[openstack-dev] [all] [tc] [PTL] Cascading vs. Cells – summit recap and move forward

henry hly henry4hly at gmail.com
Fri Dec 12 06:29:25 UTC 2014


On Fri, Dec 12, 2014 at 11:41 AM, Dan Smith <dms at danplanet.com> wrote:
>> [joehuang] Could you pls. make it more clear for the deployment mode
>> of cells when used for globally distributed DCs with single API. Do
>> you mean cinder/neutron/glance/ceilometer will be shared by all
>> cells, and use RPC for inter-dc communication, and only support one
>> vendor's OpenStack distribution? How to do the cross data center
>> integration and troubleshooting with RPC if the
>> driver/agent/backend(storage/network/sever) from different vendor.
>
> Correct, cells only applies to single-vendor distributed deployments. In
> both its current and future forms, it uses private APIs for
> communication between the components, and thus isn't suited for a
> multi-vendor environment.
>
> Just MHO, but building functionality into existing or new components to
> allow deployments from multiple vendors to appear as a single API
> endpoint isn't something I have much interest in.
>
> --Dan
>

Even with the same distribution, cell still face many challenges
across multiple DC connected with WAN. Considering OAM, it's easier to
manage autonomous systems connected with external northband interface
across remote sites, than a single monolithic system connected with
internal RPC message.

Although Cell did some separation and modulation (not to say it's
still internal RPC across WAN), they leaves cinder, neutron,
ceilometer. Shall we wait for all these projects to re-factor with
Cell-like hierarchy structure, or adopt a more loose coupled way, to
distribute them into autonomous units at the basis of the whole
Openstack (except Keystone which can handle multiple region
naturally)?

As we can see, compared with Cell, much less work is needed to build a
Cascading solution, No patch is needed except Neutron (waiting some
upcoming features not landed in Juno), nearly all work lies in the
proxy, which is in fact another kind of driver/agent.

Best Regards
Henry


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



More information about the OpenStack-dev mailing list