Open Stack

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?

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