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) __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
