-
Notifications
You must be signed in to change notification settings - Fork 97
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
Comments
@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.! |
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 |
@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! |
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.
The text was updated successfully, but these errors were encountered: