On Tue, Mar 14, 2017 at 9:27 PM, Clint Byrum <[email protected]> wrote: > Excerpts from Doug Hellmann's message of 2017-03-14 20:05:54 -0400: >> 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). >> > > +1 for just pulling it under the oslo umbrella but not renaming it. As > much as I like the uniformity oslo.keymanager would bring, I think it's > already adopted well enough we just want to make it clear that it is > blessed and ok to adopt.
The precedent here is "tooz" that we use for DLM is under oslo umbrella. -- Dims > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
