Pulling volumes & images out into separate services (and moving from AMQP to REST) sounds like a huge breaking change, so if that is indeed the plan, let's do that asap (i.e. Cactus).
On Thu, Feb 17, 2011 at 3:44 PM, Paul Voccio <paul.voc...@rackspace.com>wrote: > 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> > Date: Tue, 15 Feb 2011 11:38:37 -0800 > To: Troy Toman <troy.to...@rackspace.com> > > Cc: "openstack@lists.launchpad.net" <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>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, and delete the original message. >> Your cooperation is appreciated. >> >> > _______________________________________________ Mailing list: > https://launchpad.net/~openstack Post to : > openstack@lists.launchpad.netUnsubscribe : > 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
