Open Stack

Clint Byrum wrote:
> 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:
>>> 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..".

Well put.

Long-term, it will also help drive Barbican on the "base services" track
(an oslo.db-compatible database, an oslo.messaging-compatible queue, an
oslo.keymanager-compatible key manager...)

>>> 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 it may be originally seeded by the same people, I think the two
groups may diverge in the future, especially if support for other key
managers is added.

-- 
Thierry Carrez (ttx)