<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:宋体;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"\@宋体";
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:宋体;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:宋体;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"批注框文本 Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:9.0pt;
font-family:宋体;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin:0cm;
margin-bottom:.0001pt;
text-indent:21.0pt;
font-size:12.0pt;
font-family:宋体;}
span.Char
{mso-style-name:"批注框文本 Char";
mso-style-priority:99;
mso-style-link:批注框文本;
font-family:宋体;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="ZH-CN" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US">Hi Joe, <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Thank you to lead us to deep diving into cascading. My answer is listed below your question.
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">> I don't think this is sufficient. If the underlying hardware the
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">> between multiple vendors is different setting the same values for
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">> a flavor will result in different performance characteristics.
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">> For example, nova allows for setting VCPUs, but nova doesn't provide<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">> an easy way to define how powerful a VCPU is. Also flavors are commonly<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">> hardware dependent, take what rackspace offers:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">> <a href="http://www.rackspace.com/cloud/public-pricing#cloud-servers">
http://www.rackspace.com/cloud/public-pricing#cloud-servers</a><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">> Rackspace has "I/O Optimized" flavors<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">> * High-performance, RAID 10-protected SSD storage<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">> * Option of booting from Cloud Block Storage (additional charges apply
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">> for Cloud Block Storage)<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">> * Redundant 10-Gigabit networking<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">> * Disk I/O scales with the number of data disks up to ~80,000 4K random
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">> read IOPS and ~70,000 4K random write IOPS.*<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">> How would cascading support something like this?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">[joehuang] Just reminder you that the cascading works like a normal OpenStack, if it can be solved by one OpenStack instance, it should be feasible
too in cascading through the self-similar mechanism used ( just treat the cascaded OpenStack as one huge compute node ). The only difference between cascading OpenStack and normal OpenStack is that the agent/driver processes running on compute-node /cinder-volume
node / L2/L3 agent.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">Let me give an example how the issues you mentioned can be solved in cascading.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">Suppose that we have one cascading OpenStack (OpenStack0), two cascaded OpenStack( OpenStack1, OpenStack2 )<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">For OpenStack1: there are 5 compute nodes in OpenStack1 with “High-performance, RAID 10-protected SSD storage”, we can add these 5 nodes to host
aggregate “SSD” with extra spec (Storage:SSD), there are another 5 nodes booting from Cloud Block Storage, we can add these 5 nodes to host aggregate “cloudstorage” with extra spec (Storage:cloud). All these 10 nodes belongs to AZ1 (availability zone 1)<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">For OpenStack2: there are 5 compute nodes in OpenStack2 with “Redundant 10-Gigabit networking”, we can add these 5 nodes to host aggregate “SSD”
with extra spec (Storage:SSD), there are another 5 nodes with random access to volume with QoS requirement, we can add these 5 nodes to host aggregate “randomio” with extra spec (IO:random). All these 10 nodes belongs to AZ2 (availability zone 2). We can define
volume QoS associated with volume-type: vol-type-random-qos.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">In the cascading OpenStack, add compute-node1 as the proxy-node (proxy-node1) for the cascaded OpenStack1, add compute-node2 as the proxy-node
(proxy-node2) for the cascaded OpenStack2. From the information described for cascaded OpenStack, add proxy-node1 to AZ1, and host aggregate “SSD” and “cloudstorage”, add proxy-node2 to AZ2, and host aggregate “SSD” and “randomio”, cinder-proxy running on
proxy-node2 will retrieve the volume type with QoS information from the cascaded OpenStack2. After that, the tenant user or the cloud admin can define “Flavor” with extra-spec which will be matched with host-aggregate spec.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">In the cascading layer, you need to configure the regarding scheduler filter.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">Now: if you boot a VM in AZ1 with flavor (Storage:SSD), the request will be scheduled to proxy-node1, and the request will be reassembled as restful
request to cascaded OpenStack1, and the node which were added into SSD host aggregate will be scheduled just like a normal OpenStack done.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">if you boot a VM in AZ2 with flavor (Storage:SSD), the request will be scheduled to proxy-node2, and the request will be reassembled as restful
request to cascaded OpenStack2, and the node which were added into SSD host aggregate will be scheduled just like a normal OpenStack done.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">But if you boot a VM in AZ2 with flavor (randomio), the request will be scheduled to proxy-node2, and the request will be reassembled as restful
request to cascaded OpenStack2, and the node which were added into randomio host aggregate will be scheduled just like a normal OpenStack done. If you attach a volume which was created with the volume-type “vol-type-random-qos” in AZ2 to VM2, and the qos for
VM to access volume will also taken into effect.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">I just give a relative easy to understand example, more complicated use cases can also be settled using the cascading amazing self-similar mechanism,
I called it as FRACTAL (fantastic math) pattern (<a href="https://www.linkedin.com/pulse/20140729022031-23841540-openstack-cascading-and-fractal?trk=prof-post">https://www.linkedin.com/pulse/20140729022031-23841540-openstack-cascading-and-fractal?trk=prof-post</a>).<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">Best regards<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">Chaoyi Huang ( joehuang )<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Joe Gordon [mailto:joe.gordon0@gmail.com]
<br>
<b>Sent:</b> Friday, December 12, 2014 11:29 AM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [all] [tc] [PTL] Cascading vs. Cells - summit recap and move forward<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US">On Thu, Dec 11, 2014 at 6:25 PM, joehuang <<a href="mailto:joehuang@huawei.com" target="_blank">joehuang@huawei.com</a>> wrote:<o:p></o:p></span></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">Hello, Joe</span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">Thank you for your good question.
</span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">Question:</span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US">How would something like flavors work across multiple vendors. The OpenStack API doesn't have any hard coded names and sizes for flavors. So a flavor such as
m1.tiny may actually be very different vendor to vendor.<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">Answer:</span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">The flavor is defined by Cloud Operator from the cascading OpenStack. And Nova-proxy
( which is the driver for “Nova as hypervisor” ) will sync the flavor to the cascaded OpenStack when it was first used in the cascaded OpenStack. If flavor was changed before a new VM is booted, the changed flavor will also be updated to the cascaded OpenStack
just before the new VM booted request. Through this synchronization mechanism, all flavor used in multi-vendor’s cascaded OpenStack will be kept the same as what used in the cascading level, provide a consistent view for flavor.</span><span lang="EN-US"><o:p></o:p></span></p>
</div>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">I don't think this is sufficient. If the underlying hardware the between multiple vendors is different setting the same values for a flavor will result in different performance characteristics. For example, nova allows
for setting VCPUs, but nova doesn't provide an easy way to define how powerful a VCPU is. Also flavors are commonly hardware dependent, take what rackspace offers:<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><a href="http://www.rackspace.com/cloud/public-pricing#cloud-servers">http://www.rackspace.com/cloud/public-pricing#cloud-servers</a><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">Rackspace has "I/O Optimized" flavors<o:p></o:p></span></p>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">* High-performance, RAID 10-protected SSD storage<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">* Option of booting from Cloud Block Storage (additional charges apply for Cloud Block Storage)<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">* Redundant 10-Gigabit networking<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">* Disk I/O scales with the number of data disks up to ~80,000 4K random read IOPS and ~70,000 4K random write IOPS.*<o:p></o:p></span></p>
</div>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">How would cascading support something like this?<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"> <o:p></o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">Best Regards</span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">Chaoyi Huang ( joehuang )</span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><span lang="EN-US"><o:p></o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Joe
Gordon [mailto:<a href="mailto:joe.gordon0@gmail.com" target="_blank">joe.gordon0@gmail.com</a>]
<br>
<b>Sent:</b> Friday, December 12, 2014 8:17 AM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)</span><span lang="EN-US"><o:p></o:p></span></p>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US"><br>
<b>Subject:</b> Re: [openstack-dev] [all] [tc] [PTL] Cascading vs. Cells - summit recap and move forward<o:p></o:p></span></p>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US"> <o:p></o:p></span></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US"> <o:p></o:p></span></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US"> <o:p></o:p></span></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US">On Thu, Dec 11, 2014 at 1:02 AM, joehuang <<a href="mailto:joehuang@huawei.com" target="_blank">joehuang@huawei.com</a>> wrote:<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US">Hello, Russell,<br>
<br>
Many thanks for your reply. See inline comments.<br>
<br>
-----Original Message-----<br>
From: Russell Bryant [mailto:<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</a>]<br>
Sent: Thursday, December 11, 2014 5:22 AM<br>
To: <a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] [all] [tc] [PTL] Cascading vs. Cells – summit recap and move forward<br>
<br>
>> On Fri, Dec 5, 2014 at 8:23 AM, joehuang <<a href="mailto:joehuang@huawei.com" target="_blank">joehuang@huawei.com</a>> wrote:<br>
>>> Dear all & TC & PTL,<br>
>>><br>
>>> In the 40 minutes cross-project summit session “Approaches for<br>
>>> scaling out”[1], almost 100 peoples attended the meeting, and the<br>
>>> conclusion is that cells can not cover the use cases and<br>
>>> requirements which the OpenStack cascading solution[2] aim to<br>
>>> address, the background including use cases and requirements is also<br>
>>> described in the mail.<br>
<br>
>I must admit that this was not the reaction I came away with the discussion with.<br>
>There was a lot of confusion, and as we started looking closer, many (or perhaps most)<br>
>people speaking up in the room did not agree that the requirements being stated are<br>
>things we want to try to satisfy.<br>
<br>
[joehuang] Could you pls. confirm your opinion: 1) cells can not cover the use cases and requirements which the OpenStack cascading solution aim to address. 2) Need further discussion whether to satisfy the use cases and requirements.<br>
<br>
On 12/05/2014 06:47 PM, joehuang wrote:<br>
>>> Hello, Davanum,<br>
>>><br>
>>> Thanks for your reply.<br>
>>><br>
>>> Cells can't meet the demand for the use cases and requirements described in the mail.<br>
<br>
>You're right that cells doesn't solve all of the requirements you're discussing.<br>
>Cells addresses scale in a region. My impression from the summit session<br>
> and other discussions is that the scale issues addressed by cells are considered<br>
> a priority, while the "global API" bits are not.<br>
<br>
[joehuang] Agree cells is in the first class priority.<br>
<br>
>>> 1. Use cases<br>
>>> a). Vodafone use case[4](OpenStack summit speech video from 9'02"<br>
>>> to 12'30" ), establishing globally addressable tenants which result<br>
>>> in efficient services deployment.<br>
<br>
> Keystone has been working on federated identity.<br>
>That part makes sense, and is already well under way.<br>
<br>
[joehuang] The major challenge for VDF use case is cross OpenStack networking for tenants. The tenant's VM/Volume may be allocated in different data centers geographically, but virtual network (L2/L3/FW/VPN/LB) should be built for each tenant automatically
and isolated between tenants. Keystone federation can help authorization automation, but the cross OpenStack network automation challenge is still there.<br>
Using prosperity orchestration layer can solve the automation issue, but VDF don't like prosperity API in the north-bound, because no ecosystem is available. And other issues, for example, how to distribute image, also cannot be solved by Keystone federation.<br>
<br>
>>> b). Telefonica use case[5], create virtual DC( data center) cross<br>
>>> multiple physical DCs with seamless experience.<br>
<br>
>If we're talking about multiple DCs that are effectively local to each other<br>
>with high bandwidth and low latency, that's one conversation.<br>
>My impression is that you want to provide a single OpenStack API on top of<br>
>globally distributed DCs. I honestly don't see that as a problem we should<br>
>be trying to tackle. I'd rather continue to focus on making OpenStack work<br>
>*really* well split into regions.<br>
> I think some people are trying to use cells in a geographically distributed way,<br>
> as well. I'm not sure that's a well understood or supported thing, though.<br>
> Perhaps the folks working on the new version of cells can comment further.<br>
<br>
[joehuang] 1) Splited region way cannot provide cross OpenStack networking automation for tenant. 2) exactly, the motivation for cascading is "single OpenStack API on top of globally distributed DCs". Of course, cascading can also be used for DCs close to each
other with high bandwidth and low latency. 3) Folks comment from cells are welcome.<br>
.<br>
<br>
>>> c). ETSI NFV use cases[6], especially use case #1, #2, #3, #5, #6,<br>
>>> 8#. For NFV cloud, it’s in nature the cloud will be distributed but<br>
>>> inter-connected in many data centers.<br>
<br>
>I'm afraid I don't understand this one. In many conversations about NFV, I haven't heard this before.<br>
<br>
[joehuang] This is the ETSI requirement and use cases specification for NFV. ETSI is the home of the Industry Specification Group for NFV. In Figure 14 (virtualization of EPC) of this document, you can see that the operator's cloud including many data centers
to provide connection service to end user by inter-connected VNFs. The requirements listed in (<a href="https://wiki.openstack.org/wiki/TelcoWorkingGroup" target="_blank">https://wiki.openstack.org/wiki/TelcoWorkingGroup</a>) is mainly about the requirements
from specific VNF(like IMS, SBC, MME, HSS, S/P GW etc) to run over cloud, eg. migrate the traditional telco. APP from prosperity hardware to cloud. Not all NFV requirements have been covered yet. Forgive me there are so many telco terms here.<br>
<br>
>><br>
>>> 2.requirements<br>
>>> a). The operator has multiple sites cloud; each site can use one or<br>
>>> multiple vendor’s OpenStack distributions.<br>
<br>
>Is this a technical problem, or is a business problem of vendors not<br>
>wanting to support a mixed environment that you're trying to work<br>
>around with a technical solution?<br>
<br>
[joehuang] Pls. refer to VDF use case, the multi-vendor policy has been stated very clearly: 1) Local relationships: Operating Companies also have long standing relationships to their own choice of vendors; 2) Multi-Vendor :Each site can use one or multiple
vendors which leads to better use of local resources and capabilities. Technical solution must be provided for multi-vendor integration and verification, It's usually ETSI standard in the past for mobile network. But how to do that in multi-vendor's cloud
infrastructure? Cascading provide a way to use OpenStack API as the integration interface.<o:p></o:p></span></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US">How would something like flavors work across multiple vendors. The OpenStack API doesn't have any hard coded names and sizes for flavors. So a flavor such as
m1.tiny may actually be very different vendor to vendor.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US"> <o:p></o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US"><br>
>> b). Each site with its own requirements and upgrade schedule while<br>
>> maintaining standard OpenStack API c). The multi-site cloud must<br>
>> provide unified resource management with global Open API exposed, for<br>
>> example create virtual DC cross multiple physical DCs with seamless<br>
>> experience.<br>
<br>
>> Although a prosperity orchestration layer could be developed for the<br>
>> multi-site cloud, but it's prosperity API in the north bound<br>
>> interface. The cloud operators want the ecosystem friendly global<br>
>> open API for the mutli-site cloud for global access.<br>
<br>
>I guess the question is, do we see a "global API" as something we want<br>
>to accomplish. What you're talking about is huge, and I'm not even sure<br>
>how you would expect it to work in some cases (like networking).<br>
<br>
[joehuang] Yes, the most challenge part is networking. In the PoC, L2 networking cross OpenStack is to leverage the L2 population mechanism.The L2proxy for DC1 in the cascading layer will detect the new VM1(in DC1)'s port is up, and then ML2 L2 population will
be activated, the VM1's tunneling endpoint- host IP or L2GW IP in DC1, will be populated to L2proxy for DC2, and L2proxy for DC2 will create a external port in the DC2 Neutron with the VM1's tunneling endpoint- host IP or L2GW IP in DC1. The external port
will be attached to the L2GW or only external port created, L2 population(if not L2GW used) inside DC2 can be activated to notify all VMs located in DC2 for the same L2 network. For L3 networking finished in the PoC is to use extra route over GRE to serve
local VLAN/VxLAN networks located in different DCs. Of course, other L3 networking method can be developed, for example, through VPN service. There are 4 or 5 BPs talking about edge network gateway to connect OpenStack tenant network to outside network, all
these technologies can be leveraged to do cross OpenStack networking for different scenario. To experience the cross OpenStack networking, please try PoC source code:
<a href="https://github.com/stackforge/tricircle" target="_blank">https://github.com/stackforge/tricircle</a><o:p></o:p></span></p>
</blockquote>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"><span lang="EN-US">>In any case, to be as clear as possible, I'm not convinced this is something<br>
>we should be working on. I'm going to need to see much more<br>
>overwhelming support for the idea before helping to figure out any further steps.<br>
<br>
[joehuang] If you or any other have any doubts, please feel free to ignite a discussion thread. For time difference reason, we (working in China) are not able to join most of IRC meeting, so mail-list is a good way for discussion.<br>
<br>
Russell Bryant<br>
<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>
<br>
<br>
Best Regards<br>
<br>
Chaoyi Huang ( joehuang )<o:p></o:p></span></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US">_______________________________________________<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><o:p></o:p></span></p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US"> <o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">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><o:p></o:p></span></p>
</blockquote>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
</div>
</div>
</body>
</html>