> -----Original Message-----
> From: henry hly [mailto:henry4...@gmail.com]
> Sent: 08 October 2014 09:16
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack
> cascading
> Hi,
> Good questions: why not just keeping multiple endpoints, and leaving
> orchestration effort in the client side?
> From feedback of some large data center operators, they want the cloud
> exposed to tenant as a single region with multiple AZs, while each AZ may be
> distributed in different/same locations, very similar with AZ concept of AWS.
> And the OpenStack API is indispensable for the cloud for eco-system
> friendly.
> The cascading is mainly doing one thing: map each standalone child
> Openstack to AZs in the parent Openstack, hide separated child endpoints,
> thus converge them into a single standard OS-API endpoint.
> One of the obvious benefit doing so is the networking: we can create a single
> Router/LB, with subnet/port member from different child, just like in a single
> OpenStack instance. Without the parent OpenStack working as the
> aggregation layer, it is not so easy to do so. Explicit VPN endpoint may be
> required in each child.
I've read through the thread and the various links, and to me this still sounds 
an awful lot like having multiple regions in Keystone.

First of all I think we're in danger of getting badly mixed up in terminology 
here around AZs which is an awfully overloaded term - esp when we make 
comparisons to AWS AZs.  Whether we think the current Openstack usage of these 
terms or not, lets at least stick to how they are currently defined and used in 

AZs - A scheduling concept in Nova and Cinder.    Simply provides some 
isolation schemantic about a compute host or storage server.  Nothing to do 
with explicit physical or geographical location, although some degree of that 
(separate racks, power, etc) is usually implied.

Regions - A keystone concept for a collection of Openstack Endpoints.   They 
may be distinct (a completely isolated set of Openstack service) or overlap 
(some shared services).  Openstack clients support explicit user selection of a 

Cells - A scalability / fault-isolation concept within Nova.  Because Cells 
aspires to provide all Nova features transparently across cells this kind or 
acts like multiple regions where only the Nova service is distinct (Networking 
has to be common, Glance has to be common or at least federated in a 
transparent way, etc).   The difference from regions is that the user doesn’t 
have to make an explicit region choice - they get a single Nova URL for all 
cells.   From what I remember Cells originally started out also using the 
existing APIs as the way to connect the Cells together, but had to move away 
from that because of the performance overhead of going through multiple layers.

Now with Cascading it seems that we're pretty much building on the Regions 
concept, wrapping it behind a single set of endpoints for user convenience, 
overloading the term AZ to re-expose those sets of services to allow the user 
to choose between them (doesn't this kind of negate the advantage of not having 
to specify the region in the client- is that really such a bit deal for users 
?) , and doing something to provide a sort of federated Neutron service - 
because as we all know the hard part in all of this is how you handle the 

It kind of feels to me that if we just concentrated on the part of this that is 
working out how to distribute/federate Neutron then we'd have a solution that 
could be mapped as easily cells and/or regions - and I wonder if then why 
really need yet another aggregation concept ?

OpenStack-dev mailing list

Reply via email to