Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dedicated openbao tf provider #339

Open
jediminer543 opened this issue May 19, 2024 · 3 comments
Open

Dedicated openbao tf provider #339

jediminer543 opened this issue May 19, 2024 · 3 comments
Labels

Comments

@jediminer543
Copy link

jediminer543 commented May 19, 2024

Is your feature request related to a problem? Please describe.
For configuring Vault, hashicorp provides a terraform provider to manage various components from terraform or opentofu. As best I can tell openbao does not maintain a fork of this, and so as openbao's api diverges there will be no replicate this functionality. There exists an opentofu manged fork but this is specifically aimed at vault, and is currently just mirroring hashicorp upstream

Describe the solution you'd like
Fork the tf provider to ensure openbao is managable? or some advice regarding api compatibility

Describe alternatives you've considered
The tf provider will function for now while the apis are matched, but divergence will likely occur and features will break, which will mean re-configuring providers and re-importing existing configuration

Additional context
The background to this is that I'm writing an infrastructure stack and would like to be able to auto-configure vault for certain uses. As best I can tell there is no existing discussion about this for guidance either.

@cipherboy
Copy link
Member

@jediminer543 The TF provider remains open source under the MPL, so I'd encourage you to contribute there instead. OpenBao is unlikely to require changes that will break this provider, though perhaps if HashiCorp is unwilling to merge any (minimally) OpenBao-specific changes, we could consider forking. But this would be a lot of work for something which largely has great intersectionality. I'd imagine for the most part, the overlapping functionality (between Vault and OpenBao) will continue to work just fine for the foreseeable future, minus any (unintentional) changes we make. My 2c.!

@jediminer543
Copy link
Author

Oki; was mostly raising this as a "what is the approximate policy on this" as if the goal is to maintain compat unless hashicorp breaks something then that works; my concern was that either hashicorp would make a breaking change due to a vault update (fixable by version pinning but not ideal) or openbao would get a feature not available via the provider. But if that's the plan is to use the hashicorp/opentofu provider I'll go with that.

Sorry for the bother, hope it wasn't too stupid of a question; leaving issue open incase there is any more discussion, feel free to close if there isn't

@cipherboy
Copy link
Member

@jediminer543 No, it is a good question :-) This has all mostly been discussed on a case-by-case basis. OpenAPI clients might end up getting forked, since they're auto-generatable (and we want to conform to the APIs exposed by OpenBao proper which will differ in places than Vault). But others we've opted not to fork, or not to fork initially until we have more maintainers and community. :-) If its something you want to work on, I'd suggest starting upstream and seeing if there's pushback to adding something we have, and we can revisit if there is!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants