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 [loywo...@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 <t...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
