openstack team mailing list archive

[Justin Santa Barbara <justin@xxxxxxxxxxxx>]

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.voccio@xxxxxxxxxxxxx>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 <justin@xxxxxxxxxxxx>
> Date: Tue, 15 Feb 2011 11:38:37 -0800
> To: Troy Toman <troy.toman@xxxxxxxxxxxxx>
>
> Cc: "openstack@xxxxxxxxxxxxxxxxxxx" <openstack@xxxxxxxxxxxxxxxxxxx>
> 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.toman@xxxxxxxxxxxxx>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 abuse@xxxxxxxxxxxxx, 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
>
>