Open Stack

There are lots of advantages:

1) It allows services to be more autonomous, and gives us clearly defined service boundaries. Each service can be treated as a black box.
2) All service communication becomes versioned, not just the public API but also the admin API.  This means looser coupling which can help us work in parallel.  So glance can be on 1.2 of their API, but another API that depends on it (say compute) can continue to consume 1.1 until they're ready to switch -- we don't have the bottlenecks of everyone having to update everything together.
3) Also because things are loosely coupled and there are clearly defined boundaries  it positions us to have many other services (LBaaS, FWaaS, DBaaS, DNSaaS, etc).
4) It also becomes easier to deploy a subset of functionality ( you want compute and image, but not block).
5) Interested developers can get involved in only the services that they care about without worrying about other services.
6) We already have 3 APIs (nova, swift, glance), we need to do this kind of integration as it is, it makes sense for us to standardize on it.

We are certainly changing the way we are doing things, but I don't really think we are throwing away a lot of functionality.  As PVO mentioned, things should work very similar to the way they are working now.  You still have compute workers, you may still have an internal queue, the only difference is that cross-service communication is now happening by issuing REST calls.

-jOrGe W.


On Feb 18, 2011, at 9:34 AM, Jay Pipes wrote:

> OK, fair enough.
> 
> Can I ask what the impetus for moving from AMQP to REST for all
> internal APIs is? Seems to me we will be throwing away a lot of
> functionality for the benefit of cross-WAN REST communication?
> 
> -jay
> 
> On Fri, Feb 18, 2011 at 9:31 AM, Paul Voccio <paul.voccio at rackspace.com> wrote:
>> Jay,
>> 
>> I understand Justin's concern if we move /network and /images and /volume
>> to their own endpoints then it would be a change to the customer. I think
>> this could be solved by putting a proxy in front of each endpoint and
>> routing back to the appropriate service endpoint.
>> 
>> I added another image on the wiki page to describe what I'm trying to say.
>> http://wiki.openstack.org/api_transition
>> 
>> I think might not be as bad of a transition since the compute worker would
>> receive a request for a new compute node then it would proxy over to the
>> admin or public api of the network or volume node to request information.
>> It would work very similar to how the queues work now.
>> 
>> pvo
>> 
>> On 2/17/11 8:33 PM, "Jay Pipes" <jaypipes at gmail.com> wrote:
>> 
>>> Sorry, I don't view the proposed changes from AMQP to REST as being
>>> "customer facing API changes". Could you explain? These are internal
>>> interfaces, no?
>>> 
>>> -jay
>>> 
>>> On Thu, Feb 17, 2011 at 8:13 PM, Justin Santa Barbara
>>> <justin at fathomdb.com> wrote:
>>>> An API is for life, not just for Cactus.
>>>> I agree that stability is important.  I don't see how we can claim to
>>>> deliver 'stability' when the plan is then immediately to destablize
>>>> everything with a very disruptive change soon after, including customer
>>>> facing API changes and massive internal re-architecting.
>>>> 
>>>> 
>>>> On Thu, Feb 17, 2011 at 4:18 PM, Jay Pipes <jaypipes at gmail.com> wrote:
>>>>> 
>>>>> On Thu, Feb 17, 2011 at 6:57 PM, Justin Santa Barbara
>>>>> <justin at fathomdb.com> wrote:
>>>>>> 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).
>>>>> 
>>>>> Sorry, I have to disagree with you here, Justin :)  The Cactus release
>>>>> is supposed to be about stability and the only features going into
>>>>> Cactus should be to achieve API parity of the OpenStack Compute API
>>>>> with the Rackspace Cloud Servers API. Doing such a huge change like
>>>>> moving communication from AMQP to HTTP for volume and network would be
>>>>> a change that would likely undermine the stability of the Cactus
>>>>> release severely.
>>>>> 
>>>>> -jay
>>>> 
>>>> 
>> 
>> 
>> 
>> 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 at rackspace.com, and delete the original message.
>> Your cooperation is appreciated.
>> 
>> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp