Open Stack

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.

> 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).

> Who is going to use this (project involvement): Cinder, Nova, Sahara,
> and Glance already use Castellan, Swift has a patch that integrates
> Castellan.
> 
> Proposed adoption model/plan: The Castellan library was already created
> and produces a functional and useful artifact (a pypi release) and is
> integrated into various OpenStack projects and now it is proposed that
> the library be moved into the Oslo group's namespace by creating a fork
> of Castellan, clean up a few things, create a new oslo.keymanager
> release on pypi, and change the projects to use oslo.keymanager.
> 
> Thanks,
> 
> Kaitlin Farr
> Software Engineer
> The Johns Hopkins University Applied Physics Laboratory