Re: [Openstack] API Spec
Preface: I am not very familiar with Nova. On 08/26/2011 01:19 PM, Devin Carlen wrote: I believe we should have had a Rackspace API module just like we have an EC2 API module. Then the OpenStack API wouldn't have been burdened by the historical decisions around the Rackspace API. But that is ancient history at this point. So that I can better understand, as well as for others that may not know, would it be possible to get a basic explanation of why it is hard to modify Nova, now, to modularize the Rackspace API? basic == non-technical highlights in simple english, please. This sounds to me like a bad architectural decision that people are living with - so, why not admit that and make it a priority to change? -- Kind regards, Michael snipped it's been over and year and it is hard sounding excuses(?) ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] API Spec
The Rackspace compute API is actually one of the better cloud APIs out there. It's a pretty damn good basis for an OpenStack Nova API. EC2, on the other hand, is a pretty obnoxious API and I've already outlined my thoughts on its role as a defacto API on my blog. Having said that, there is basically no difference between the OpenStack API and a Rackspace API that has not changed in 2 years. In other words, there's been no attempt to improve the API based on two year's of learning, no attempt to step back and model the problem of cloud computing in general, it uses some goofy Rackspace terminology like Flavor, and there's been no attempt to expose the features of OpenStack that don't exist in the current Rackspace API. The biggest difference is authentication. That's been left up to the implementor. Yuck! Pick an authentication scheme and live with it! The most important thing right now would not be to re-write the API, but to create specs for other parts of OpenStack like volumes and integrate them into the structure of the current API. It shouldn't be too hard. I absolutely don't understand why, after a year of work, all we have is clone of the Rackspace API labeled 1.1. -George On Aug 27, 2011, at 12:34 PM, Michael Shuler wrote: Preface: I am not very familiar with Nova. On 08/26/2011 01:19 PM, Devin Carlen wrote: I believe we should have had a Rackspace API module just like we have an EC2 API module. Then the OpenStack API wouldn't have been burdened by the historical decisions around the Rackspace API. But that is ancient history at this point. So that I can better understand, as well as for others that may not know, would it be possible to get a basic explanation of why it is hard to modify Nova, now, to modularize the Rackspace API? basic == non-technical highlights in simple english, please. This sounds to me like a bad architectural decision that people are living with - so, why not admit that and make it a priority to change? -- Kind regards, Michael snipped it's been over and year and it is hard sounding excuses(?) ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comt: @GeorgeReesep: +1.207.956.0217f: +1.612.338.5041 enStratus: Governance for Public, Private, and Hybrid Clouds - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese smime.p7s Description: S/MIME cryptographic signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Why are we using github again?
On Fri, Aug 26, 2011, Jesse Andrews anotherje...@gmail.com wrote: I disagree. I find lots of valuable in github even if trunk merges require gerrit. Teams can (and IMHO should) use pull requests to improve the quality before it is proposed to trunk. Pull requests to branches can be made while the work is still in progress (sending patches to others branches is something that can be done in BZR, but seems to be rarely done) Except that tools for Gerrit are hostile to this workflow now. This worked just fine before (I used forks of glance myself on github), but I had to find out the hard way that this is no longer the case. If you don't clone directly off of trunk, then you need to workaround the Gerrit tools now. JE ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] API Spec
A cloud platform simply isn't functional without an API. It is a core requirement. No API, no cloud. -George On Aug 27, 2011, at 7:04 PM, Tim Bell wrote: I'm also a non-API expert but getting a stable open cloud engine with a reasonable API would seem to be a good target before we look to enhance it. There are lots of potential users of Nova (including Rackspace) who would like to get Nova into production. An API will fully exploits all of the underlying functionality should be discussed/planned in the longer term but let's get Diablo out and deployable first. Tim Bell CERN ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comt: @GeorgeReesep: +1.207.956.0217f: +1.612.338.5041 enStratus: Governance for Public, Private, and Hybrid Clouds - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese smime.p7s Description: S/MIME cryptographic signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] API Spec
I have an api, diablo nova v1.1. What we are talking about is if it covers 100% functionality. I can start my deployment testing with v1.1. The limiting factor is not v1.1 vs v1.x for most sites. It is packaging, user exits and integration, not whether feature X is in the latest API. Tim. - Reply message - From: George Reese george.re...@enstratus.com To: Tim Bell tim.b...@cern.ch Cc: openstack@lists.launchpad.net openstack@lists.launchpad.net Subject: [Openstack] API Spec Date: Sat, Aug 27, 2011 20:47 A cloud platform simply isn't functional without an API. It is a core requirement. No API, no cloud. -George On Aug 27, 2011, at 7:04 PM, Tim Bell wrote: I'm also a non-API expert but getting a stable open cloud engine with a reasonable API would seem to be a good target before we look to enhance it. There are lots of potential users of Nova (including Rackspace) who would like to get Nova into production. An API will fully exploits all of the underlying functionality should be discussed/planned in the longer term but let's get Diablo out and deployable first. Tim Bell CERN ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comt: @GeorgeReesep: +1.207.956.0217f: +1.612.338.5041 enStratus: Governance for Public, Private, and Hybrid Clouds - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] API Spec
On 8/26/11 1:19 PM, Devin Carlen devin.car...@gmail.com wrote: There have been a lot of efforts lately to bring the feature set of the OpenStack API in line with the EC2 API, and this is admirable. But this has NOT been happening at the architect level. This has been happening at the developer level, and it is being done with API extensions which make it sound like the feature is somehow not complete or not supported fully, because it's not part of the core API. I think you are hitting on a perception problem around extensions that might be solvable by taking some steps to make the intent clear. I propose two things: always keep the next version of the API in play and improve the classification of the extensions. Developers have to choose to contribute in a way that either works with the current APIs or not. Mixing these is bad, and fortunately unnecessary. The two tracks should probably have different tech leads. How about this as classification system for extensions: temporary extension accepted for addition to core api in the next backwards compatible version uprev backport extension ‹ accepted for addition to core api in the next non-backwards compatible version uprev default extension viewed as standard, but not incorporated into the core to allow opt-out by an operator common extension ‹ viewed as the preferred solution, but must be an opt-in by an operator candidate extension ‹ an extension viewed as trying to prove itself worthy for a higher level private extension ‹ an extension not offered or not accepted for a higher level Thoughts? This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] API Spec
This is on the agenda for Tuesday's policy board meeting (in #openstack-meeting 1 hour before the weekly OpenStack team meeting for those interested). Sounds like a potentially acceptable solution is to set some cross-project API standards and then push the remainder of the API definition and implementation into each project. Then the API can progress with the underlying project's features as the developers see fit. Jonathan. On Aug 27, 2011, at 4:16 PM, Tim Bell wrote: I have an api, diablo nova v1.1. What we are talking about is if it covers 100% functionality. I can start my deployment testing with v1.1. The limiting factor is not v1.1 vs v1.x for most sites. It is packaging, user exits and integration, not whether feature X is in the latest API. Tim. - Reply message - From: George Reese george.re...@enstratus.com To: Tim Bell tim.b...@cern.ch Cc: openstack@lists.launchpad.net openstack@lists.launchpad.net Subject: [Openstack] API Spec Date: Sat, Aug 27, 2011 20:47 A cloud platform simply isn't functional without an API. It is a core requirement. No API, no cloud. -George On Aug 27, 2011, at 7:04 PM, Tim Bell wrote: I'm also a non-API expert but getting a stable open cloud engine with a reasonable API would seem to be a good target before we look to enhance it. There are lots of potential users of Nova (including Rackspace) who would like to get Nova into production. An API will fully exploits all of the underlying functionality should be discussed/planned in the longer term but let's get Diablo out and deployable first. Tim Bell CERN ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comt: @GeorgeReesep: +1.207.956.0217f: +1.612.338.5041 enStratus: Governance for Public, Private, and Hybrid Clouds - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] API Spec
I don't necessarily agree with that approach. I'm not sure if that's the way AWS does things or not, but you will note that the AWS APIs are very fragmented across projects. I think there are several principles that may at times be in conflict that need to be in place: * Any GA feature should be exposed via API at the time of its GA-ness. * There needs to be a gatekeeper (possibly the wrong word) ensuring that the APIs are self-consistent And the understanding should exist that modeling something for functionality may not be the same as the way it is modeled in the API. In fact, the underlying model will likely be refactored many times by the API must be timeless (but evolvable). -George On Aug 28, 2011, at 2:29 AM, Jonathan Bryce wrote: This is on the agenda for Tuesday's policy board meeting (in #openstack-meeting 1 hour before the weekly OpenStack team meeting for those interested). Sounds like a potentially acceptable solution is to set some cross-project API standards and then push the remainder of the API definition and implementation into each project. Then the API can progress with the underlying project's features as the developers see fit. Jonathan. On Aug 27, 2011, at 4:16 PM, Tim Bell wrote: I have an api, diablo nova v1.1. What we are talking about is if it covers 100% functionality. I can start my deployment testing with v1.1. The limiting factor is not v1.1 vs v1.x for most sites. It is packaging, user exits and integration, not whether feature X is in the latest API. Tim. - Reply message - From: George Reese george.re...@enstratus.com To: Tim Bell tim.b...@cern.ch Cc: openstack@lists.launchpad.net openstack@lists.launchpad.net Subject: [Openstack] API Spec Date: Sat, Aug 27, 2011 20:47 A cloud platform simply isn't functional without an API. It is a core requirement. No API, no cloud. -George On Aug 27, 2011, at 7:04 PM, Tim Bell wrote: I'm also a non-API expert but getting a stable open cloud engine with a reasonable API would seem to be a good target before we look to enhance it. There are lots of potential users of Nova (including Rackspace) who would like to get Nova into production. An API will fully exploits all of the underlying functionality should be discussed/planned in the longer term but let's get Diablo out and deployable first. Tim Bell CERN ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comt: @GeorgeReesep: +1.207.956.0217f: +1.612.338.5041 enStratus: Governance for Public, Private, and Hybrid Clouds - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comt: @GeorgeReesep: +1.207.956.0217f: +1.612.338.5041 enStratus: Governance for Public, Private, and Hybrid Clouds - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese smime.p7s Description: S/MIME cryptographic signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
