Open Stack

Excerpts from Doug Hellmann's message of 2017-03-14 19:20:08 -0400:
> Excerpts from Clint Byrum's message of 2017-03-13 13:49:22 -0700:
> > Excerpts from Doug Hellmann's message of 2017-03-13 15:12:42 -0400:
> > > Excerpts from Farr, Kaitlin M.'s message of 2017-03-13 18:55:18 +0000:
> > > > Proposed library name: Rename Castellan to oslo.keymanager
> > > > 
> > > > Proposed library mission/motivation: Castellan's goal is to provide a
> > > > generic key manager interface that projects can use for their key
> > > > manager needs, e.g., storing certificates or generating keys for
> > > > encrypting data.  The interface passes the commands and Keystone
> > > > credentials on to the configured back end. Castellan is not a service
> > > > and does not maintain state. The library can grow to have multiple
> > > > back ends, as long as the back end can authenticate Keystone
> > > > credentials.  The only two back end options now in Castellan are
> > > > Barbican and a limited mock key manager useful only for unit tests.
> > > > If someone wrote a Keystone auth plugin for Vault, we could also have a
> > > > Vault back end for Castellan.
> > > > 
> > > > The benefit of using Castellan versus using Barbican directly
> > > > is Castellan allows the option of swapping out for other key managers,
> > > > mainly for testing.  If projects want their own custom back end for
> > > > Castellan, they can write a back end that implements the Castellan
> > > > interface but lives in their own code base, i.e., ConfKeyManager in
> > > > Nova and Cinder. Additionally, Castellan already has oslo.config
> > > > options defined which are helpful for configuring the project to talk
> > > > to Barbican.
> > > > 
> > > > When the Barbican team first created the Castellan library, we had
> > > > reached out to oslo to see if we could name it oslo.keymanager, but the
> > > > idea was not accepted because the library didn't have enough traction.
> > > > Now, Castellan is used in many projects, and we thought we would
> > > > suggest renaming again.  At the PTG, the Barbican team met with the AWG
> > > > to discuss how we could get Barbican integrated with more projects, and
> > > > the rename was also suggested at that meeting.  Other projects are
> > > > interested in creating encryption features, and a rename will help
> > > > clarify the difference between Barbican and Castellan.
> > > 
> > > Can you expand on why you think that is so? I'm not disagreeing with the
> > > statement, but it's not obviously true to me, either. I vaguely remember
> > > having it explained at the PTG, but I don't remember the details.
> > > 
> > 
> > To me, Oslo is a bunch of libraries that encompass "the way OpenStack
> > does XXXX". When XXXX is key management, projects are, AFAICT, universally
> > using Castellan at the moment. So I think it fits in Oslo conceptually.
> > 
> > As far as what benefit there is to renaming it, the biggest one is
> > divesting Castellan of the controversy around Barbican. There's no
> > disagreement that explicitly handling key management is necessary. There
> > is, however, still hesitance to fully adopt Barbican in that role. In
> > fact I heard about some alternatives to Barbican, namely "Vault"[1] and
> > "Tang"[2], that may be useful for subsets of the community, or could
> > even grow into de facto standards for key management.
> > 
> > So, given that there may be other backends, and the developers would
> > like to embrace that, I see value in renaming. It would help, I think,
> > Castellan's developers to be able to focus on key management and not
> > have to explain to every potential user "no we're not Barbican's cousin,
> > we're just an abstraction..".
> > 
> > > > Existing similar libraries (if any) and why they aren't being used: N/A
> > > > 
> > > > Reviewer activity: Barbican team
> > > 
> > > If the review team is going to be largely the same, I'm not sure I
> > > see the benefit of changing the ownership of the library. We certainly
> > > have other examples of Oslo libraries being managed mainly by
> > > sub-teams made up of folks who primarily focus on other projects.
> > > oslo.policy and oslo.versionedobjects come to mind, but in both of
> > > those cases the code was incubated in Oslo or brought into Oslo
> > > before the tools for managing shared libraries were widely used
> > > outside of the Oslo team. We now have quite a few examples of project
> > > teams managing shared libraries (other than their clients).
> > > 
> > 
> > While this makes sense, I'm not so sure any of those are actually
> > specifically in the same category as Castellan. Perhaps you can expand
> > on which libraries have done this, and how they're similar to Castellan?
> 
> oslo.versionedobjects was extracted from nova, and came with a small
> set of contributors who have made up a subteam of Oslo. As far as
> I know, they rarely contribute outside of that library (I haven't
> checked lately, so apologies if my info is out of date). I forget
> where the oslo.policy code came from, but it is largely managed by
> contributors from the keystone team. Those seem quite similar to this
> case.
> 
> Maybe I'm misunderstanding, though. Are there Oslo team members
> ready to sign up to help manage this new library, or is the expectation
> that it will be handled by exactly the same group of people under
> a different name?

I feel that I need to clarify my position.

Although I am not 100% convinced a rename and ownership change is
needed, if the Oslo and Barbican teams agree that it makes sense
and the contributors want to work under the Oslo banner, I am not
fundamentally opposed to the move.

If the primary thing we seek to gain is the neutrality from having
the Oslo team own the library, then I am more in favor of simply
changing the ownership and not renaming the library, because the
rename comes with extra roll-out and maintenance burden (we have
to maintain the old library until we have no stable releases of
server projects using it).

Doug

> 
> > 
> > [1] https://www.vaultproject.io/
> > [2] https://github.com/latchset/tang
> > 
>