On Fri, Dec 12, 2014 at 4:10 PM, Steve Gordon <sgor...@redhat.com> wrote:
> ----- Original Message -----
>> From: "henry hly" <henry4...@gmail.com>
>> To: "OpenStack Development Mailing List (not for usage questions)" 
>> <openstack-dev@lists.openstack.org>
>> On Fri, Dec 12, 2014 at 11:41 AM, Dan Smith <d...@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.
> The key question here is this primarily the role of OpenStack or an external 
> cloud management platform, and I don't profess to know the answer. What do 
> people use (workaround or otherwise) for these use cases *today*? Another 
> question I have is, one of the stated use cases is for managing OpenStack 
> clouds from multiple vendors - is the implication here that some of these 
> have additional divergent API extensions or is the concern solely the 
> incompatibilities inherent in communicating using the RPC mechanisms? If 
> there are divergent API extensions, how is that handled from a proxying point 
> of view if not all underlying OpenStack clouds necessarily support it (I 
> guess same applies when using distributions without additional extensions but 
> of different versions - e.g. Icehouse vs Juno which I believe was also a 
> targeted use case?)?

It's not about divergent northband API extension. Services between
Openstack projects are SOA based, this is a vertical splitting, so
when building large and distributed system (whatever it is) with
horizontal splitting, shouldn't we prefer clear and stable RESTful
interface between these building blocks?

>> 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)?
> Similarly though, is the intent with Cascading that each new project would 
> have to also implement and provide a proxy for use in these deployments? One 
> of the challenges with maintaining/supporting the existing Cells 
> implementation has been that it's effectively it's own thing and as a result 
> it is often not considered when adding new functionality.

Yes we need a new proxy, but nova proxy is just a new type of virt
driver, neutron proxy a new type of agent, cinder proxy a new type of
volume store...They just utilize existing standard driver/agent
mechanism, no influence on other code in tree.

>> 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.
> Right, but the proxies still appear to be a not insignificant amount of code 
> - is the intent not that the proxies would eventually reside within the 
> relevant projects? I've been assuming yes but I am wondering if this was an 
> incorrect assumption on my part based on your comment.
> Thanks,
> Steve
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

OpenStack-dev mailing list

Reply via email to