I wanted to put out into the open where we think the evolution of the apis will go over the next few releases. This is by no means the only way to do this, but I thought it would be a start of conversation.
http://wiki.openstack.org/api_transition I also wanted to clear up some confusion that I think came out of our email thread the other day. With the OpenStack 1.1 API proposal, this is really a OpenStack Compute 1.1 proposal. While volumes and images are currently in, I think longer term they would be pulled out. The network and volume services should be able to scale independently of each other. If you look at the diagram, the changes would entail moving from an amqp protocol to a http protocol that a worker would hit on the public/admin interfaces to accomplish the same work as before. Lets keep the thread going. Pvo From: Justin Santa Barbara <jus...@fathomdb.com<mailto:jus...@fathomdb.com>> Date: Tue, 15 Feb 2011 11:38:37 -0800 To: Troy Toman <troy.to...@rackspace.com<mailto:troy.to...@rackspace.com>> Cc: "openstack@lists.launchpad.net<mailto:openstack@lists.launchpad.net>" <openstack@lists.launchpad.net<mailto:openstack@lists.launchpad.net>> Subject: Re: [Openstack] OpenStack Compute API 1.1 Sounds great - when the patch comes in we can discuss whether this should be an extension or whether scheduled snapshots / generic tasks have broader applicability across OpenStack (and thus would be better in the core API) Is there a blueprint? On Tue, Feb 15, 2011 at 11:32 AM, Troy Toman <troy.to...@rackspace.com<mailto:troy.to...@rackspace.com>> wrote: On Feb 15, 2011, at 1:06 PM, Justin Santa Barbara wrote: OK - so it sounds like volumes are going to be in the core API (?) - good. Let's get that into the API spec. It also sounds like extensions (swift / glance?) are not going to be in the same API long-term. So why do we have the extensions mechanism? Until we have an implemented use case (i.e. a patch) that uses the extensions element, I don't see how we can spec it out or approve it. So if you want it in v1.1, we better find a team that wants to use it and write code. If there is such a patch, I stand corrected and let's get it reviewed and merged. I would actually expect that the majority of the use cases that we want in the API but don't _want_ to go through core would be more simply addressed by well-known metadata (e.g. RAID-5, multi-continent replication, HPC, HIPAA). I'm don't agree that the lack of a coded patch means we can't discuss an extension mechanism. But, if you want a specific use case, we have at least one we intend to deliver. It may be more of a one-off than a general case because it is required to give us a reasonable transition path from our current codebase to Nova. But, it is not an imagined need. In the Rackspace Cloud Servers 1.0 API, we support a concept of backup schedules with a series of API calls to manage them. In drafting the OpenStack compute API, this was something that didn't feel generally applicable or useful in the core API. So, you don't see it as part of the CORE API spec. That said, for transition purposes, we will need a way to provide this capability to our customers when we move to Nova. Our current plan is to do this using the extension mechanism in the proposed API. If there is a better way to handle this need, then let's discuss further. But, I didn't want the lack of a specific example to squash the idea of extensions. Troy Toman Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com<mailto:ab...@rackspace.com>, and delete the original message. Your cooperation is appreciated. _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net<mailto: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
