2 ms·

Well with these changes before the first version I would not consider openbao a fork of vault. More like a different product. Yeah some of these proposed change

by merb 3y ago

Well with these changes before the first version I would not consider openbao a fork of vault. More like a different product. Yeah some of these proposed changes are nice. But they shouldn’t be done in the first release if you wanted to take over vault customers. I will probably never migrate to openbao. Especially if raft is the only storage option. And don’t get me wrong you can do that stuff. You do the work, so you guys can do whatever you like.

cipherboy 3y ago
I think there's many counter examples to this: Jenkins & Hudson, Illumos & Solaris, LibreSSL & OpenSSL & BoringSSL, LibreOffice & OpenOffice, Spongy Castle & Bouncy Castle, and Webkit & KHTML to name a few. A fork need not necessarily be 1:1, bug for bug, compatible. We discussed this here: https://github.com/orgs/openbao/discussions/55 https://github.com/orgs/openbao/discussions/55 and here: https://github.com/orgs/openbao/discussions/64 https://github.com/orgs/openbao/discussions/64 -- you're welcome to give feedback there and contribute to the success of the project. :-) But as noted here: https://developer.hashicorp.com/vault/docs/configuration/storage#integrated-storage-vs-external-storage https://developer.hashicorp.com/vault/docs/configuration/sto... -- upstream only supports the Raft backend. The other backends may have issues and don't see many commits as upstream has not delegated maintenance to external community members. Frequently, commentators (both employees and community members) suggest moving away from custom storage backends to Raft. A storage migration only impacts one small category of users -- the operator -- but remains transparent to the consumers of secrets (whether humans or applications). This only occurs once. Yes, it requires planning. Yes, it is a lot of work to execute successfully. But it is also an approach upstream uses e.g., in FIPS 140-2 migrations: https://developer.hashicorp.com/vault/docs/enterprise/fips/fips1402#migration-restrictions https://developer.hashicorp.com/vault/docs/enterprise/fips/f... -- as we get time, we'd like to make this type of cross-instance migration more automated if we can. But our goal is to remain API compatible, so the vast majority of use cases require no changes to operate with the forked code. And we wish to remain as drop-in compatible with consumers using Raft as we can. So yes, I think OpenBao can still be called a fork of Vault. And IMO, even a 1:1 bug compatible fork is still a separate product, and that isn't necessarily a bad thing. :-) OpenTofu has much the same approach, where they don't guarantee a 1:1 drop-in, bug-for-bug fork of upstream, but instead gives themselves some room to make changes for the best of their community: https://opentofu.org/docs/language/v1-compatibility-promises/ https://opentofu.org/docs/language/v1-compatibility-promises... I think that every project needs to find their own balance, and this is what the OpenBao community has chosen. :-) My 2c, views my own. But feel free to contact me via email if you have additional technical concerns to discuss.

by merb 3y ago

cipherboy 3y ago

I think there's many counter examples to this: Jenkins & Hudson, Illumos & Solaris, LibreSSL & OpenSSL & BoringSSL, LibreOffice & OpenOffice, Spongy Castle & Bouncy Castle, and Webkit & KHTML to name a few. A fork need not necessarily be 1:1, bug for bug, compatible. We discussed this here: https://github.com/orgs/openbao/discussions/55 https://github.com/orgs/openbao/discussions/55 and here: https://github.com/orgs/openbao/discussions/64 https://github.com/orgs/openbao/discussions/64 -- you're welcome to give feedback there and contribute to the success of the project. :-) But as noted here: https://developer.hashicorp.com/vault/docs/configuration/storage#integrated-storage-vs-external-storage https://developer.hashicorp.com/vault/docs/configuration/sto... -- upstream only supports the Raft backend. The other backends may have issues and don't see many commits as upstream has not delegated maintenance to external community members. Frequently, commentators (both employees and community members) suggest moving away from custom storage backends to Raft. A storage migration only impacts one small category of users -- the operator -- but remains transparent to the consumers of secrets (whether humans or applications). This only occurs once. Yes, it requires planning. Yes, it is a lot of work to execute successfully. But it is also an approach upstream uses e.g., in FIPS 140-2 migrations: https://developer.hashicorp.com/vault/docs/enterprise/fips/fips1402#migration-restrictions https://developer.hashicorp.com/vault/docs/enterprise/fips/f... -- as we get time, we'd like to make this type of cross-instance migration more automated if we can. But our goal is to remain API compatible, so the vast majority of use cases require no changes to operate with the forked code. And we wish to remain as drop-in compatible with consumers using Raft as we can. So yes, I think OpenBao can still be called a fork of Vault. And IMO, even a 1:1 bug compatible fork is still a separate product, and that isn't necessarily a bad thing. :-) OpenTofu has much the same approach, where they don't guarantee a 1:1 drop-in, bug-for-bug fork of upstream, but instead gives themselves some room to make changes for the best of their community: https://opentofu.org/docs/language/v1-compatibility-promises/ https://opentofu.org/docs/language/v1-compatibility-promises... I think that every project needs to find their own balance, and this is what the OpenBao community has chosen. :-) My 2c, views my own. But feel free to contact me via email if you have additional technical concerns to discuss.