Re: [openstack-dev] Barbican Incubation Review
Jarret Raim wrote: Barbican, the key management service for OpenStack, requested incubation before the holidays. After the initial review, there were several issues brought up by various individuals that needed to be resolved pre-incubation. At this point, we have completed the work on those tasks. I'd like to request a final review before a vote on our incubation at the next TC meeting, which should be on 2/4. The list of tasks and their status is documented as part of our incubation request, which is on the openstack wiki: https://wiki.openstack.org/wiki/Barbican/Incubation In preparation for the meeting later today, you could also prepare an etherpad describing where you currently stand compared to incubation requirements as described in the governance repo[1]. That will help speed up your review. [1] http://git.openstack.org/cgit/openstack/governance/tree/reference/incubation-integration-requirements -- 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] Barbican Incubation Review
I spun one up here https://etherpad.openstack.org/p/GFoJ4LpK8A Most of the questions are on our incubation wiki, but I answered each of the issues from the page you linked. Thanks, -- Jarret Raim @jarretraim On 2/4/14, 7:45 AM, Thierry Carrez thie...@openstack.org wrote: Jarret Raim wrote: Barbican, the key management service for OpenStack, requested incubation before the holidays. After the initial review, there were several issues brought up by various individuals that needed to be resolved pre-incubation. At this point, we have completed the work on those tasks. I'd like to request a final review before a vote on our incubation at the next TC meeting, which should be on 2/4. The list of tasks and their status is documented as part of our incubation request, which is on the openstack wiki: https://wiki.openstack.org/wiki/Barbican/Incubation In preparation for the meeting later today, you could also prepare an etherpad describing where you currently stand compared to incubation requirements as described in the governance repo[1]. That will help speed up your review. [1] http://git.openstack.org/cgit/openstack/governance/tree/reference/incubati on-integration-requirements -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 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] Barbican Incubation Review
On Wed, Jan 29, 2014 at 3:28 PM, Justin Santa Barbara jus...@fathomdb.com wrote: Jarret Raim wrote: I'm presuming that this is our last opportunity for API review - if this isn't the right occasion to bring this up, ignore me! Apparently you are right: For incubation 'Project APIs should be reasonably stable' http://git.openstack.org/cgit/openstack/governance/tree/reference/incubation-integration-requirements#n23 And there is nothing about APIs in graduation. I wouldn't agree here. The barbican API will be evolving over time as we add new functionality. We will, of course, have to deal with backwards compatibility and version as we do so. I suggest that writing bindings for every major language, maintaining them through API revisions, and dealing with all the software that depends on your service is a much bigger undertaking than e.g. writing Barbican itself ;-) So it seems much more efficient to get v1 closer to right. I don't think this need turn into a huge upfront design project either; I'd just like to see the TC approve your project with an API that the PTLs have signed off on as meeting their known needs, rather than one that we know will need changes. Better to delay take-off than commit ourselves to rebuilding the engine in mid-flight. We don't need the functionality to be implemented in your first release, but the API should allow the known upcoming changes. We're also looking at adopting the model that Keystone uses for API blueprints where the API changes are separate blueprints that are reviewed by a larger group than the implementations. I think you should aspire to something greater than the adoption of Keystone V3. I'm sorry to pick on your project - I think it is much more important to OpenStack than many others, though that's a big part of why it is important to avoid API churn. The instability of our APIs is a huge barrier to OpenStack adoption. I'd love to see the TC review all breaking API changes, but I don't think we're set up that way. Justin ___ 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
[openstack-dev] Barbican Incubation Review
This is a follow-up to Jarret Raim's email regarding Barbican's incubation review: http://lists.openstack.org/pipermail/openstack-dev/2014-January/025860.html Please note that the PR for Barbican's DevStack integration can now be found here: https://review.openstack.org/#/c/70512/ Thanks for any feedback or comments. Chad Lung ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Barbican Incubation Review
All, Barbican, the key management service for OpenStack, requested incubation before the holidays. After the initial review, there were several issues brought up by various individuals that needed to be resolved pre-incubation. At this point, we have completed the work on those tasks. I'd like to request a final review before a vote on our incubation at the next TC meeting, which should be on 2/4. The list of tasks and their status is documented as part of our incubation request, which is on the openstack wiki: https://wiki.openstack.org/wiki/Barbican/Incubation The only outstanding PR on the list is our devstack integration. I'd love it if we could get some eyes on that patch. Things seem to be working for us in our testing, but it'd be great to get some feedback from -infra to make sure we aren¹t going to cause any headaches for the gate. The review is here: https://review.openstack.org/#/c/69962 During our initial request, there was a conversation about our being a mostly Rackspace driven effort. While it was decided that diversifying the team isn't a requirement for incubation, it is for integration and we've made some headway on that effort. At this point, we have external contributors from eVault, HP and RedHat that have submitted code and / or blueprints for the system. There are other folks that have expressed interest in contributing, so I'm hopeful that our team will continue to diversify over the course of our incubation period. Our general page is here: https://wiki.openstack.org/wiki/Barbican Our GitHub documentation: https://github.com/cloudkeep/barbican https://github.com/cloudkeep/barbican/wiki We are currently working on moving this documentation to the OpenStack standard docbook format. We have a ways to go on this front, but the staging area for that work can be found here: http://docs.cloudkeep.io/barbican-devguide/content/preface.html The team hangs out in the #openstack-barbican channel on freenode. If you want to talk, stop on by. Thanks, Jarret Raim 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] Barbican Incubation Review
Given the issues we continue to face with achieving stable APIs, I hope there will be some form of formal API review before we approve any new OpenStack APIs. When we release an API, it should mean that we're committing to support that API _forever_. Glancing at the specification, I noticed some API issues that will be hard to fix: * the API for asymmetric keys (i.e. keys with a public and private part) has not yet been fleshed out * there does not appear to be support for key rotation * I don't see metadata or tags or some other way for API consumers to attach extra information they might need * cypher_type is spelled in the less common way The first two are deal-breakers IMHO for a 1.0. #3 is a straight extension, so could be added later, but I think it an important safety valve in case anything else got missed. #4 will probably cause the most argument :-) Everyone is looking forward to the better security that Barbican will bring, so I think it all the more important that we avoid a rapid v2.0 and the pain that brings to everyone. I would hope that the PTLs of all projects that are going to offer encryption review the proposed API to make sure that it meets their project's future requirements. I'm presuming that this is our last opportunity for API review - if this isn't the right occasion to bring this up, ignore me! Justin ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Barbican Incubation Review
On Wed, Jan 29, 2014 at 2:42 PM, Jarret Raim jarret.r...@rackspace.comwrote: All, Barbican, the key management service for OpenStack, requested incubation before the holidays. After the initial review, there were several issues brought up by various individuals that needed to be resolved pre-incubation. At this point, we have completed the work on those tasks. I'd like to request a final review before a vote on our incubation at the next TC meeting, which should be on 2/4. The list of tasks and their status is documented as part of our incubation request, which is on the openstack wiki: https://wiki.openstack.org/wiki/Barbican/Incubation The only outstanding PR on the list is our devstack integration. I'd love it if we could get some eyes on that patch. Things seem to be working for us in our testing, but it'd be great to get some feedback from -infra to make sure we aren¹t going to cause any headaches for the gate. The review is here: https://review.openstack.org/#/c/69962 During our initial request, there was a conversation about our being a mostly Rackspace driven effort. While it was decided that diversifying the team isn't a requirement for incubation, it is for integration and we've made some headway on that effort. At this point, we have external contributors from eVault, HP and RedHat that have submitted code and / or blueprints for the system. There are other folks that have expressed interest in contributing, so I'm hopeful that our team will continue to diversify over the course of our incubation period. Our general page is here: https://wiki.openstack.org/wiki/Barbican Our GitHub documentation: https://github.com/cloudkeep/barbican https://github.com/cloudkeep/barbican/wiki We are currently working on moving this documentation to the OpenStack standard docbook format. We have a ways to go on this front, but the staging area for that work can be found here: http://docs.cloudkeep.io/barbican-devguide/content/preface.html Hi Jarret - Please don't use the OpenStack branding on your output prior to permission through this process. Thanks, Anne The team hangs out in the #openstack-barbican channel on freenode. If you want to talk, stop on by. Thanks, Jarret Raim ___ 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] Barbican Incubation Review
Jarret Raim wrote: I'm presuming that this is our last opportunity for API review - if this isn't the right occasion to bring this up, ignore me! I wouldn't agree here. The barbican API will be evolving over time as we add new functionality. We will, of course, have to deal with backwards compatibility and version as we do so. I suggest that writing bindings for every major language, maintaining them through API revisions, and dealing with all the software that depends on your service is a much bigger undertaking than e.g. writing Barbican itself ;-) So it seems much more efficient to get v1 closer to right. I don't think this need turn into a huge upfront design project either; I'd just like to see the TC approve your project with an API that the PTLs have signed off on as meeting their known needs, rather than one that we know will need changes. Better to delay take-off than commit ourselves to rebuilding the engine in mid-flight. We don't need the functionality to be implemented in your first release, but the API should allow the known upcoming changes. We're also looking at adopting the model that Keystone uses for API blueprints where the API changes are separate blueprints that are reviewed by a larger group than the implementations. I think you should aspire to something greater than the adoption of Keystone V3. I'm sorry to pick on your project - I think it is much more important to OpenStack than many others, though that's a big part of why it is important to avoid API churn. The instability of our APIs is a huge barrier to OpenStack adoption. I'd love to see the TC review all breaking API changes, but I don't think we're set up that way. Justin ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
