Open Stack

Hello, Loy,

Thank you very much. You have already grasped the core design idea for OpenStack cascading:

>>By my understanding, core idea of Cascading is that each resource
>>building block(like child cell) is a clearly separated autonomous
>>system, with the already defined REST OS-API as the NB integration
>>interface of each block, is that right?

Yes, you are right. the cascading OpenStack (the parent) using already defined 
REST OS-API as the NB integration for each building block
(we called cascaded OpenStack).

>>So, what's the OAM and business value? Is it easy to add a building
>>block POD into the running production cloud, while this POD is from a
>>different Openstack packager and has its own deployment choice:
>>Openstack version release(J/K/L...), MQ/DB type(mysql/pg,
>>rabbitmq/zeromq..), backend drivers, Nova/Neutron/Cinder/Ceilometer
>>controller-node / api-server config options...?

In the lab, we have already dynamicly added new block POD (cascaded OpenStack)
 into the cloud with OpenStack cascading introduced. And each cascaded OpenStack
 version can be different because we use pythonclient and OpenStack itself support 
multiple API version compatibility co-exist. For sure DB/messagebus/backend drivers/controller 
node configuration can be different for different cascaded OpenStack.

Best regards

Chaoyi Huang ( joehuang )

________________________________________
From: loy wolfe [loywolfe at gmail.com]
Sent: 01 October 2014 16:13
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by     OpenStack cascading

Hi Joe and Cellers,

I've tried to understand relationship between Cell and Cascading. If
Cell has been designed as below, would it be the same as Cascading?

1) Besides Nova, Neutron/Ceilometer.. is also hierarchically
structured for scalability.

2) Child-parent interaction is based on REST OS-API, but not internal
rpc message.

By my understanding, core idea of Cascading is that each resource
building block(like child cell) is a clearly separated autonomous
system, with the already defined REST OS-API as the NB integration
interface of each block, is that right?

So, what's the OAM and business value? Is it easy to add a building
block POD into the running production cloud, while this POD is from a
different Openstack packager and has its own deployment choice:
Openstack version release(J/K/L...), MQ/DB type(mysql/pg,
rabbitmq/zeromq..), backend drivers, Nova/Neutron/Cinder/Ceilometer
controller-node / api-server config options...?

Best Regards
Loy


On Wed, Oct 1, 2014 at 3:19 PM, Tom Fifield <tom at openstack.org> wrote:
>
> Hi Joe,
>
> On 01/10/14 09:10, joehuang wrote:
> > OpenStack cascading: to integrate multi-site / multi-vendor OpenStack instances into one cloud with OpenStack API exposed.
> > Cells: a single OpenStack instance scale up methodology
>
> Just to let you know - there are actually some users out there that use
> cells "to integrate multi-site / multi-vendor OpenStack instances into
> one cloud with OpenStack API exposed.", and this is their main reason
> for using cells - not as a "scale up" methodology.
>
>
> Regards,
>
> Tom
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev