<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 09/30/2014 12:10 PM, John Griffith
wrote:<br>
</div>
<blockquote
cite="mid:CA+qL3LWXzCtuEHqcw5XZeVmNQS3sqW40aDrzK4egYB0XkC9w-A@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_default" style="font-family:courier
new,monospace"><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 moz-do-not-send="true"
href="mailto:john@johngarbutt.com" target="_blank">john@johngarbutt.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span
class="">On 30 September 2014 14:04, joehuang <<a
moz-do-not-send="true"
href="mailto:joehuang@huawei.com">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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="https://github.com/stackforge/tricircle"
target="_blank">https://github.com/stackforge/tricircle</a><br>
> [3] Live demo video at YouTube: <a
moz-do-not-send="true"
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
moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="https://wiki.openstack.org/wiki/Summit/Planning"
target="_blank">https://wiki.openstack.org/wiki/Summit/Planning</a><br>
<a moz-do-not-send="true"
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 moz-do-not-send="true"
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>
</blockquote>
</div>
</div>
</div>
</blockquote>
<br>
I'm starting on work to support a comparable mechanism to share data
between Keystone servers.<br>
<br>
<a class="moz-txt-link-freetext" href="http://adam.younglogic.com/2014/09/multiple-signers/">http://adam.younglogic.com/2014/09/multiple-signers/</a><br>
<br>
<br>
<blockquote
cite="mid:CA+qL3LWXzCtuEHqcw5XZeVmNQS3sqW40aDrzK4egYB0XkC9w-A@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
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 moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a moz-do-not-send="true"
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 class="gmail_default" style="font-family:'courier
new',monospace">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>
</div>
</blockquote>
<br>
<br>
<br>
<br>
<br>
<blockquote
cite="mid:CA+qL3LWXzCtuEHqcw5XZeVmNQS3sqW40aDrzK4egYB0XkC9w-A@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_default" style="font-family:'courier
new',monospace"><br>
</div>
<div class="gmail_default" style="font-family:'courier
new',monospace">Thanks,</div>
<div class="gmail_default" style="font-family:'courier
new',monospace">John</div>
<br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>