Re: [Openstack-poc] 3rd Party APIs
Hey, I just realised there's a thread on the openstack-poc list about how OpenStack should view implementations of APIs other than the OpenStack API: https://lists.launchpad.net/openstack-poc/msg00448.html (PPB members - please note that other folks can't subscribe to the POC list. If you want an open discussion on something, the openstack-poc list isn't the place for it) tl;dr - rather than actively discouraging folks from contributing native API implementations, encourage them to resolve the current difficulties with the EC2 API and their work as a test case for feature/subsystem branch development process. The discussion is fairly complex and seems to degenerate into an overly general what is and is not core discussion. There also seems to be a sense of urgency around finding a final solution here, which I don't fully understand. The truth is we don't know the answer. We just need to have some rough idea of what we're trying to achieve and figure out the thing we want to try next. We'll likely have to try a bunch of stuff before finding one that works. What I'd like to see us get to is: Deep overlap between the OpenStack developer community and the community of folks drafting whatever IaaS standard(s) wind up being dominant. e.g. prominent, active Nova developers developers contributing to the CIMI or OCCI standards and bringing the needs of OpenStack to the standard and bringing ideas from the standards process to OpenStack. This isn't a question of asking existing OpenStack developers to join these standards bodies. It's about enabling members of those standards bodies to become as much a part of OpenStack as any other developer. How to do that? Encourage members the various standards communities to actively contribute an implementation of their standard to OpenStack and, more importantly, stick around to become an ongoing active member of the OpenStack developer community. If this worked out, OpenStack would gain new developers, new ideas and would be seen as the best place to do new work around IaaS APIs. AFAICT nova-core has two major concerns with the EC2 API - 1) currently having to make a change once in the OpenStack API and again in the EC2 API and 2) the EC2 isn't maintenance isn't sufficiently active. I think a lot of the urgency around this discussion is wanting to avoid exacerbating the situation by adding another API. To me, the answer is fairly simple. We cannot accept a new API until these concerns are addressed: 1) The amount of duplication between the OpenStack, EC2 and any proposed API needs to be significantly reduced 2) The developers of any proposed new API need to demonstrate a commitment (through their work) to sticking around as active OpenStack developers maintaining the API (perhaps as a subsystem tree) That's a high bar, and I expect only seriously committed contributors would meet it. In the meantime, those contributors can work on their APIs as feature branches and encourage others to give feedback. Two alternatives to the above are on the table. Firstly, implementing these APIs as deltacloud-like proxy servers and blessing these as official OpenStack products. IMHO, proxies are architecturally less than ideal. Perhaps with enough engineering effort (including OpenStack API additions) we can get to where they are almost on-par with a native API, but I'm sceptical. The other option is to support these APIs with external plugins. For us to get there, we need a stable library-like API that these plugins can depend on. It's potentially an ideal solution, but I think we've a long way to get there. A stepping stone is the re-factoring to reduce duplication between APIs. Cheers, Mark. ___ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp
Re: [Openstack-poc] 3rd Party APIs
The reason I said c and not b is because there may be something in the future that we see that really, really needs to belong in the kernel of an OpenStack system. By choosing B, categorically it seemed like an assertion that none of these 3rd party APIs (or plugins or whatever) could *ever* become core. And while I don't see that as beneficial now and for the examples we're talking about, I don't want to close down that possibility. Right now we *do* have option C by my view and definitions, even though there's not a formal process. How did we suddenly start gating and testing against devstack? I don't think anyone here would disagree with it, but it's also not a formal project or process that went through any form of approval, incubation, etc. other than be damned useful on the technical side and providing a very clear value to getting a solid OpenStack product out the door. - joe On May 6, 2012, at 9:01 AM, Jay Pipes wrote: On 05/05/2012 08:24 PM, John Dickinson wrote: This is the second message on this thread that has said something to the effect of there is great benefit to not having 'core' or 'official' or 'approved' parts of the ecosystem (vs the core openstack projects). Yet in both of those messages, option c was chosen. How does that work? How is that not option b? You are correct, John. I had confused c) with b)... I am supporting option b): Standards Bodies/Developers: would prefer to have some recognition/discoverability for the new apis, currently the only path forward is to be in core, so they are pushing to be included, but they might be ok with some other type of recognition. Best, -jay ___ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp
Re: [Openstack-poc] 3rd Party APIs
Joshua McKenty wrote: I'm a fan of c), where the officialness is tied to a committed organization or team that is keeping the code up-to-date and tested. I'd also be a fan of making that a per-release designation, with an easy renewal if the commitment is still in place. Generally, a smaller core with a supported status for satellite projects is my favorite model, for much of OpenStack development. I don't have very strong feelings on that subject. My gut feeling would be to support (c), but I could be convinced by a strong argument why we shouldn't. If that's the decision we end up taking, the PPB discussion quickly shifts to defining the taxonomy of OpenStack projects. On this subject and others that were raised at the Design Summit (like plug-ins), Core/Incubated/Other doesn't really cut it anymore. In particular I'd like to have at least one category for projects that are essential to the OpenStack development community but should not be part of the OpenStack core product (the IaaS stack of projects with a coordinated release every 6 months). Openstack-common, openstack-ci, or things we gate the core product on (devstack, tempest) should never be part of OpenStack Core (or ever be incubated to become core). However they are necessary for us to produce OpenStack core, and require our collective attention and support. So they need to be blessed in some kind of official category meaning they are an central part of OpenStack as a development community. Maybe OpenStack Companion project... Another category could be necessary to describe external projects/plug-ins that are continuously tested with OpenStack Core as part of our integration testing and for which we therefore have a pretty good idea of how well they work with OpenStack. Choosing the right term is a bit more tricky here since most names are a bit overloaded. Maybe OpenStack recommended project/plugin... Regards, -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp
Re: [Openstack-poc] 3rd Party APIs
I'd definitely go for option c here. I'm one of those Core Developers you mention that wants less code in the core repos. We also need to make sure the right people are maintaining that API code, which aren't necessarily the *-core teams. On May 2, 2012, at 1:02 PM, Vishvananda Ishaya wrote: We discussed the policy on third party apis this week at the PPB meeting. We decided to take it to the mailing list for discussion so we can get to some reasonable things to vote on in next weeks meeting. tl; dr How do third party apis fit in OpenStack? Background This was inspired by the current proposals for OCCI and CDMI into nova and swift and the upcoming work and proposals for CIMI for nova. The basic question is: does this code belong in the core repositories and if not, where does it go. I see a number of groups with interest in this. I'm going to outline the major players and give my (biased) opinion on what they want a) Core Developers: would prefer to have these apis outside of core. It is already a burden to maintain the existing apis, so separating these into separate projects would be beneficial. b) Standards Bodies/Developers: would prefer to have some recognition/discoverability for the new apis, currently the only path forward is to be in core, so they are pushing to be included, but they might be ok with some other type of recognition. c) Deployers/Distributors: want an easy way to know that these external plugins work well. This can be accomplished by testing/etc. Probably don't really care too much about the new apis unless they get specific customer requests d) Users: some users (scientific community) would love to have access to these other apis. From a user perspective, the more apis the better, as long as they are stable and all work. Current Proposals a) ppb doesn't care and the projects decide individually b) third party apis are not part of openstack core, and we focus on building a strong ecosystem where these apis could exist as proxies or external plugins. It is up to deployers to decide which ecosystem projects to include in their distributions c) just like b, but there is additionally a process by which these third party tools could become 'official' in some sense or be 'recommended' for inclusion by the distros. d) third party standards are vetted for inclusion by the ppb and are added to core projects assuming they can pass certain testing requirements e) we have our own api, so we shouldn't be encouraging 3rd party apis at all. Tney are on their own. f) ??? Please discuss, Vish ___ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp
Re: [Openstack-poc] 3rd Party APIs
On 05/03/2012 04:08 AM, Thierry Carrez wrote: Joshua McKenty wrote: I'm a fan of c), where the officialness is tied to a committed organization or team that is keeping the code up-to-date and tested. I'd also be a fan of making that a per-release designation, with an easy renewal if the commitment is still in place. Generally, a smaller core with a supported status for satellite projects is my favorite model, for much of OpenStack development. I don't have very strong feelings on that subject. My gut feeling would be to support (c), but I could be convinced by a strong argument why we shouldn't. I feel the same way. (c) sounds good, but I'm not married to it... If that's the decision we end up taking, the PPB discussion quickly shifts to defining the taxonomy of OpenStack projects. On this subject and others that were raised at the Design Summit (like plug-ins), Core/Incubated/Other doesn't really cut it anymore. In particular I'd like to have at least one category for projects that are essential to the OpenStack development community but should not be part of the OpenStack core product (the IaaS stack of projects with a coordinated release every 6 months). Openstack-common, openstack-ci, or things we gate the core product on (devstack, tempest) should never be part of OpenStack Core (or ever be incubated to become core). However they are necessary for us to produce OpenStack core, and require our collective attention and support. So they need to be blessed in some kind of official category meaning they are an central part of OpenStack as a development community. Maybe OpenStack Companion project... I don't necessarily view openstack-ci and openstack-common in the same vein. I think openstack-common actually should be part of core since it is an important dependency for so many of the core projects (and becoming more so...). Openstack-ci, tempest and devstack are also critical pieces, but they are support projects, not necessarily dependencies. So I would categorize them as OpenStack Supporting Projects or similar. Another category could be necessary to describe external projects/plug-ins that are continuously tested with OpenStack Core as part of our integration testing and for which we therefore have a pretty good idea of how well they work with OpenStack. Choosing the right term is a bit more tricky here since most names are a bit overloaded. Maybe OpenStack recommended project/plugin... The term recommended comes with a lot of baggage :) I don't want plugins to be recommended or suggested -- at least by the community; companies should feel free to recommend or suggest whatever they feel is best for their distro or deployment. I just want a category called OpenStack Extensions (or Plugins, depending on what the semantics-du-jour happen to be. Best, -jay ___ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp
Re: [Openstack-poc] 3rd Party APIs
+1, primarily by process of elimination. The other options seem either too permissive or too strict. I think our job is to provide a way for the ecosystem to develop and give people a place and category for these projects to live, but not to micromanage every piece of the ecosystem. Devin On May 2, 2012, at 9:50 PM, Joshua McKenty wrote: I'm a fan of c), where the officialness is tied to a committed organization or team that is keeping the code up-to-date and tested. I'd also be a fan of making that a per-release designation, with an easy renewal if the commitment is still in place. Generally, a smaller core with a supported status for satellite projects is my favorite model, for much of OpenStack development. -- Joshua McKenty, CEO Piston Cloud Computing, Inc. w: (650) 24-CLOUD m: (650) 283-6846 http://www.pistoncloud.com Oh, Westley, we'll never survive! Nonsense. You're only saying that because no one ever has. On Wednesday, May 2, 2012 at 3:02 PM, Vishvananda Ishaya wrote: We discussed the policy on third party apis this week at the PPB meeting. We decided to take it to the mailing list for discussion so we can get to some reasonable things to vote on in next weeks meeting. tl; dr How do third party apis fit in OpenStack? Background This was inspired by the current proposals for OCCI and CDMI into nova and swift and the upcoming work and proposals for CIMI for nova. The basic question is: does this code belong in the core repositories and if not, where does it go. I see a number of groups with interest in this. I'm going to outline the major players and give my (biased) opinion on what they want a) Core Developers: would prefer to have these apis outside of core. It is already a burden to maintain the existing apis, so separating these into separate projects would be beneficial. b) Standards Bodies/Developers: would prefer to have some recognition/discoverability for the new apis, currently the only path forward is to be in core, so they are pushing to be included, but they might be ok with some other type of recognition. c) Deployers/Distributors: want an easy way to know that these external plugins work well. This can be accomplished by testing/etc. Probably don't really care too much about the new apis unless they get specific customer requests d) Users: some users (scientific community) would love to have access to these other apis. From a user perspective, the more apis the better, as long as they are stable and all work. Current Proposals a) ppb doesn't care and the projects decide individually b) third party apis are not part of openstack core, and we focus on building a strong ecosystem where these apis could exist as proxies or external plugins. It is up to deployers to decide which ecosystem projects to include in their distributions c) just like b, but there is additionally a process by which these third party tools could become 'official' in some sense or be 'recommended' for inclusion by the distros. d) third party standards are vetted for inclusion by the ppb and are added to core projects assuming they can pass certain testing requirements e) we have our own api, so we shouldn't be encouraging 3rd party apis at all. Tney are on their own. f) ??? Please discuss, Vish ___ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp
Re: [Openstack-poc] 3rd Party APIs
On May 3, 2012, at 1:16 PM, Jay Pipes wrote: The term recommended comes with a lot of baggage :) I don't want plugins to be recommended or suggested -- at least by the community; companies should feel free to recommend or suggest whatever they feel is best for their distro or deployment. I just want a category called OpenStack Extensions (or Plugins, depending on what the semantics-du-jour happen to be. I agree with this, which is why I support option b --John smime.p7s Description: S/MIME cryptographic signature ___ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp
