Re: [openstack-dev] Incubation Request for Barbican
On 12/19/2013 12:10 AM, Mike Perez wrote: On Tue, Dec 17, 2013 at 1:59 PM, Mike Perez thin...@gmail.com mailto:thin...@gmail.com wrote: snip I reviewed the TC meeting notes, and my question still stands. It seems the committee is touching on the point of there being a worry because if it's a single company running the show, they can pull resources away and the project collapses. My worry is just having one company attempting to design solutions to use cases that work for them, will later not work for those potential companies that would provide contributors. -Mike Perez Which is our fundamental chicken and egg problem. The Barbican team has said they've reached out to other parties, who have expressed interest in joining, but no one else has. The Heat experience shows that a lot of the time companies won't kick in resources until there is some kind of stamp of general approval. If you showed up early, with a commitment to work openly, the fact that the project maps to your own use cases really well isn't a bug, it's a feature. I don't want to hold up a team from incubating because other people stayed on the sidelines. That was actually exactly what was going on with Heat, where lots of entities thought they would keep that side of the equation proprietary, or outside of OpenStack. By bringing Heat in, we changed the equation, I think massively for the better. -Sean -- Sean Dague Samsung Research America s...@dague.net / sean.da...@samsung.com http://dague.net signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Incubation Request for Barbican
Excerpts from Sean Dague's message of 2013-12-19 04:14:51 -0800: On 12/19/2013 12:10 AM, Mike Perez wrote: On Tue, Dec 17, 2013 at 1:59 PM, Mike Perez thin...@gmail.com mailto:thin...@gmail.com wrote: snip I reviewed the TC meeting notes, and my question still stands. It seems the committee is touching on the point of there being a worry because if it's a single company running the show, they can pull resources away and the project collapses. My worry is just having one company attempting to design solutions to use cases that work for them, will later not work for those potential companies that would provide contributors. -Mike Perez Which is our fundamental chicken and egg problem. The Barbican team has said they've reached out to other parties, who have expressed interest in joining, but no one else has. The Heat experience shows that a lot of the time companies won't kick in resources until there is some kind of stamp of general approval. I want to confirm this specific case. I joined the TripleO effort just about a year ago. We needed an orchestration tool. If Heat hadn't been in incubation we would have considered all other options. Because it was incubated, even though some others might have been more or less attractive, there was no question we would lend our efforts to Heat. Had we just decided to build our own, or try to enhance Ansible or salt-cloud, we'd have likely had to abandon that effort as Heat improved beyond their scope in the context of managing OpenStack API's. If you showed up early, with a commitment to work openly, the fact that the project maps to your own use cases really well isn't a bug, it's a feature. I don't want to hold up a team from incubating because other people stayed on the sidelines. That was actually exactly what was going on with Heat, where lots of entities thought they would keep that side of the equation proprietary, or outside of OpenStack. By bringing Heat in, we changed the equation, I think massively for the better. Right, contributing to a project that is already part of OpenStack means you don't have to have _another_ conversation with management/legal/etc. about contributing to _another_ OpenSource project with slightly different governance/licensing/affiliation. An organization can align its strategy around OpenStack, earn influence on the board/TC/dev teams/etc. So when it is time to open source something as part of that, the org can, I hope, count on OpenStack to welcome them and shout to the world that there is a new X in town and everybody else should take a good long look at it and consider dropping their own X in favor of contributing to this one. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Incubation Request for Barbican
On Thu, Dec 19, 2013 at 4:14 AM, Sean Dague s...@dague.net wrote: On 12/19/2013 12:10 AM, Mike Perez wrote: On Tue, Dec 17, 2013 at 1:59 PM, Mike Perez thin...@gmail.com mailto:thin...@gmail.com wrote: snip I reviewed the TC meeting notes, and my question still stands. It seems the committee is touching on the point of there being a worry because if it's a single company running the show, they can pull resources away and the project collapses. My worry is just having one company attempting to design solutions to use cases that work for them, will later not work for those potential companies that would provide contributors. -Mike Perez Which is our fundamental chicken and egg problem. The Barbican team has said they've reached out to other parties, who have expressed interest in joining, but no one else has. The Heat experience shows that a lot of the time companies won't kick in resources until there is some kind of stamp of general approval. If you showed up early, with a commitment to work openly, the fact that the project maps to your own use cases really well isn't a bug, it's a feature. I don't want to hold up a team from incubating because other people stayed on the sidelines. That was actually exactly what was going on with Heat, where lots of entities thought they would keep that side of the equation proprietary, or outside of OpenStack. By bringing Heat in, we changed the equation, I think massively for the better. -Sean To make my message more clear, I would like to see the TC thinking of this problem as well. In Cinder for example, there was a push for a shared service. One of the problems that the core saw in this feature was it was a one-sided project because only one vendor was really contributing. The API they provided may work great for them, but may not work for other potential contributors that come from another company where their storage system works differently. I see this as causing potential serious rewrites that really just sets a project back. I'm not at all saying this stops incubation, but just something else to consider besides a company pulling out the main resource from a project. -Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Incubation Request for Barbican
On Thu, Dec 12, 2013 at 4:48 PM, Morgan Fainberg m...@metacloud.com wrote: On December 12, 2013 at 14:32:36, Dolph Mathews (dolph.math...@gmail.com//dolph.math...@gmail.com) wrote: On Thu, Dec 12, 2013 at 2:58 PM, Adam Young ayo...@redhat.com wrote: On 12/04/2013 08:58 AM, Jarret Raim wrote: While I am all for adding a new program, I think we should only add one if we rule out all existing programs as a home. With that in mind why not add this to the keystone program? Perhaps that may require a tweak to keystones mission statement, but that is doable. I saw a partial answer to this somewhere but not a full one. From our point of view, Barbican can certainly help solve some problems related to identity like SSH key management and client certs. However, there is a wide array of functionality that Barbican will handle that is not related to identity. Some examples, there is some additional detail in our application if you want to dig deeper [1]. * Symmetric key management - These keys are used for encryption of data at rest in various places including Swift, Nova, Cinder, etc. Keys are resources that roll up to a project, much like servers or load balancers, but they have no direct relationship to an identity. * SSL / TLS certificates - The management of certificate authorities and the issuance of keys for SSL / TLS. Again, these are resources rather than anything attached to identity. * SSH Key Management - These could certainly be managed through keystone if we think that¹s the right way to go about it, but from Barbican¹s point of view, these are just another type of a key to be generated and tracked that roll up to an identity. * Client certificates - These are most likely tied to an identity, but again, just managed as resources from a Barbican point of view. * Raw Secret Storage - This functionality is usually used by applications residing on an Cloud. An app can use Barbican to store secrets such as sensitive configuration files, encryption keys and the like. This data belongs to the application rather than any particular user in Keystone. For example, some Rackspace customers don¹t allow their application dev / maintenance teams direct access to the Rackspace APIs. * Boot Verification - This functionality is used as part of the trusted boot functionality for transparent disk encryption on Nova. * Randomness Source - Barbican manages HSMs which allow us to offer a source of true randomness. In short (ha), I would encourage everyone to think of keys / certificates as resources managed by an API in much the same way we think of VMs being managed by the Nova API. A consumer of Barbican (either as an OpenStack service or a consumer of an OpenStack cloud) will have an API to create and manage various types of secrets that are owned by their project. My reason for keeping them separate is more practical: the Keystone team is already somewhat overloaded. I know that a couple of us have interest in contributing to Barbican, the question is time and prioritization. Unless there is some benefit to having both projects in the same program with essentially different teams, I think Barbican should proceed as is. I personally plan on contributing to Barbican. /me puts PTL hat on ++ I don't want Russel's job. Keystone has a fairly narrow mission statement in my mind (come to think of it, I need to propose it to governance..), and that's basically to abstract away the problem of authenticating and authorizing the API users of other openstack services. Everything else, including identity management, key management, key distribution, quotas, etc, is just secondary fodder that we tend to help with along the way... but they should be first class problems in someone else's mind. If we rolled everything together that kind of looks related to keystone under a big keystone program for the sake of organizational tidiness, I know I would be less effective as a PTL and that's a bit disheartening. That said, I'm always happy to help where I can. The long and the short of it is that I can’t argue that Barbican couldn’t be considered a mechanism of “Identity” (in most everything keys end up being a form of Identity, and the management of that would fit nicely under the “Identity Program”). That being said I also can’t argue that Barbican shouldn’t be it’s own top-level program. It comes down to the best fit for OpenStack as a whole. From a deployer standpoint, I don’t think it will make any real difference if Barbican is in Identity or it’s own program. Basically, it’ll be a separate process to run in either case. It will have it’s own rules and quirks. From a developer standpoint, I don’t think it will make a significant difference (besides, perhaps where documentation lies). The contributors to Keystone will contribute (or not) to Barbican and vice-versa based upon interest/time/needs. From a community and
Re: [openstack-dev] Incubation Request for Barbican
Bhandaru, Malini K wrote: Barbican, key manager is essential to openstack, paves the way to greater security. Instead of rejecting the project because of its current existence owed so heavily to Rackspace and to John Wood, why not we adopt it, code review, contribute code etc. We can have cores from multiple companies. Swift was a project that was born similarly. During development John Wood and the whole Rackspace team has been open to feature design discussions and providing good code review. Intel plans to create a plugin for Barbican, along the lines of a low cost HSM, essentially using the Intel TXT and the Trusted Platform Module to save a master secret used to encrypt all the other secrets. Our Intel team is small and some of us had other distractions in October and November, but we are back and may even grow in strength. John, Jarret, and team, thank you for all the hard work. During the TC meeting yesterday it was decided that Barbican should request a new incubation evaluation once it completes the remaining technical requirements that were mentioned during the initial incubation evaluation. That should happen in a few weeks. As far as the diversity requirement is concerned, the TC is actually divided: some members think it should be a requirement for incubation, while others think it should be a requirement for graduation to integrated. The discussion on this is still ongoing (and shall happen in a separate thread which I'll soon create), but hopefully we'll have a common view on it by the time Barbican asks for reevaluation. Regards, -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Incubation Request for Barbican
On 12/13/2013 03:50 AM, Thierry Carrez wrote: Russell Bryant wrote: $ git shortlog -s -e | sort -n -r 172 John Wood john.w...@rackspace.com 150 jfwood john.w...@rackspace.com 65 Douglas Mendizabal douglas.mendiza...@rackspace.com 39 Jarret Raim jarret.r...@rackspace.com 17 Malini K. Bhandaru malini.k.bhand...@intel.com 10 Paul Kehrer paul.l.keh...@gmail.com 10 Jenkins jenk...@review.openstack.org 8 jqxin2006 jqxin2...@gmail.com 7 Arash Ghoreyshi arashghorey...@gmail.com 5 Chad Lung chad.l...@gmail.com 3 Dolph Mathews dolph.math...@gmail.com 2 John Vrbanac john.vrba...@rackspace.com 1 Steven Gonzales stevendgonza...@gmail.com 1 Russell Bryant rbry...@redhat.com 1 Bryan D. Payne bdpa...@acm.org It appears to be an effort done by a group, and not an individual. Most commits by far are from Rackspace, but there is at least one non-trivial contributor (Malini) from another company (Intel), so I think this is OK. If you remove Jenkins and attach Paul Kehrer, jqxin2006 (Michael Xin), Arash Ghoreyshi, Chad Lung and Steven Gonzales to Rackspace, then the picture is: 67% of commits come from a single person (John Wood) 96% of commits come from a single company (Rackspace) I think that's a bit brittle: if John Wood or Rackspace were to decide to place their bets elsewhere, the project would probably die instantly. I would feel more comfortable if a single individual didn't author more than 50% of the changes, and a single company didn't sponsor more than 80% of the changes. Personally I think that's a large enough group to make up a Program and gain visibility, but a bit too fragile to enter incubation just now. Thierry, It is important to point out that in the case of Heat, almost all of the Heat commits prior to incubation came from Red Hat. The team was diverse, with each of the original core team contributing about 20% of the commits. But that has significantly changed - now there are commits from all over the place and our core team has grown to many folks outside of Red Hat. The Heat community is much more resilient today then it was in the past, which is the point multiple contributors/companies bring. But what brought about this resilience was incubation. If the mission of the project matches OpenStack, I'd suggest allowing for incubation and see what happens. Incubation brings all kinds of goodness to a project. Few companies are willing to commit engineering talent to work on an OpenStack project until it has entered incubation. I spent countless hours on the phone trying to get devs to commit to working on heat prior to incubation, and it was a nearly impossible task - managers at companies just didn't want to commit people to work on speculative RD. IIRC, there is a way for a project to *exit* incubation if it falls apart. We should not be afraid of an incubated project failing and exiting via this already defined (but never used) path. In this particular case, I believe Barbican is not ready for incubation because of their dependence on celery, but ultimately I don't make the decision :) Regards -steve ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Incubation Request for Barbican
-Original Message- From: Steven Dake [mailto:sd...@redhat.com] In this particular case, I believe Barbican is not ready for incubation because of their dependence on celery, but ultimately I don't make the decision :) We've landed the PR that removes celery and replaces it with oslo.messaging. As Thierry said, once we are finished with the other couple of requests from the TC and we'll re-apply after the holidays. Other than that, I agree with everything you said :) Jarret smime.p7s Description: S/MIME cryptographic signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Incubation Request for Barbican
On 12/18/2013 10:23 AM, Jarret Raim wrote: -Original Message- From: Steven Dake [mailto:sd...@redhat.com] In this particular case, I believe Barbican is not ready for incubation because of their dependence on celery, but ultimately I don't make the decision :) We've landed the PR that removes celery and replaces it with oslo.messaging. As Thierry said, once we are finished with the other couple of requests from the TC and we'll re-apply after the holidays. Other than that, I agree with everything you said :) I also just want to note that Jarret and the Barbican team have been very responsive to the technical requirements we've talked about for incubation. And I think this is progressing really great in going and working on that list and coming back for the actual incubation request once it's done. Thanks folks. The responsiveness there has been very appreciated. -Sean -- Sean Dague http://dague.net signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Incubation Request for Barbican
On Tue, Dec 17, 2013 at 1:59 PM, Mike Perez thin...@gmail.com wrote: On Tue, Dec 17, 2013 at 11:44 AM, Jarret Raim jarret.r...@rackspace.comwrote: On 12/13/13, 4:50 AM, Thierry Carrez thie...@openstack.org wrote: If you remove Jenkins and attach Paul Kehrer, jqxin2006 (Michael Xin), Arash Ghoreyshi, Chad Lung and Steven Gonzales to Rackspace, then the picture is: 67% of commits come from a single person (John Wood) 96% of commits come from a single company (Rackspace) I think that's a bit brittle: if John Wood or Rackspace were to decide to place their bets elsewhere, the project would probably die instantly. I would feel more comfortable if a single individual didn't author more than 50% of the changes, and a single company didn't sponsor more than 80% of the changes. I think these numbers somewhat miss the point. It is true that Rackspace is the primary sponsor of Barbican and that John Wood is the developer that has been on the project the longest. However, % of commits is not the only measure of contributions to the project. That number doesn¹t include the work on our chef-automation scripts or design work to figure out the HSM interfaces or work on the testing suite or writing our documentation or the million other tasks for the project. Rackspace is committed to this project. If John Wood leaves, we¹ll hire additional developers to replace him. There is no risk of the project lacking resources because a single person decides to work on something else. We¹ve seen other folks from HP, RedHat, Nebula, etc. say that they are interested in contributing and we are getting outside contributions today. That will only continue, but I think the risk of the project somehow collapsing is being overstated. There are problems that aren¹t necessarily the sexiest things to work on, but need to be done. It may be hard to get a large number of people interested in such a project in a short period of time. I think it would be a mistake to reject projects that solve important problems just because the team is a bit one sided at the time. Besides it being considered brittle because there is one major code contributor, I would be worried about the project being one-sided to solving the use cases that work for one company, but may not work for the use cases of other companies if they have not chimed in yet. Do you feel this is not the case? Can anyone from somewhere other than Rackspace speak up and say they have been involved with the design/discussions of Barbican? -Mike Perez I reviewed the TC meeting notes, and my question still stands. It seems the committee is touching on the point of there being a worry because if it's a single company running the show, they can pull resources away and the project collapses. My worry is just having one company attempting to design solutions to use cases that work for them, will later not work for those potential companies that would provide contributors. -Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Incubation Request for Barbican
On 12/13/13, 7:56 AM, Russell Bryant rbry...@redhat.com wrote: 1) Are each of the items you mention big enough to have a sustainable team that can exist as its own program? The answer here for Barbican and Keystone is yes. 2) Would there be a benefit of *changing* the scope and mission of the Identity program to accomodate a larger problem space? Security sounds too broad ... but I'm sure you see what I'm getting at. Dolph and I have talked about this a bit. Right now, if we combined them, it feels like we would have meetings where the first half would be about Keystone and the second about Barbican. Same for design sessions. The systems and the concerns they address are entirely separate. Currently the teams are also entirely separate. While I think we can encourage both teams to have a close relationship (Adam Young and I had a conversion about that recently), there is no benefit to combining the teams now other than to reduce the number of programs. As the combination doesn¹t help either project, it seems like Barbican having its own program is the best option. When we're talking about authentication, authorization, identity management, key management, key distribution ... these things really *do* seem related enough that it would be *really* nice if a group was looking at all of them and how they fit into the bigger OpenStack picture. I really don't want to see silos for each of these things. I don¹t agree here. Key management and distribution can be used to solve problems in the identity space. They can also be used to solve problems in other spaces in openstack. Barbican uses keystone to provide auth / auth to keys, much like Nova uses keystone to provide auth / auth to servers. Additionally, Barbican will deal with other parts of the encryption space (e.g. SSL) that have very little to do with identity. So, would OpenStack benefit from a tighter relationship between these projects? I think this may be the case, personally. I think there would be benefit to individuals working together from the two projects where it makes sense - especially where we have knowledge overlaps. I don¹t agree that including Barbican in the Identity program is the right way to do that. Could this tighter relationship happen between separate programs? It could, but I think a single program better expresses the intent if that's really what is best. Barbican¹s intent is to simplify key management to enable consuming systems and users to offer or use encryption in their services. This is a fundementally different mission than Keystone has. Jarret smime.p7s Description: S/MIME cryptographic signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Incubation Request for Barbican
On 12/13/13, 4:50 AM, Thierry Carrez thie...@openstack.org wrote: If you remove Jenkins and attach Paul Kehrer, jqxin2006 (Michael Xin), Arash Ghoreyshi, Chad Lung and Steven Gonzales to Rackspace, then the picture is: 67% of commits come from a single person (John Wood) 96% of commits come from a single company (Rackspace) I think that's a bit brittle: if John Wood or Rackspace were to decide to place their bets elsewhere, the project would probably die instantly. I would feel more comfortable if a single individual didn't author more than 50% of the changes, and a single company didn't sponsor more than 80% of the changes. I think these numbers somewhat miss the point. It is true that Rackspace is the primary sponsor of Barbican and that John Wood is the developer that has been on the project the longest. However, % of commits is not the only measure of contributions to the project. That number doesn¹t include the work on our chef-automation scripts or design work to figure out the HSM interfaces or work on the testing suite or writing our documentation or the million other tasks for the project. Rackspace is committed to this project. If John Wood leaves, we¹ll hire additional developers to replace him. There is no risk of the project lacking resources because a single person decides to work on something else. We¹ve seen other folks from HP, RedHat, Nebula, etc. say that they are interested in contributing and we are getting outside contributions today. That will only continue, but I think the risk of the project somehow collapsing is being overstated. There are problems that aren¹t necessarily the sexiest things to work on, but need to be done. It may be hard to get a large number of people interested in such a project in a short period of time. I think it would be a mistake to reject projects that solve important problems just because the team is a bit one sided at the time. Jarret smime.p7s Description: S/MIME cryptographic signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Incubation Request for Barbican
On Tue, Dec 17, 2013 at 11:44 AM, Jarret Raim jarret.r...@rackspace.comwrote: On 12/13/13, 4:50 AM, Thierry Carrez thie...@openstack.org wrote: If you remove Jenkins and attach Paul Kehrer, jqxin2006 (Michael Xin), Arash Ghoreyshi, Chad Lung and Steven Gonzales to Rackspace, then the picture is: 67% of commits come from a single person (John Wood) 96% of commits come from a single company (Rackspace) I think that's a bit brittle: if John Wood or Rackspace were to decide to place their bets elsewhere, the project would probably die instantly. I would feel more comfortable if a single individual didn't author more than 50% of the changes, and a single company didn't sponsor more than 80% of the changes. I think these numbers somewhat miss the point. It is true that Rackspace is the primary sponsor of Barbican and that John Wood is the developer that has been on the project the longest. However, % of commits is not the only measure of contributions to the project. That number doesn¹t include the work on our chef-automation scripts or design work to figure out the HSM interfaces or work on the testing suite or writing our documentation or the million other tasks for the project. Rackspace is committed to this project. If John Wood leaves, we¹ll hire additional developers to replace him. There is no risk of the project lacking resources because a single person decides to work on something else. We¹ve seen other folks from HP, RedHat, Nebula, etc. say that they are interested in contributing and we are getting outside contributions today. That will only continue, but I think the risk of the project somehow collapsing is being overstated. There are problems that aren¹t necessarily the sexiest things to work on, but need to be done. It may be hard to get a large number of people interested in such a project in a short period of time. I think it would be a mistake to reject projects that solve important problems just because the team is a bit one sided at the time. Besides it being considered brittle because there is one major code contributor, I would be worried about the project being one-sided to solving the use cases that work for one company, but may not work for the use cases of other companies if they have not chimed in yet. Do you feel this is not the case? Can anyone from somewhere other than Rackspace speak up and say they have been involved with the design/discussions of Barbican? -Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Incubation Request for Barbican
To add to Jarret's arguments, across OpenStack we have seen as subsystems grow more mature and complex from additional feature extensions, they spawn off into separate projects. Case in point -- Neutron rose out of Nova Networking, and is marching on in richness and community support. Common libraries went into Oslo. The Nova scheduler is currently being forklifted into a service of its own called gantt. At the Portland summit such considerations were raised and given that Barbican provides a separate functionality, it does cleanly live in its own project. True the public/private key pair of a service, tenant etc is part of its identity. In that respect Keystone and Barbican would intersect, which could be managed by delegating the storage of the public key in Barbican, like a directory service. Regards Malini -Original Message- From: Jarret Raim [mailto:jarret.r...@rackspace.com] Sent: Tuesday, December 17, 2013 11:36 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] Incubation Request for Barbican On 12/13/13, 7:56 AM, Russell Bryant rbry...@redhat.com wrote: 1) Are each of the items you mention big enough to have a sustainable team that can exist as its own program? The answer here for Barbican and Keystone is yes. 2) Would there be a benefit of *changing* the scope and mission of the Identity program to accomodate a larger problem space? Security sounds too broad ... but I'm sure you see what I'm getting at. Dolph and I have talked about this a bit. Right now, if we combined them, it feels like we would have meetings where the first half would be about Keystone and the second about Barbican. Same for design sessions. The systems and the concerns they address are entirely separate. Currently the teams are also entirely separate. While I think we can encourage both teams to have a close relationship (Adam Young and I had a conversion about that recently), there is no benefit to combining the teams now other than to reduce the number of programs. As the combination doesn¹t help either project, it seems like Barbican having its own program is the best option. When we're talking about authentication, authorization, identity management, key management, key distribution ... these things really *do* seem related enough that it would be *really* nice if a group was looking at all of them and how they fit into the bigger OpenStack picture. I really don't want to see silos for each of these things. I don¹t agree here. Key management and distribution can be used to solve problems in the identity space. They can also be used to solve problems in other spaces in openstack. Barbican uses keystone to provide auth / auth to keys, much like Nova uses keystone to provide auth / auth to servers. Additionally, Barbican will deal with other parts of the encryption space (e.g. SSL) that have very little to do with identity. So, would OpenStack benefit from a tighter relationship between these projects? I think this may be the case, personally. I think there would be benefit to individuals working together from the two projects where it makes sense - especially where we have knowledge overlaps. I don¹t agree that including Barbican in the Identity program is the right way to do that. Could this tighter relationship happen between separate programs? It could, but I think a single program better expresses the intent if that's really what is best. Barbican¹s intent is to simplify key management to enable consuming systems and users to offer or use encryption in their services. This is a fundementally different mission than Keystone has. Jarret ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Incubation Request for Barbican
Barbican, key manager is essential to openstack, paves the way to greater security. Instead of rejecting the project because of its current existence owed so heavily to Rackspace and to John Wood, why not we adopt it, code review, contribute code etc. We can have cores from multiple companies. Swift was a project that was born similarly. During development John Wood and the whole Rackspace team has been open to feature design discussions and providing good code review. Intel plans to create a plugin for Barbican, along the lines of a low cost HSM, essentially using the Intel TXT and the Trusted Platform Module to save a master secret used to encrypt all the other secrets. Our Intel team is small and some of us had other distractions in October and November, but we are back and may even grow in strength. John, Jarret, and team, thank you for all the hard work. Malini -Original Message- From: Jarret Raim [mailto:jarret.r...@rackspace.com] Sent: Tuesday, December 17, 2013 11:44 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] Incubation Request for Barbican On 12/13/13, 4:50 AM, Thierry Carrez thie...@openstack.org wrote: If you remove Jenkins and attach Paul Kehrer, jqxin2006 (Michael Xin), Arash Ghoreyshi, Chad Lung and Steven Gonzales to Rackspace, then the picture is: 67% of commits come from a single person (John Wood) 96% of commits come from a single company (Rackspace) I think that's a bit brittle: if John Wood or Rackspace were to decide to place their bets elsewhere, the project would probably die instantly. I would feel more comfortable if a single individual didn't author more than 50% of the changes, and a single company didn't sponsor more than 80% of the changes. I think these numbers somewhat miss the point. It is true that Rackspace is the primary sponsor of Barbican and that John Wood is the developer that has been on the project the longest. However, % of commits is not the only measure of contributions to the project. That number doesn¹t include the work on our chef-automation scripts or design work to figure out the HSM interfaces or work on the testing suite or writing our documentation or the million other tasks for the project. Rackspace is committed to this project. If John Wood leaves, we¹ll hire additional developers to replace him. There is no risk of the project lacking resources because a single person decides to work on something else. We¹ve seen other folks from HP, RedHat, Nebula, etc. say that they are interested in contributing and we are getting outside contributions today. That will only continue, but I think the risk of the project somehow collapsing is being overstated. There are problems that aren¹t necessarily the sexiest things to work on, but need to be done. It may be hard to get a large number of people interested in such a project in a short period of time. I think it would be a mistake to reject projects that solve important problems just because the team is a bit one sided at the time. Jarret ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Incubation Request for Barbican
++ As someone who has required patches to Barbican (and not affiliated with Rackspace) I can attest to the fact that my, albeit simple, changes have been reviewed and merged in a timely and constructive manner. Even if the project were to bring on a flood of new developers it wouldn't move this commit diversity metric for quite some time. There is already a need for a keystore and I think this need will only grow. So why not support it as its own composable service? Thanks for all the work on Barbican! On Dec 17, 2013 6:17 PM, Bhandaru, Malini K malini.k.bhand...@intel.com wrote: Barbican, key manager is essential to openstack, paves the way to greater security. Instead of rejecting the project because of its current existence owed so heavily to Rackspace and to John Wood, why not we adopt it, code review, contribute code etc. We can have cores from multiple companies. Swift was a project that was born similarly. During development John Wood and the whole Rackspace team has been open to feature design discussions and providing good code review. Intel plans to create a plugin for Barbican, along the lines of a low cost HSM, essentially using the Intel TXT and the Trusted Platform Module to save a master secret used to encrypt all the other secrets. Our Intel team is small and some of us had other distractions in October and November, but we are back and may even grow in strength. John, Jarret, and team, thank you for all the hard work. Malini -Original Message- From: Jarret Raim [mailto:jarret.r...@rackspace.com] Sent: Tuesday, December 17, 2013 11:44 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] Incubation Request for Barbican On 12/13/13, 4:50 AM, Thierry Carrez thie...@openstack.org wrote: If you remove Jenkins and attach Paul Kehrer, jqxin2006 (Michael Xin), Arash Ghoreyshi, Chad Lung and Steven Gonzales to Rackspace, then the picture is: 67% of commits come from a single person (John Wood) 96% of commits come from a single company (Rackspace) I think that's a bit brittle: if John Wood or Rackspace were to decide to place their bets elsewhere, the project would probably die instantly. I would feel more comfortable if a single individual didn't author more than 50% of the changes, and a single company didn't sponsor more than 80% of the changes. I think these numbers somewhat miss the point. It is true that Rackspace is the primary sponsor of Barbican and that John Wood is the developer that has been on the project the longest. However, % of commits is not the only measure of contributions to the project. That number doesn¹t include the work on our chef-automation scripts or design work to figure out the HSM interfaces or work on the testing suite or writing our documentation or the million other tasks for the project. Rackspace is committed to this project. If John Wood leaves, we¹ll hire additional developers to replace him. There is no risk of the project lacking resources because a single person decides to work on something else. We¹ve seen other folks from HP, RedHat, Nebula, etc. say that they are interested in contributing and we are getting outside contributions today. That will only continue, but I think the risk of the project somehow collapsing is being overstated. There are problems that aren¹t necessarily the sexiest things to work on, but need to be done. It may be hard to get a large number of people interested in such a project in a short period of time. I think it would be a mistake to reject projects that solve important problems just because the team is a bit one sided at the time. Jarret ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Incubation Request for Barbican
Russell Bryant wrote: $ git shortlog -s -e | sort -n -r 172John Wood john.w...@rackspace.com 150jfwood john.w...@rackspace.com 65Douglas Mendizabal douglas.mendiza...@rackspace.com 39Jarret Raim jarret.r...@rackspace.com 17Malini K. Bhandaru malini.k.bhand...@intel.com 10Paul Kehrer paul.l.keh...@gmail.com 10Jenkins jenk...@review.openstack.org 8jqxin2006 jqxin2...@gmail.com 7Arash Ghoreyshi arashghorey...@gmail.com 5Chad Lung chad.l...@gmail.com 3Dolph Mathews dolph.math...@gmail.com 2John Vrbanac john.vrba...@rackspace.com 1Steven Gonzales stevendgonza...@gmail.com 1Russell Bryant rbry...@redhat.com 1Bryan D. Payne bdpa...@acm.org It appears to be an effort done by a group, and not an individual. Most commits by far are from Rackspace, but there is at least one non-trivial contributor (Malini) from another company (Intel), so I think this is OK. If you remove Jenkins and attach Paul Kehrer, jqxin2006 (Michael Xin), Arash Ghoreyshi, Chad Lung and Steven Gonzales to Rackspace, then the picture is: 67% of commits come from a single person (John Wood) 96% of commits come from a single company (Rackspace) I think that's a bit brittle: if John Wood or Rackspace were to decide to place their bets elsewhere, the project would probably die instantly. I would feel more comfortable if a single individual didn't author more than 50% of the changes, and a single company didn't sponsor more than 80% of the changes. Personally I think that's a large enough group to make up a Program and gain visibility, but a bit too fragile to enter incubation just now. -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Incubation Request for Barbican
$ git shortlog -s -e | sort -n -r 172 John Wood john.w...@rackspace.com 150 jfwood john.w...@rackspace.com 65 Douglas Mendizabal douglas.mendiza...@rackspace.com 39 Jarret Raim jarret.r...@rackspace.com 17 Malini K. Bhandaru malini.k.bhand...@intel.com 10 Paul Kehrer paul.l.keh...@gmail.com 10 Jenkins jenk...@review.openstack.org 8 jqxin2006 jqxin2...@gmail.com 7 Arash Ghoreyshi arashghorey...@gmail.com 5 Chad Lung chad.l...@gmail.com 3 Dolph Mathews dolph.math...@gmail.com 2 John Vrbanac john.vrba...@rackspace.com 1 Steven Gonzales stevendgonza...@gmail.com 1 Russell Bryant rbry...@redhat.com 1 Bryan D. Payne bdpa...@acm.org It appears to be an effort done by a group, and not an individual. Most commits by far are from Rackspace, but there is at least one non-trivial contributor (Malini) from another company (Intel), so I think this is OK. There has been some interest from some quarters (RedHat, HP and others) in additional support. I hope that the incubation process will help accelerate external contributions. For what it's worth, I just wanted to express my intent to get more involved in Barbican in the near future. I plan to be helping out with both reviews and coding on a variety of pieces. So that will help (a little) with the diversification situation. I would also mention that there has been great interest in Barbican among the OSSG crowd and it wouldn't surprise me to see more people from that group getting involved in the future. Cheers, -bryan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Incubation Request for Barbican
From: Bryan D. Payne [mailto:bdpa...@acm.org] Sent: 12 December 2013 16:12 To: OpenStack Development Mailing List (not for usage questions) Cc: openstack...@lists.openstack.org; cloudkeep@googlegroups. com; barbi...@lists.rackspace.com Subject: Re: [openstack-dev] Incubation Request for Barbican $ git shortlog -s -e | sort -n -r 172 John Wood john.w...@rackspace.com 150 jfwood john.w...@rackspace.com 65 Douglas Mendizabal douglas.mendiza...@rackspace.com 39 Jarret Raim jarret.r...@rackspace.com 17 Malini K. Bhandaru malini.k.bhand...@intel.com 10 Paul Kehrer paul.l.keh...@gmail.com 10 Jenkins jenk...@review.openstack.org 8 jqxin2006 jqxin2...@gmail.com 7 Arash Ghoreyshi arashghorey...@gmail.com 5 Chad Lung chad.l...@gmail.com 3 Dolph Mathews dolph.math...@gmail.com 2 John Vrbanac john.vrba...@rackspace.com 1 Steven Gonzales stevendgonza...@gmail.com 1 Russell Bryant rbry...@redhat.com 1 Bryan D. Payne bdpa...@acm.org It appears to be an effort done by a group, and not an individual. Most commits by far are from Rackspace, but there is at least one non-trivial contributor (Malini) from another company (Intel), so I think this is OK. There has been some interest from some quarters (RedHat, HP and others) in additional support. I hope that the incubation process will help accelerate external contributions. For what it's worth, I just wanted to express my intent to get more involved in Barbican in the near future. I plan to be helping out with both reviews and coding on a variety of pieces. So that will help (a little) with the diversification situation. I would also mention that there has been great interest in Barbican among the OSSG crowd and it wouldn't surprise me to see more people from that group getting involved in the future. Cheers, -bryan Just adding a +1 here from HP. We're very excited about some of the capabilities that Barbican will bring and will be engaging with the development of the project. Cheers, -Rob smime.p7s Description: S/MIME cryptographic signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Incubation Request for Barbican
On 12/04/2013 08:58 AM, Jarret Raim wrote: While I am all for adding a new program, I think we should only add one if we rule out all existing programs as a home. With that in mind why not add this to the keystone program? Perhaps that may require a tweak to keystones mission statement, but that is doable. I saw a partial answer to this somewhere but not a full one. From our point of view, Barbican can certainly help solve some problems related to identity like SSH key management and client certs. However, there is a wide array of functionality that Barbican will handle that is not related to identity. Some examples, there is some additional detail in our application if you want to dig deeper [1]. * Symmetric key management - These keys are used for encryption of data at rest in various places including Swift, Nova, Cinder, etc. Keys are resources that roll up to a project, much like servers or load balancers, but they have no direct relationship to an identity. * SSL / TLS certificates - The management of certificate authorities and the issuance of keys for SSL / TLS. Again, these are resources rather than anything attached to identity. * SSH Key Management - These could certainly be managed through keystone if we think that¹s the right way to go about it, but from Barbican¹s point of view, these are just another type of a key to be generated and tracked that roll up to an identity. * Client certificates - These are most likely tied to an identity, but again, just managed as resources from a Barbican point of view. * Raw Secret Storage - This functionality is usually used by applications residing on an Cloud. An app can use Barbican to store secrets such as sensitive configuration files, encryption keys and the like. This data belongs to the application rather than any particular user in Keystone. For example, some Rackspace customers don¹t allow their application dev / maintenance teams direct access to the Rackspace APIs. * Boot Verification - This functionality is used as part of the trusted boot functionality for transparent disk encryption on Nova. * Randomness Source - Barbican manages HSMs which allow us to offer a source of true randomness. In short (ha), I would encourage everyone to think of keys / certificates as resources managed by an API in much the same way we think of VMs being managed by the Nova API. A consumer of Barbican (either as an OpenStack service or a consumer of an OpenStack cloud) will have an API to create and manage various types of secrets that are owned by their project. My reason for keeping them separate is more practical: the Keystone team is already somewhat overloaded. I know that a couple of us have interest in contributing to Barbican, the question is time and prioritization. Unless there is some benefit to having both projects in the same program with essentially different teams, I think Barbican should proceed as is. I personally plan on contributing to Barbican. Keystone plays a critical role for us (as it does with every service) in authenticating the user to a particular project and storing the roles that the user has for that project. Barbican then enforces these restrictions. However, keys / secrets are fundamentally divorced from identities in much the same way that databases in Trove are, they are owned by a project, not a particular user. Hopefully our thought process makes some sense, let me know if I can provide more detail. Jarret [1] https://wiki.openstack.org/wiki/Barbican/Incubation ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Incubation Request for Barbican
On Thu, Dec 12, 2013 at 2:58 PM, Adam Young ayo...@redhat.com wrote: On 12/04/2013 08:58 AM, Jarret Raim wrote: While I am all for adding a new program, I think we should only add one if we rule out all existing programs as a home. With that in mind why not add this to the keystone program? Perhaps that may require a tweak to keystones mission statement, but that is doable. I saw a partial answer to this somewhere but not a full one. From our point of view, Barbican can certainly help solve some problems related to identity like SSH key management and client certs. However, there is a wide array of functionality that Barbican will handle that is not related to identity. Some examples, there is some additional detail in our application if you want to dig deeper [1]. * Symmetric key management - These keys are used for encryption of data at rest in various places including Swift, Nova, Cinder, etc. Keys are resources that roll up to a project, much like servers or load balancers, but they have no direct relationship to an identity. * SSL / TLS certificates - The management of certificate authorities and the issuance of keys for SSL / TLS. Again, these are resources rather than anything attached to identity. * SSH Key Management - These could certainly be managed through keystone if we think that¹s the right way to go about it, but from Barbican¹s point of view, these are just another type of a key to be generated and tracked that roll up to an identity. * Client certificates - These are most likely tied to an identity, but again, just managed as resources from a Barbican point of view. * Raw Secret Storage - This functionality is usually used by applications residing on an Cloud. An app can use Barbican to store secrets such as sensitive configuration files, encryption keys and the like. This data belongs to the application rather than any particular user in Keystone. For example, some Rackspace customers don¹t allow their application dev / maintenance teams direct access to the Rackspace APIs. * Boot Verification - This functionality is used as part of the trusted boot functionality for transparent disk encryption on Nova. * Randomness Source - Barbican manages HSMs which allow us to offer a source of true randomness. In short (ha), I would encourage everyone to think of keys / certificates as resources managed by an API in much the same way we think of VMs being managed by the Nova API. A consumer of Barbican (either as an OpenStack service or a consumer of an OpenStack cloud) will have an API to create and manage various types of secrets that are owned by their project. My reason for keeping them separate is more practical: the Keystone team is already somewhat overloaded. I know that a couple of us have interest in contributing to Barbican, the question is time and prioritization. Unless there is some benefit to having both projects in the same program with essentially different teams, I think Barbican should proceed as is. I personally plan on contributing to Barbican. /me puts PTL hat on ++ I don't want Russel's job. Keystone has a fairly narrow mission statement in my mind (come to think of it, I need to propose it to governance..), and that's basically to abstract away the problem of authenticating and authorizing the API users of other openstack services. Everything else, including identity management, key management, key distribution, quotas, etc, is just secondary fodder that we tend to help with along the way... but they should be first class problems in someone else's mind. If we rolled everything together that kind of looks related to keystone under a big keystone program for the sake of organizational tidiness, I know I would be less effective as a PTL and that's a bit disheartening. That said, I'm always happy to help where I can. Keystone plays a critical role for us (as it does with every service) in authenticating the user to a particular project and storing the roles that the user has for that project. Barbican then enforces these restrictions. However, keys / secrets are fundamentally divorced from identities in much the same way that databases in Trove are, they are owned by a project, not a particular user. Hopefully our thought process makes some sense, let me know if I can provide more detail. Jarret [1] https://wiki.openstack.org/wiki/Barbican/Incubation ___ OpenStack-dev mailing listOpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- -Dolph ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org
Re: [openstack-dev] Incubation Request for Barbican
On December 12, 2013 at 14:32:36, Dolph Mathews (dolph.math...@gmail.com) wrote: On Thu, Dec 12, 2013 at 2:58 PM, Adam Young ayo...@redhat.com wrote: On 12/04/2013 08:58 AM, Jarret Raim wrote: While I am all for adding a new program, I think we should only add one if we rule out all existing programs as a home. With that in mind why not add this to the keystone program? Perhaps that may require a tweak to keystones mission statement, but that is doable. I saw a partial answer to this somewhere but not a full one. From our point of view, Barbican can certainly help solve some problems related to identity like SSH key management and client certs. However, there is a wide array of functionality that Barbican will handle that is not related to identity. Some examples, there is some additional detail in our application if you want to dig deeper [1]. * Symmetric key management - These keys are used for encryption of data at rest in various places including Swift, Nova, Cinder, etc. Keys are resources that roll up to a project, much like servers or load balancers, but they have no direct relationship to an identity. * SSL / TLS certificates - The management of certificate authorities and the issuance of keys for SSL / TLS. Again, these are resources rather than anything attached to identity. * SSH Key Management - These could certainly be managed through keystone if we think that¹s the right way to go about it, but from Barbican¹s point of view, these are just another type of a key to be generated and tracked that roll up to an identity. * Client certificates - These are most likely tied to an identity, but again, just managed as resources from a Barbican point of view. * Raw Secret Storage - This functionality is usually used by applications residing on an Cloud. An app can use Barbican to store secrets such as sensitive configuration files, encryption keys and the like. This data belongs to the application rather than any particular user in Keystone. For example, some Rackspace customers don¹t allow their application dev / maintenance teams direct access to the Rackspace APIs. * Boot Verification - This functionality is used as part of the trusted boot functionality for transparent disk encryption on Nova. * Randomness Source - Barbican manages HSMs which allow us to offer a source of true randomness. In short (ha), I would encourage everyone to think of keys / certificates as resources managed by an API in much the same way we think of VMs being managed by the Nova API. A consumer of Barbican (either as an OpenStack service or a consumer of an OpenStack cloud) will have an API to create and manage various types of secrets that are owned by their project. My reason for keeping them separate is more practical: the Keystone team is already somewhat overloaded. I know that a couple of us have interest in contributing to Barbican, the question is time and prioritization. Unless there is some benefit to having both projects in the same program with essentially different teams, I think Barbican should proceed as is. I personally plan on contributing to Barbican. /me puts PTL hat on ++ I don't want Russel's job. Keystone has a fairly narrow mission statement in my mind (come to think of it, I need to propose it to governance..), and that's basically to abstract away the problem of authenticating and authorizing the API users of other openstack services. Everything else, including identity management, key management, key distribution, quotas, etc, is just secondary fodder that we tend to help with along the way... but they should be first class problems in someone else's mind. If we rolled everything together that kind of looks related to keystone under a big keystone program for the sake of organizational tidiness, I know I would be less effective as a PTL and that's a bit disheartening. That said, I'm always happy to help where I can. The long and the short of it is that I can’t argue that Barbican couldn’t be considered a mechanism of “Identity” (in most everything keys end up being a form of Identity, and the management of that would fit nicely under the “Identity Program”). That being said I also can’t argue that Barbican shouldn’t be it’s own top-level program. It comes down to the best fit for OpenStack as a whole. From a deployer standpoint, I don’t think it will make any real difference if Barbican is in Identity or it’s own program. Basically, it’ll be a separate process to run in either case. It will have it’s own rules and quirks. From a developer standpoint, I don’t think it will make a significant difference (besides, perhaps where documentation lies). The contributors to Keystone will contribute (or not) to Barbican and vice-versa based upon interest/time/needs. From a community and communication standpoint (which is the important part here), I think it comes down to messaging and what Barbican is meant to be. If we are happy messaging
Re: [openstack-dev] Incubation Request for Barbican
I'd like to look at keeping things simple when they can be simple. I need to understand why there¹s already a key distribution service under keystone? https://review.openstack.org/#/c/40692/18/openstack-identity-api/v3/src/ma rkdown/identity-api-v3-os-kds-ext.md I¹ve said before that I think the KDS more properly belongs in Barbican rather than Keystone. There is a thread on this list detailing other people¹s thoughts on the issue. I think the issue boiled down to two main concerns. First, some are concerned / resistant about having to install another service. Second, Barbican is going through our incubation process right now. Some felt that they didn¹t wan to wait and that Keystone was the shorter path. There could be two ways of looking at this - is Identity changing their scope? Or is an incubating project trying to take work away from an existing program? Not sure. I mostly just want to know who is best served by a new code base getting incubated under our defined umbrella. Dolph can better answer the question about scope, but I think the KDS going into Keystone is a matter of expediency rather than best fit. As I¹ve mentioned before, Keystone will use Barbican to satisfy some of their requirements, but key management is a fundamentally separate process from identity management. I agree that Barbican solves different problems than identity, and we need to figure out the motivations for the seeming pressing need to differentiate from keystone-the-project. There's autonomy, gathering your own team, and probably other reasons. Can you expand on your need for pursuing this incubation route? I sent out a mail to this list of the types of things that Barbican will tackle that have nothing to do with identity. These processes are fundamentally different than those in Keystone and the Keystone functionality is completely separate from anything that Barbican will do. There have been several folks asking this questions and I¹m honestly confused where the desire to push the two projects together is coming from. Can someone be more specific about why they think these two projects overlap? Is it solely because they both have to do with security? Or is there something else? I do realize we are clarifying our incubation route, so partially we need to explore the incubation under an existing² possibility and pros and cons. I'm doing something unofficial with the training group, for example. There are certainly pros and cons there. But I don't want to muddy the waters with that discussion, I want to hear from Barbican about your explorations of collaborating with Keystone and your motivations for wanting a separate application. This certainly sounds like a good idea, but I don¹t think it applies to the Barbican / Keystone projects. Thanks, Jarret smime.p7s Description: S/MIME cryptographic signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Incubation Request for Barbican
While I am all for adding a new program, I think we should only add one if we rule out all existing programs as a home. With that in mind why not add this to the keystone program? Perhaps that may require a tweak to keystones mission statement, but that is doable. I saw a partial answer to this somewhere but not a full one. From our point of view, Barbican can certainly help solve some problems related to identity like SSH key management and client certs. However, there is a wide array of functionality that Barbican will handle that is not related to identity. Some examples, there is some additional detail in our application if you want to dig deeper [1]. * Symmetric key management - These keys are used for encryption of data at rest in various places including Swift, Nova, Cinder, etc. Keys are resources that roll up to a project, much like servers or load balancers, but they have no direct relationship to an identity. * SSL / TLS certificates - The management of certificate authorities and the issuance of keys for SSL / TLS. Again, these are resources rather than anything attached to identity. * SSH Key Management - These could certainly be managed through keystone if we think that¹s the right way to go about it, but from Barbican¹s point of view, these are just another type of a key to be generated and tracked that roll up to an identity. * Client certificates - These are most likely tied to an identity, but again, just managed as resources from a Barbican point of view. * Raw Secret Storage - This functionality is usually used by applications residing on an Cloud. An app can use Barbican to store secrets such as sensitive configuration files, encryption keys and the like. This data belongs to the application rather than any particular user in Keystone. For example, some Rackspace customers don¹t allow their application dev / maintenance teams direct access to the Rackspace APIs. * Boot Verification - This functionality is used as part of the trusted boot functionality for transparent disk encryption on Nova. * Randomness Source - Barbican manages HSMs which allow us to offer a source of true randomness. In short (ha), I would encourage everyone to think of keys / certificates as resources managed by an API in much the same way we think of VMs being managed by the Nova API. A consumer of Barbican (either as an OpenStack service or a consumer of an OpenStack cloud) will have an API to create and manage various types of secrets that are owned by their project. Keystone plays a critical role for us (as it does with every service) in authenticating the user to a particular project and storing the roles that the user has for that project. Barbican then enforces these restrictions. However, keys / secrets are fundamentally divorced from identities in much the same way that databases in Trove are, they are owned by a project, not a particular user. Hopefully our thought process makes some sense, let me know if I can provide more detail. Jarret [1] https://wiki.openstack.org/wiki/Barbican/Incubation smime.p7s Description: S/MIME cryptographic signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Incubation Request for Barbican
Jarret Raim wrote: The TC is currently working on formalizing requirements for new programs and projects [3]. I figured I would give them a try against this application. First, I'm assuming that the application is for a new program that contains the new project. The application doesn't make that bit clear, though. In looking through the documentation for incubating [1], there doesn¹t seem to be any mention of also having to be associated with a program. Is it a requirement that all projects belong to a program at this point? If so, I guess we would be asking for a new program as I think that encryption and key management is a separate concern from the rest of the programs listed here [2]. [1] https://wiki.openstack.org/wiki/Governance/NewProjects [2] https://wiki.openstack.org/wiki/Programs With the introduction of programs (think: official teams), all incubated/integrated projects must belong to an official program... So when a project applies for incubation but is not part of an official program yet, it de-facto also applies to be considered a program. [...] ** Team should have a lead, elected by the team contributors Was the PTL elected? I can't seem to find record of that. If not, I would like to see an election held for the PTL. We¹re happy to do an election. Is this something we can do as part of the next election cycle? Or something that needs to be done out of band? I'm not 100% sure we'll keep that election requirement. I think the program application should have an initial PTL named on it. The way that's determined is up to the team (natural candidate, election...). ** Team should have a clear way to grant ATC (voting) status to its significant contributors Related to the above I thought that the process of becoming an ATC was pretty well set [3]. Is there some specific that Barbican would have to do that is different than the ATC rules in the Tech Committee documentation? [3] https://wiki.openstack.org/wiki/Governance/Foundation/TechnicalCommittee No, since the team produces code the ATC designation method is pretty well established. This rule cares for programs which have weirder deliverables. -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Incubation Request for Barbican
With the introduction of programs (think: official teams), all incubated/integrated projects must belong to an official program... So when a project applies for incubation but is not part of an official program yet, it de-facto also applies to be considered a program. Ahh, understood. So I guess we'd be asking for a new program then. I'm not 100% sure we'll keep that election requirement. I think the program application should have an initial PTL named on it. The way that's determined is up to the team (natural candidate, election...). It sounds like if we have a PTL election as part of the normal Icehouse schedule, we should be covered here? No, since the team produces code the ATC designation method is pretty well established. This rule cares for programs which have weirder deliverables. Easy enough, thanks for the clarification. Jarret ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Incubation Request for Barbican
On Dec 3, 2013 6:45 PM, Jarret Raim jarret.r...@rackspace.com wrote: With the introduction of programs (think: official teams), all incubated/integrated projects must belong to an official program... So when a project applies for incubation but is not part of an official program yet, it de-facto also applies to be considered a program. Ahh, understood. So I guess we'd be asking for a new program then. While I am all for adding a new program, I think we should only add one if we rule out all existing programs as a home. With that in mind why not add this to the keystone program? Perhaps that may require a tweak to keystones mission statement, but that is doable. I saw a partial answer to this somewhere but not a full one. I'm not 100% sure we'll keep that election requirement. I think the program application should have an initial PTL named on it. The way that's determined is up to the team (natural candidate, election...). It sounds like if we have a PTL election as part of the normal Icehouse schedule, we should be covered here? No, since the team produces code the ATC designation method is pretty well established. This rule cares for programs which have weirder deliverables. Easy enough, thanks for the clarification. Jarret ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Incubation Request for Barbican
On 12/02/2013 10:19 AM, Jarret Raim wrote: All, Barbican is the OpenStack key management service and we’d like to request incubation for the Icehouse release. A Rackspace sponsored team has been working for about 9 months now, including following the Havana release cycle for our first release. Our incubation request is here: https://wiki.openstack.org/wiki/Barbican Our documentation is mostly hosted at GitHub for the moment, though we are in the process of converting much of it to DocBook. https://github.com/cloudkeep/barbican https://github.com/cloudkeep/barbican/wiki The Barbican team will be on IRC today at #openstack-barbican and you can contact us using the barbi...@lists.rackspace.com mailing list if desired. The TC is currently working on formalizing requirements for new programs and projects [3]. I figured I would give them a try against this application. First, I'm assuming that the application is for a new program that contains the new project. The application doesn't make that bit clear, though. Teams in OpenStack can be created as-needed and grow organically. As the team work matures, some technical efforts will be recognized as essential to the completion of the OpenStack project mission. By becoming an official Program, they place themselves under the authority of the OpenStack Technical Committee. In return, their contributors get to vote in the Technical Committee election, and they get some space and time to discuss future development at our Design Summits. When considering new programs, the TC will look into a number of criteria, including (but not limited to): * Scope ** Team must have a specific scope, separated from others teams scope I would like to see a statement of scope for Barbican on the application. It should specifically cover how the scope differs from other programs, in particular the Identity program. ** Team must have a mission statement This is missing. * Maturity ** Team must already exist, have regular meetings and produce some work This seems covered. ** Team should have a lead, elected by the team contributors Was the PTL elected? I can't seem to find record of that. If not, I would like to see an election held for the PTL. ** Team should have a clear way to grant ATC (voting) status to its significant contributors Related to the above * Deliverables ** Team should have a number of clear deliverables barbican and python-barbicanclient, I presume. It would be nice to have this clearly defined on the application. Now, for the project specific requirements: Projects wishing to be included in the integrated release of OpenStack must first apply for incubation status. During their incubation period, they will be able to access new resources and tap into other OpenStack programs (in particular the Documentation, QA, Infrastructure and Release management teams) to learn about the OpenStack processes and get assistance in their integration efforts. The TC will evaluate the project scope and its complementarity with existing integrated projects and other official programs, look into the project technical choices, and check a number of requirements, including (but not limited to): * Scope ** Project must have a clear and defined scope This is missing ** Project should not inadvertently duplicate functionality present in other OpenStack projects. If they do, they should have a clear plan and timeframe to prevent long-term scope duplication. ** Project should leverage existing functionality in other OpenStack projects as much as possible I'm going to hold off on diving into this too far until the scope is clarified. * Maturity ** Project should have a diverse and active team of contributors Using a mailmap file [4]: $ git shortlog -s -e | sort -n -r 172 John Wood john.w...@rackspace.com 150 jfwood john.w...@rackspace.com 65 Douglas Mendizabal douglas.mendiza...@rackspace.com 39 Jarret Raim jarret.r...@rackspace.com 17 Malini K. Bhandaru malini.k.bhand...@intel.com 10 Paul Kehrer paul.l.keh...@gmail.com 10 Jenkins jenk...@review.openstack.org 8 jqxin2006 jqxin2...@gmail.com 7 Arash Ghoreyshi arashghorey...@gmail.com 5 Chad Lung chad.l...@gmail.com 3 Dolph Mathews dolph.math...@gmail.com 2 John Vrbanac john.vrba...@rackspace.com 1 Steven Gonzales stevendgonza...@gmail.com 1 Russell Bryant rbry...@redhat.com 1 Bryan D. Payne bdpa...@acm.org It appears to be an effort done by a group, and not an individual. Most commits by far are from Rackspace, but there is at least one non-trivial contributor (Malini) from another company (Intel), so I think this is OK. ** Project should not have a major architectural rewrite planned. API should be reasonably stable. Thoughts from the Barbican team on this? * Process ** Project must be hosted under stackforge
Re: [openstack-dev] Incubation Request for Barbican
On 12/02/2013 11:53 AM, Russell Bryant wrote: ** Project must have no library dependencies which effectively restrict how the project may be distributed [1] http://git.openstack.org/cgit/stackforge/barbican/tree/tools/pip-requires It looks like the only item here not in the global requirements is Celery, which is licensed under a 3-clause BSD license. https://github.com/celery/celery/blob/master/LICENSE A notable point is this clause: * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. I'm not sure if we have other dependencies using this license already. It's also not clear how to interpret this when Python is always distributed as source. We can take this up on the legal-discuss mailing list. If you have comments on this point, please jump over to the legal-discuss list and respond to this thread: http://lists.openstack.org/pipermail/legal-discuss/2013-December/000106.html We can post the outcome back to the -dev list once that thread reaches a conclusion. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Incubation Request for Barbican
The TC is currently working on formalizing requirements for new programs and projects [3]. I figured I would give them a try against this application. First, I'm assuming that the application is for a new program that contains the new project. The application doesn't make that bit clear, though. In looking through the documentation for incubating [1], there doesn¹t seem to be any mention of also having to be associated with a program. Is it a requirement that all projects belong to a program at this point? If so, I guess we would be asking for a new program as I think that encryption and key management is a separate concern from the rest of the programs listed here [2]. [1] https://wiki.openstack.org/wiki/Governance/NewProjects [2] https://wiki.openstack.org/wiki/Programs Teams in OpenStack can be created as-needed and grow organically. As the team work matures, some technical efforts will be recognized as essential to the completion of the OpenStack project mission. By becoming an official Program, they place themselves under the authority of the OpenStack Technical Committee. In return, their contributors get to vote in the Technical Committee election, and they get some space and time to discuss future development at our Design Summits. When considering new programs, the TC will look into a number of criteria, including (but not limited to): * Scope ** Team must have a specific scope, separated from others teams scope I would like to see a statement of scope for Barbican on the application. It should specifically cover how the scope differs from other programs, in particular the Identity program. Happy to add this, I¹ll put it in the wiki today. ** Team must have a mission statement This is missing. We do have a mission statement on the Barbican/Incubation page here: https://wiki.openstack.org/wiki/Barbican/Incubation ** Team should have a lead, elected by the team contributors Was the PTL elected? I can't seem to find record of that. If not, I would like to see an election held for the PTL. We¹re happy to do an election. Is this something we can do as part of the next election cycle? Or something that needs to be done out of band? ** Team should have a clear way to grant ATC (voting) status to its significant contributors Related to the above I thought that the process of becoming an ATC was pretty well set [3]. Is there some specific that Barbican would have to do that is different than the ATC rules in the Tech Committee documentation? [3] https://wiki.openstack.org/wiki/Governance/Foundation/TechnicalCommittee * Deliverables ** Team should have a number of clear deliverables barbican and python-barbicanclient, I presume. It would be nice to have this clearly defined on the application. I will add a deliverables section, but you are correct. Now, for the project specific requirements: Projects wishing to be included in the integrated release of OpenStack must first apply for incubation status. During their incubation period, they will be able to access new resources and tap into other OpenStack programs (in particular the Documentation, QA, Infrastructure and Release management teams) to learn about the OpenStack processes and get assistance in their integration efforts. The TC will evaluate the project scope and its complementarity with existing integrated projects and other official programs, look into the project technical choices, and check a number of requirements, including (but not limited to): * Scope ** Project must have a clear and defined scope This is missing As mentioned above, I¹ll add this to the wiki today. ** Project should not inadvertently duplicate functionality present in other OpenStack projects. If they do, they should have a clear plan and timeframe to prevent long-term scope duplication. ** Project should leverage existing functionality in other OpenStack projects as much as possible I'm going to hold off on diving into this too far until the scope is clarified. * Maturity ** Project should have a diverse and active team of contributors Using a mailmap file [4]: $ git shortlog -s -e | sort -n -r 172 John Wood john.w...@rackspace.com 150 jfwood john.w...@rackspace.com 65 Douglas Mendizabal douglas.mendiza...@rackspace.com 39 Jarret Raim jarret.r...@rackspace.com 17 Malini K. Bhandaru malini.k.bhand...@intel.com 10 Paul Kehrer paul.l.keh...@gmail.com 10 Jenkins jenk...@review.openstack.org 8 jqxin2006 jqxin2...@gmail.com 7 Arash Ghoreyshi arashghorey...@gmail.com 5 Chad Lung chad.l...@gmail.com 3 Dolph Mathews dolph.math...@gmail.com 2 John Vrbanac john.vrba...@rackspace.com 1 Steven Gonzales stevendgonza...@gmail.com 1 Russell Bryant rbry...@redhat.com 1 Bryan D. Payne bdpa...@acm.org It appears to be an effort done by a group, and not an individual. Most commits by far are from Rackspace, but
Re: [openstack-dev] Incubation Request for Barbican
On 12/02/2013 04:12 PM, Jarret Raim wrote: The TC is currently working on formalizing requirements for new programs and projects [3]. I figured I would give them a try against this application. First, I'm assuming that the application is for a new program that contains the new project. The application doesn't make that bit clear, though. In looking through the documentation for incubating [1], there doesn¹t seem to be any mention of also having to be associated with a program. Is it a requirement that all projects belong to a program at this point? If so, I guess we would be asking for a new program as I think that encryption and key management is a separate concern from the rest of the programs listed here [2]. [1] https://wiki.openstack.org/wiki/Governance/NewProjects [2] https://wiki.openstack.org/wiki/Programs Teams in OpenStack can be created as-needed and grow organically. As the team work matures, some technical efforts will be recognized as essential to the completion of the OpenStack project mission. By becoming an official Program, they place themselves under the authority of the OpenStack Technical Committee. In return, their contributors get to vote in the Technical Committee election, and they get some space and time to discuss future development at our Design Summits. When considering new programs, the TC will look into a number of criteria, including (but not limited to): * Scope ** Team must have a specific scope, separated from others teams scope I would like to see a statement of scope for Barbican on the application. It should specifically cover how the scope differs from other programs, in particular the Identity program. Happy to add this, I¹ll put it in the wiki today. ** Team must have a mission statement This is missing. We do have a mission statement on the Barbican/Incubation page here: https://wiki.openstack.org/wiki/Barbican/Incubation ** Team should have a lead, elected by the team contributors Was the PTL elected? I can't seem to find record of that. If not, I would like to see an election held for the PTL. We¹re happy to do an election. Is this something we can do as part of the next election cycle? Or something that needs to be done out of band? ** Team should have a clear way to grant ATC (voting) status to its significant contributors Related to the above I thought that the process of becoming an ATC was pretty well set [3]. Is there some specific that Barbican would have to do that is different than the ATC rules in the Tech Committee documentation? [3] https://wiki.openstack.org/wiki/Governance/Foundation/TechnicalCommittee * Deliverables ** Team should have a number of clear deliverables barbican and python-barbicanclient, I presume. It would be nice to have this clearly defined on the application. I will add a deliverables section, but you are correct. Now, for the project specific requirements: Projects wishing to be included in the integrated release of OpenStack must first apply for incubation status. During their incubation period, they will be able to access new resources and tap into other OpenStack programs (in particular the Documentation, QA, Infrastructure and Release management teams) to learn about the OpenStack processes and get assistance in their integration efforts. The TC will evaluate the project scope and its complementarity with existing integrated projects and other official programs, look into the project technical choices, and check a number of requirements, including (but not limited to): * Scope ** Project must have a clear and defined scope This is missing As mentioned above, I¹ll add this to the wiki today. ** Project should not inadvertently duplicate functionality present in other OpenStack projects. If they do, they should have a clear plan and timeframe to prevent long-term scope duplication. ** Project should leverage existing functionality in other OpenStack projects as much as possible I'm going to hold off on diving into this too far until the scope is clarified. * Maturity ** Project should have a diverse and active team of contributors Using a mailmap file [4]: $ git shortlog -s -e | sort -n -r 172John Wood john.w...@rackspace.com 150jfwood john.w...@rackspace.com 65Douglas Mendizabal douglas.mendiza...@rackspace.com 39Jarret Raim jarret.r...@rackspace.com 17Malini K. Bhandaru malini.k.bhand...@intel.com 10Paul Kehrer paul.l.keh...@gmail.com 10Jenkins jenk...@review.openstack.org 8jqxin2006 jqxin2...@gmail.com 7Arash Ghoreyshi arashghorey...@gmail.com 5Chad Lung chad.l...@gmail.com 3Dolph Mathews dolph.math...@gmail.com 2John Vrbanac john.vrba...@rackspace.com 1Steven Gonzales
Re: [openstack-dev] Incubation Request for Barbican
Uses tox, but not pbr or global requirements I added a ŒTasks¹ section for stuff we need to do from this review and I¹ve added these tasks. [4] [4] https://wiki.openstack.org/wiki/Barbican/Incubation Awesome. Also, if you don't mind - we should add testr to that list. We're looking at some things in infra that will need the subunit processing. Added that to our list. Jarret ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
