5 ms·

Everything becomes clearer... Glad we already moved to OpenTofu

by tanepiper 3y ago

ricc 3y ago
It's quite sad to think that Terraform might go the way of Hudson...
- fishnchips 3y ago
  It's not the worst possible outcome.
rapnie 3y ago
Still early, but don't forget OpenBao fork of Vault. https://github.com/openbao https://github.com/openbao
- tanepiper 3y ago
  Amazing - we actually had a secrets PoC for our org paused recently, and Vault is one of the options. But honestly this looks like it could solve a few things in our team right now.
  - sanjay313 3y ago
    [dead]
- sgt 3y ago
  What about OpenMao? https://openmao.panchuang.net/#/ https://openmao.panchuang.net/#/
- cipherboy 3y ago
  Happy to answer technical questions about OpenBao as people have, though some might be best directed at the Technical Steering Committee, which I do not represent. :-)
  - candiddevmike 3y ago
    I owe you a PR review on the source IP lock, I haven't had time to test it yet. It's awesome that you address it though, thank you.
    - cipherboy 3y ago
      Thank you for the RFE! Looking at the X-Forwarded-For handling might be good, I wasn't able to add tests for that easily, though maybe the existing test could be used as a template if you get time. I think we depend on nginx or Caddy elsewhere, but the pkiext tests might also serve as a good reference. :-)
  - merb 3y ago
    Why did you kill most storage plugins? I hoped that I could move from vault to openbao , but it looks like that is not the case. I can understand the removal of secrets engines and stuff but the storage plugins should’ve been kept at least for the first few releases and than dropped a few of them while giving people a way to migrate them to supported options.
    - JanMa 3y ago
      We had some discussions about this before removing all storage plugins except Raft, In-Memory and File storage as cipherboy pointed out in the sibling comment. If you're currently not using Raft, this should not stop you from adopting OpenBao if you first migrate to the Raft storage backend. Hashicorp has a tutorial on this which you can follow: https://developer.hashicorp.com/vault/tutorials/raft/raft-migration https://developer.hashicorp.com/vault/tutorials/raft/raft-mi... I've personally used the Raft storage backend in production for some years and can assure you it is rock solid.
    - cipherboy 3y ago
      Maintainability and feature development mostly. I have a few improvements I'd have liked to have see upstream, but couldn't land due to the vast storage plugin base. You're left writing to the lowest common denominator of 20 storage engines which isn't maintainable when HashiCorp only supports Raft and Consul. Take paginated lists which I've proposed as a PR. If your backend engine of choice doesn't support efficient pagination aligning with the designated semantics, you're stuck implementing it from scratch. Now do that with transactional storage, which is another upstream requested feature... And so forth. Additionally, the current contributor base is too small to support much more. Personally, I'd like to see Postgres as the only external storage engine. But I don't presently feel we have enough maintainers to justify multiple storage engines. Raft is easiest to support as it is what upstream is actively developing. It also eases migration for upstream-aligned users. My 2c. But happy to take suggestions and contributions! Edit to add: ideally I'd have liked to add an external storage plugin interface, but this would be a bit of a perf hit over native support and wouldn't be a stable target (as I'd like to see some of these things land).
cube2222 3y ago
As the tech lead of the OpenTofu project, I can tell you that I'm positively surprised by how quick the uptake has been so far since the stable release! We're also seeing a ton of external contributors jumping in, which has been heartwarming! I also invite anybody using OpenTofu (or considering it) to join our Slack[0], it's quite active there. It's also a great place to influence the shape of new OpenTofu features. Now 1.7 is coming out soon as well, and this week we have OpenTofu Day at KubeCon happening :) [0]: http://opentofu.org/slack http://opentofu.org/slack
- vr46 3y ago
  Just started a new tiny greenfield infra project for a friend but was too cowardly to use OpenTF after I tried it and found that I needed Hashicorp providers etc, couldn’t be bothered to dig in and untangle. Gotta say, didn’t find opentf docs useful at all. But hoping things go well and one day I’ll be able to just fire things up and it’ll be frictionless.
  - cube2222 3y ago
    Sorry to hear that, could you expand on the paint points? Esp. on the friction points, where it was different than just using `tofu` instead of `terraform` in your commands. To answer some of your points: There's no point in forking the providers, as they're still open-source, you're just fetching them from our registry - registry.opentofu.org. Core docs are generally the same as Terraform docs, but we're still missing the registry UI to explore provider docs (and are currently working on a design for that).
    - vr46 3y ago
      Mainly because I installed it and ran it on a sample base infra - vpc and subnets - and I noted that it was still picking up Hashicorp providers, fine, but doesn’t this mean I have to run through a large codebase and start switching every provider out? Essentially I wasn’t sure what to do next. Should I stick with my standard terraform setup or figure out shifting to OpenTF and risk getting hit with something not available? Wasn’t something I could figure out in advance, if that makes sense? So was safest to stick with TF.
sevagh 3y ago
We're still on Terraform 1.5 (pre-license change) and Scalr. Things are still working, fingers crossed. Was there any pain in preserving existing state files and large amounts of existing infrastructure (and terraform repos) when migrating to OpenTofu?

Everything becomes clearer... Glad we already moved to OpenTofu

ricc 3y ago

It's quite sad to think that Terraform might go the way of Hudson...

fishnchips 3y ago
It's not the worst possible outcome.

rapnie 3y ago

Still early, but don't forget OpenBao fork of Vault. https://github.com/openbao https://github.com/openbao

tanepiper 3y ago
Amazing - we actually had a secrets PoC for our org paused recently, and Vault is one of the options. But honestly this looks like it could solve a few things in our team right now.
- sanjay313 3y ago
  [dead]
sgt 3y ago
What about OpenMao? https://openmao.panchuang.net/#/ https://openmao.panchuang.net/#/
cipherboy 3y ago
Happy to answer technical questions about OpenBao as people have, though some might be best directed at the Technical Steering Committee, which I do not represent. :-)
- candiddevmike 3y ago
  I owe you a PR review on the source IP lock, I haven't had time to test it yet. It's awesome that you address it though, thank you.
  - cipherboy 3y ago
    Thank you for the RFE! Looking at the X-Forwarded-For handling might be good, I wasn't able to add tests for that easily, though maybe the existing test could be used as a template if you get time. I think we depend on nginx or Caddy elsewhere, but the pkiext tests might also serve as a good reference. :-)
- merb 3y ago
  Why did you kill most storage plugins? I hoped that I could move from vault to openbao , but it looks like that is not the case. I can understand the removal of secrets engines and stuff but the storage plugins should’ve been kept at least for the first few releases and than dropped a few of them while giving people a way to migrate them to supported options.
  - JanMa 3y ago
    We had some discussions about this before removing all storage plugins except Raft, In-Memory and File storage as cipherboy pointed out in the sibling comment. If you're currently not using Raft, this should not stop you from adopting OpenBao if you first migrate to the Raft storage backend. Hashicorp has a tutorial on this which you can follow: https://developer.hashicorp.com/vault/tutorials/raft/raft-migration https://developer.hashicorp.com/vault/tutorials/raft/raft-mi... I've personally used the Raft storage backend in production for some years and can assure you it is rock solid.
  - cipherboy 3y ago
    Maintainability and feature development mostly. I have a few improvements I'd have liked to have see upstream, but couldn't land due to the vast storage plugin base. You're left writing to the lowest common denominator of 20 storage engines which isn't maintainable when HashiCorp only supports Raft and Consul. Take paginated lists which I've proposed as a PR. If your backend engine of choice doesn't support efficient pagination aligning with the designated semantics, you're stuck implementing it from scratch. Now do that with transactional storage, which is another upstream requested feature... And so forth. Additionally, the current contributor base is too small to support much more. Personally, I'd like to see Postgres as the only external storage engine. But I don't presently feel we have enough maintainers to justify multiple storage engines. Raft is easiest to support as it is what upstream is actively developing. It also eases migration for upstream-aligned users. My 2c. But happy to take suggestions and contributions! Edit to add: ideally I'd have liked to add an external storage plugin interface, but this would be a bit of a perf hit over native support and wouldn't be a stable target (as I'd like to see some of these things land).

cube2222 3y ago

As the tech lead of the OpenTofu project, I can tell you that I'm positively surprised by how quick the uptake has been so far since the stable release! We're also seeing a ton of external contributors jumping in, which has been heartwarming! I also invite anybody using OpenTofu (or considering it) to join our Slack[0], it's quite active there. It's also a great place to influence the shape of new OpenTofu features. Now 1.7 is coming out soon as well, and this week we have OpenTofu Day at KubeCon happening :) [0]: http://opentofu.org/slack http://opentofu.org/slack

vr46 3y ago
Just started a new tiny greenfield infra project for a friend but was too cowardly to use OpenTF after I tried it and found that I needed Hashicorp providers etc, couldn’t be bothered to dig in and untangle. Gotta say, didn’t find opentf docs useful at all. But hoping things go well and one day I’ll be able to just fire things up and it’ll be frictionless.
- cube2222 3y ago
  Sorry to hear that, could you expand on the paint points? Esp. on the friction points, where it was different than just using `tofu` instead of `terraform` in your commands. To answer some of your points: There's no point in forking the providers, as they're still open-source, you're just fetching them from our registry - registry.opentofu.org. Core docs are generally the same as Terraform docs, but we're still missing the registry UI to explore provider docs (and are currently working on a design for that).
  - vr46 3y ago
    Mainly because I installed it and ran it on a sample base infra - vpc and subnets - and I noted that it was still picking up Hashicorp providers, fine, but doesn’t this mean I have to run through a large codebase and start switching every provider out? Essentially I wasn’t sure what to do next. Should I stick with my standard terraform setup or figure out shifting to OpenTF and risk getting hit with something not available? Wasn’t something I could figure out in advance, if that makes sense? So was safest to stick with TF.

sevagh 3y ago

We're still on Terraform 1.5 (pre-license change) and Scalr. Things are still working, fingers crossed. Was there any pain in preserving existing state files and large amounts of existing infrastructure (and terraform repos) when migrating to OpenTofu?