<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style id="owaParaStyle">P {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
</style>
</head>
<body fPStyle="1" ocsi="0">
<div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;">
<p>Hello, John Griffith,</p>
<p> </p>
<p>Thank you very much for your funny mail. Now I see 2 "John G" ;)</p>
<p> </p>
<p>I would like to say that TrippleO is the pioneer to handle the correlationship among the OpenStack instances. Cheer.</p>
<p> </p>
<p>The problem domain for OpenStack cascading is multi-site / multi-vendor OpenStack instances integration. Based on this, the large scale cloud can be distributed in many data centers, and fault isolation / trouble shooting / configuration change / upgrade
/ patch /... can be done seperated by different OpenStack instance.</p>
<p> </p>
<p>For example, a cloud includes 2 data center, vendor A sold their OpenStack solution in data center A, vendor B sold their OpenStack solution in data center B. If a criticle bug found in data center B, then the vendor B is reponsible for the bug fix and patch
update. Clear duty responsiblity with independent OpenStack instances, even for the integration of software / hardware .
</p>
<p> </p>
<div>Best Regards<br>
<br>
Chaoyi Huang ( joehuang)<br>
</div>
<p> </p>
<p></p>
<hr tabindex="-1">
<p></p>
<div style="FONT-FAMILY: Times New Roman; COLOR: #000000; FONT-SIZE: 16px">
<div style="DIRECTION: ltr" id="divRpF215870"><font color="#000000" size="2" face="Tahoma"><b>From:</b> John Griffith [john.griffith@solidfire.com]<br>
<b>Sent:</b> 01 October 2014 0:10<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading<br>
</font><br>
</div>
<div></div>
<div>
<div dir="ltr">
<div style="FONT-FAMILY: courier new,monospace" class="gmail_default"><br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Sep 30, 2014 at 7:35 AM, John Garbutt <span dir="ltr">
<<a href="mailto:john@johngarbutt.com" target="_blank">john@johngarbutt.com</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">
<span>On 30 September 2014 14:04, joehuang <<a href="mailto:joehuang@huawei.com" target="_blank">joehuang@huawei.com</a>> wrote:<br>
> Hello, Dear TC and all,<br>
><br>
> Large cloud operators prefer to deploy multiple OpenStack instances(as different zones), rather than a single monolithic OpenStack instance because of these reasons:<br>
><br>
> 1) Multiple data centers distributed geographically;<br>
> 2) Multi-vendor business policy;<br>
> 3) Server nodes scale up modularized from 00's up to million;<br>
> 4) Fault and maintenance isolation between zones (only REST interface);<br>
><br>
> At the same time, they also want to integrate these OpenStack instances into one cloud. Instead of proprietary orchestration layer, they want to use standard OpenStack framework for Northbound API compatibility with HEAT/Horizon or other 3rd ecosystem apps.<br>
><br>
> We call this pattern as "OpenStack Cascading", with proposal described by [1][2]. PoC live demo video can be found[3][4].<br>
><br>
> Nova, Cinder, Neutron, Ceilometer and Glance (optional) are involved in the OpenStack cascading.<br>
><br>
> Kindly ask for cross program design summit session to discuss OpenStack cascading and the contribution to Kilo.<br>
><br>
> Kindly invite those who are interested in the OpenStack cascading to work together and contribute it to OpenStack.<br>
><br>
> (I applied for “other projects” track [5], but it would be better to have a discussion as a formal cross program session, because many core programs are involved )<br>
><br>
><br>
> [1] wiki: <a href="https://wiki.openstack.org/wiki/OpenStack_cascading_solution" target="_blank">
https://wiki.openstack.org/wiki/OpenStack_cascading_solution</a><br>
> [2] PoC source code: <a href="https://github.com/stackforge/tricircle" target="_blank">
https://github.com/stackforge/tricircle</a><br>
> [3] Live demo video at YouTube: <a href="https://www.youtube.com/watch?v=OSU6PYRz5qY" target="_blank">
https://www.youtube.com/watch?v=OSU6PYRz5qY</a><br>
> [4] Live demo video at Youku (low quality, for those who can't access YouTube)：<a href="http://v.youku.com/v_show/id_XNzkzNDQ3MDg4.html" target="_blank">http://v.youku.com/v_show/id_XNzkzNDQ3MDg4.html</a><br>
> [5] <a href="http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg36395.html" target="_blank">
http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg36395.html</a><br>
<br>
</span>There are etherpads for suggesting cross project sessions here:<br>
<a href="https://wiki.openstack.org/wiki/Summit/Planning" target="_blank">https://wiki.openstack.org/wiki/Summit/Planning</a><br>
<a href="https://etherpad.openstack.org/p/kilo-crossproject-summit-topics" target="_blank">https://etherpad.openstack.org/p/kilo-crossproject-summit-topics</a><br>
<br>
I am interested at comparing this to Nova's cells concept:<br>
<a href="http://docs.openstack.org/trunk/config-reference/content/section_compute-cells.html" target="_blank">http://docs.openstack.org/trunk/config-reference/content/section_compute-cells.html</a><br>
<br>
Cells basically scales out a single datacenter region by aggregating<br>
multiple child Nova installations with an API cell.<br>
<br>
Each child cell can be tested in isolation, via its own API, before<br>
joining it up to an API cell, that adds it into the region. Each cell<br>
logically has its own database and message queue, which helps get more<br>
independent failure domains. You can use cell level scheduling to<br>
restrict people or types of instances to particular subsets of the<br>
cloud, if required.<br>
<br>
It doesn't attempt to aggregate between regions, they are kept<br>
independent. Except, the usual assumption that you have a common<br>
identity between all regions.<br>
<br>
It also keeps a single Cinder, Glance, Neutron deployment per region.<br>
<br>
It would be great to get some help hardening, testing, and building<br>
out more of the cells vision. I suspect we may form a new Nova subteam<br>
to trying and drive this work forward in kilo, if we can build up<br>
enough people wanting to work on improving cells.<br>
<br>
Thanks,<br>
John<br>
<div class="HOEnZb">
<div class="h5"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<div class="gmail_extra">
<div style="FONT-FAMILY: 'courier new',monospace" class="gmail_default">Interesting idea, to be honest when TripleO was first announced what you have here is more along the lines of what I envisioned. It seems that this would have some interesting wins in
terms of upgrades, migrations and scaling in general. Anyway, you should propose it to the etherpad as John G ( the other John G :) ) recommended, I'd love to dig deeper into this.</div>
<div style="FONT-FAMILY: 'courier new',monospace" class="gmail_default"><br>
</div>
<div style="FONT-FAMILY: 'courier new',monospace" class="gmail_default">Thanks,</div>
<div style="FONT-FAMILY: 'courier new',monospace" class="gmail_default">John</div>
<br>
</div>
</div>
</div>
</div>
</div>
</body>
</html>