<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=gb2312">
<meta name="Generator" content="Microsoft Word 12 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:SimSun;
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:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:"\@SimSun";
panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:SimSun;}
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:SimSun;}
tt
{mso-style-priority:99;
font-family:SimSun;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:2015110489;
mso-list-template-ids:-123455348;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></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="EN-CA" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Kai Qiang,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">A major benefit is to have Magnum manage the COEs for end-users. Currently, Magnum basically have its end-users manage the COEs by themselves after a successful
deployment. This might work well for domain users, but it is a pain for non-domain users to manage their COEs. By moving master nodes out of users¡¯ tenants, Magnum could offer users a COE management service. For example, Magnum could offer to monitor the etcd/swarm-manage
clusters and recover them on failure. Again, the pattern of managing COEs for end-users is what Google container service and AWS container service offer. I guess it is fair to conclude that there are use cases out there?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">If we decide to offer a COE management service, we could discuss further on how to consolidate the IaaS resources for improving utilization. Solutions could
be (i) introducing a centralized control services for all tenants/clusters, or (ii) keeping the control services separated but isolating them by containers (instead of VMs). A typical use case is what Kris mentioned below.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Best regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Hongbin<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div>
<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""> Kai Qiang Wu [mailto:wkqwu@cn.ibm.com]
<br>
<b>Sent:</b> February-13-16 11:32 PM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [magnum]swarm + compose = k8s?<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p>Hi HongBin and Egor,<br>
I went through what you talked about, and thinking what's the great benefits for utilisation here.<br>
For user cases, looks like following:<br>
<br>
user A want to have a COE provision.<br>
user B want to have a separate COE. (different tenant, non-share)<br>
user C want to use existed COE (same tenant as User A, share)<br>
<br>
When you talked about utilisation case, it seems you mentioned:<br>
different tenant users want to use same control node to manage different nodes, it seems that try to make COE openstack tenant aware, it also means you want to introduce another control schedule layer above the COEs, we need to think about the if it is typical
user case, and what's the benefit compared with containerisation. <br>
<br>
<br>
And finally, it is a topic can be discussed in middle cycle meeting. <br>
<br>
<br>
Thanks<br>
<br>
Best Wishes,<br>
--------------------------------------------------------------------------------<br>
Kai Qiang Wu (<span lang="ZH-CN">Î⿪ǿ</span> Kennan<span lang="ZH-CN">£©</span><br>
IBM China System and Technology Lab, Beijing<br>
<br>
E-mail: <a href="mailto:wkqwu@cn.ibm.com">wkqwu@cn.ibm.com</a><br>
Tel: 86-10-82451647<br>
Address: Building 28(Ring Building), ZhongGuanCun Software Park, <br>
No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193<br>
--------------------------------------------------------------------------------<br>
Follow your heart. You are miracle! <br>
<br>
<img border="0" width="16" height="16" id="_x0000_i1025" src="cid:image001.gif@01D1671D.0ACEE9E0" alt="Inactive hide details for Hongbin Lu ---13/02/2016 11:02:13 am---Egor, Thanks for sharing your insights. I gave it more thought"><span style="color:#424282">Hongbin
Lu ---13/02/2016 11:02:13 am---Egor, Thanks for sharing your insights. I gave it more thoughts. Maybe the goal can be achieved with</span><br>
<br>
<span style="font-size:10.0pt;color:#5F5F5F">From: </span><span style="font-size:10.0pt">Hongbin Lu <<a href="mailto:hongbin.lu@huawei.com">hongbin.lu@huawei.com</a>></span><br>
<span style="font-size:10.0pt;color:#5F5F5F">To: </span><span style="font-size:10.0pt">Guz Egor <<a href="mailto:guz_egor@yahoo.com">guz_egor@yahoo.com</a>>, "OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>></span><br>
<span style="font-size:10.0pt;color:#5F5F5F">Date: </span><span style="font-size:10.0pt">13/02/2016 11:02 am</span><br>
<span style="font-size:10.0pt;color:#5F5F5F">Subject: </span><span style="font-size:10.0pt">Re: [openstack-dev] [magnum]swarm + compose = k8s?</span><o:p></o:p></p>
<div class="MsoNormal">
<hr size="2" width="100%" noshade="" style="color:#8091A5" align="left">
</div>
<p class="MsoNormal"><br>
<br>
<br>
<span style="font-family:"Calibri","sans-serif";color:#1F497D">Egor,</span><br>
<br>
<span style="font-family:"Calibri","sans-serif";color:#1F497D">Thanks for sharing your insights. I gave it more thoughts. Maybe the goal can be achieved without implementing a shared COE. We could move all the master nodes out of user tenants, containerize
them, and consolidate them into a set of VMs/Physical servers.</span><br>
<br>
<span style="font-family:"Calibri","sans-serif";color:#1F497D">I think we could separate the discussion into two:</span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:72.0pt"><span style="font-family:"Calibri","sans-serif";color:#1F497D">1. Should Magnum introduce a new bay type, in which master nodes are managed by Magnum (not users themselves)? Like what GCE [1] or ECS [2] does.</span><br>
<span style="font-family:"Calibri","sans-serif";color:#1F497D">2. How to consolidate the control services that originally runs on master nodes of each cluster?</span><o:p></o:p></p>
<p class="MsoNormal"><br>
<span style="font-family:"Calibri","sans-serif";color:#1F497D">Note that the proposal is for adding a new COE (not for changing the existing COEs). That means users will continue to provision existing self-managed COE (k8s/swarm/mesos) if they choose to.</span><br>
<br>
<span style="font-family:"Calibri","sans-serif";color:#1F497D">[1] </span><a href="https://cloud.google.com/container-engine/"><span style="font-family:"Calibri","sans-serif"">https://cloud.google.com/container-engine/</span></a><br>
<span style="font-family:"Calibri","sans-serif";color:#1F497D">[2] </span><a href="http://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html"><span style="font-family:"Calibri","sans-serif"">http://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html</span></a><br>
<br>
<span style="font-family:"Calibri","sans-serif";color:#1F497D">Best regards,</span><br>
<span style="font-family:"Calibri","sans-serif";color:#1F497D">Hongbin</span><br>
<br>
<b><span style="font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-family:"Tahoma","sans-serif""> Guz Egor [<a href="mailto:guz_egor@yahoo.com">mailto:guz_egor@yahoo.com</a>]
<b><br>
Sent:</b> February-12-16 2:34 PM<b><br>
To:</b> OpenStack Development Mailing List (not for usage questions)<b><br>
Cc:</b> Hongbin Lu<b><br>
Subject:</b> Re: [openstack-dev] [magnum]swarm + compose = k8s?</span><br>
<br>
<span style="font-size:13.5pt;font-family:"Arial","sans-serif"">Hongbin,</span><br>
<br>
<span style="font-family:"Helvetica","sans-serif"">I am not sure that it's good idea, it looks you propose Magnum enter to "schedulers war" (personally I tired from these debates Mesos vs Kub vs Swarm).</span><br>
<span style="font-family:"Helvetica","sans-serif"">If your concern is just utilization you can always run control plane at "agent/slave" nodes, there main reason why operators (at least in our case) keep them</span><br>
<span style="font-family:"Helvetica","sans-serif"">separate because they need different attention (e.g. I almost don't care why/when "agent/slave" node died, but always double check that master node was
</span><br>
<span style="font-family:"Helvetica","sans-serif"">repaired or replaced). </span>
<br>
<br>
<span style="font-family:"Helvetica","sans-serif"">One use case I see for shared COE (at least in our environment), when developers want run just docker container without installing anything locally
</span><br>
<span style="font-family:"Helvetica","sans-serif"">(e.g docker-machine). But in most cases it's just examples from internet or there own experiments ):
</span><br>
<br>
<span style="font-family:"Helvetica","sans-serif"">But we definitely should discuss it during midcycle next week.
</span><br>
<br>
<span style="font-family:"Helvetica","sans-serif"">--- </span><br>
<span style="font-family:"Helvetica","sans-serif"">Egor</span><o:p></o:p></p>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="2" width="100%" align="center">
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-family:"Arial","sans-serif"">From:</span></b><span style="font-family:"Arial","sans-serif""> Hongbin Lu <</span><a href="mailto:hongbin.lu@huawei.com"><span style="font-family:"Arial","sans-serif"">hongbin.lu@huawei.com</span></a><span style="font-family:"Arial","sans-serif"">><b><br>
To:</b> OpenStack Development Mailing List (not for usage questions) <</span><a href="mailto:openstack-dev@lists.openstack.org"><span style="font-family:"Arial","sans-serif"">openstack-dev@lists.openstack.org</span></a><span style="font-family:"Arial","sans-serif"">>
<b><br>
Sent:</b> Thursday, February 11, 2016 8:50 PM<b><br>
Subject:</b> Re: [openstack-dev] [magnum]swarm + compose = k8s?</span><br>
<br>
<span style="font-family:"Helvetica","sans-serif";color:#1F497D">Hi team,</span><br>
<br>
<span style="font-family:"Helvetica","sans-serif";color:#1F497D">Sorry for bringing up this old thread, but a recent debate on container resource [1] reminded me the use case Kris mentioned below. I am going to propose a preliminary idea to address the use
case. Of course, we could continue the discussion in the team meeting or midcycle.</span><br>
<br>
<b><span style="font-family:"Helvetica","sans-serif";color:#1F497D">Idea</span></b><span style="font-family:"Helvetica","sans-serif";color:#1F497D">: Introduce a docker-native COE, which consists of only minion/worker/slave nodes (no master nodes).</span><br>
<b><span style="font-family:"Helvetica","sans-serif";color:#1F497D">Goal</span></b><span style="font-family:"Helvetica","sans-serif";color:#1F497D">: Eliminate duplicated IaaS resources (master node VMs, lbaas vips, floating ips, etc.)</span><br>
<b><span style="font-family:"Helvetica","sans-serif";color:#1F497D">Details</span></b><span style="font-family:"Helvetica","sans-serif";color:#1F497D">: Traditional COE (k8s/swarm/mesos) consists of master nodes and worker nodes. In these COEs, control services
(i.e. scheduler) run on master nodes, and containers run on worker nodes. If we can port the COE control services to Magnum control plate and share them with all tenants, we eliminate the need of master nodes thus improving resource utilization. In the new
COE, users create/manage containers through Magnum API endpoints. Magnum is responsible to spin tenant VMs, schedule containers to the VMs, and manage the life-cycle of those containers. Unlike other COEs, containers created by this COE are considered as OpenStack-manage
resources. That means they will be tracked in Magnum DB, and accessible by other OpenStack services (i.e. Horizon, Heat, etc.).</span><br>
<br>
<span style="font-family:"Helvetica","sans-serif";color:#1F497D">What do you feel about this proposal? Let¡¯s discuss.</span><br>
<br>
<span style="font-family:"Helvetica","sans-serif";color:#1F497D">[1] </span><a href="https://etherpad.openstack.org/p/magnum-native-api" target="_blank"><span style="font-family:"Helvetica","sans-serif"">https://etherpad.openstack.org/p/magnum-native-api</span></a><br>
<br>
<span style="font-family:"Helvetica","sans-serif";color:#1F497D">Best regards,</span><br>
<span style="font-family:"Helvetica","sans-serif";color:#1F497D">Hongbin</span><br>
<br>
<b><span style="font-family:"Helvetica","sans-serif"">From:</span></b><span style="font-family:"Helvetica","sans-serif""> Kris G. Lindgren [</span><a href="mailto:klindgren@godaddy.com"><span style="font-family:"Helvetica","sans-serif"">mailto:klindgren@godaddy.com</span></a><span style="font-family:"Helvetica","sans-serif"">]
<b><br>
Sent:</b> September-30-15 7:26 PM<b><br>
To:</b> </span><a href="mailto:openstack-dev@lists.openstack.org"><span style="font-family:"Helvetica","sans-serif"">openstack-dev@lists.openstack.org</span></a><b><span style="font-family:"Helvetica","sans-serif""><br>
Subject:</span></b><span style="font-family:"Helvetica","sans-serif""> Re: [openstack-dev] [magnum]swarm + compose = k8s?</span><br>
<br>
<span style="font-family:"Helvetica","sans-serif"">We are looking at deploying magnum as an answer for how do we do containers company wide at Godaddy. I am going to agree with both you and josh.</span><br>
<br>
<span style="font-family:"Helvetica","sans-serif"">I agree that managing one large system is going to be a pain and pas experience tells me this wont be practical/scale, however from experience I also know exactly the pain Josh is talking about.</span><br>
<br>
<span style="font-family:"Helvetica","sans-serif"">We currently have ~4k projects in our internal openstack cloud, about 1/4 of the projects are currently doing some form of containers on their own, with more joining every day. If all of these projects were
to convert of to the current magnum configuration we would suddenly be attempting to support/configure ~1k magnum clusters. Considering that everyone will want it HA, we are looking at a minimum of 2 kube nodes per cluster + lbaas vips + floating ips. From
a capacity standpoint this is an excessive amount of duplicated infrastructure to spinup in projects where people maybe running 10¨C20 containers per project. From an operator support perspective this is a special level of hell that I do not want to get into.
Even if I am off by 75%, 250 still sucks.</span><br>
<br>
<span style="font-family:"Helvetica","sans-serif"">From my point of view an ideal use case for companies like ours (yahoo/godaddy) would be able to support hierarchical projects in magnum. That way we could create a project for each department, and then the
subteams of those departments can have their own projects. We create a a bay per department. Sub-projects if they want to can support creation of their own bays (but support of the kube cluster would then fall to that team). When a sub-project spins up a pod
on a bay, minions get created inside that teams sub projects and the containers in that pod run on the capacity that was spun up under that project, the minions for each pod would be a in a scaling group and as such grow/shrink as dictated by load.</span><br>
<br>
<span style="font-family:"Helvetica","sans-serif"">The above would make it so where we support a minimal, yet imho reasonable, number of kube clusters, give people who can't/don¡¯t want to fall inline with the provided resource a way to make their own and still
offer a "good enough for a single company" level of multi-tenancy.</span><br>
<span style="font-size:10.0pt;font-family:"Courier New";color:#535353">>Joshua,</span><br>
<span style="font-size:10.0pt;font-family:"Courier New";color:#535353">> </span><br>
<span style="font-size:10.0pt;font-family:"Courier New";color:#535353">>If you share resources, you give up multi-tenancy. No COE system has the</span><br>
<span style="font-size:10.0pt;font-family:"Courier New";color:#535353">>concept of multi-tenancy (kubernetes has some basic implementation but it</span><br>
<span style="font-size:10.0pt;font-family:"Courier New";color:#535353">>is totally insecure). Not only does multi-tenancy have to ¡°look like¡± it</span><br>
<span style="font-size:10.0pt;font-family:"Courier New";color:#535353">>offers multiple tenants isolation, but it actually has to deliver the</span><br>
<span style="font-size:10.0pt;font-family:"Courier New";color:#535353">>goods.</span><br>
<span style="font-size:10.0pt;font-family:"Courier New";color:#535353">> </span><br>
<span style="font-size:10.0pt;font-family:"Courier New";color:#535353">>I understand that at first glance a company like Yahoo may not want</span><br>
<span style="font-size:10.0pt;font-family:"Courier New";color:#535353">>separate bays for their various applications because of the perceived</span><br>
<span style="font-size:10.0pt;font-family:"Courier New";color:#535353">>administrative overhead. I would then challenge Yahoo to go deploy a COE</span><br>
<span style="font-size:10.0pt;font-family:"Courier New";color:#535353">>like kubernetes (which has no multi-tenancy or a very basic implementation</span><br>
<span style="font-size:10.0pt;font-family:"Courier New";color:#535353">>of such) and get it to work with hundreds of different competing</span><br>
<span style="font-size:10.0pt;font-family:"Courier New";color:#535353">>applications. I would speculate the administrative overhead of getting</span><br>
<span style="font-size:10.0pt;font-family:"Courier New";color:#535353">>all that to work would be greater then the administrative overhead of</span><br>
<span style="font-size:10.0pt;font-family:"Courier New";color:#535353">>simply doing a bay create for the various tenants.</span><br>
<span style="font-size:10.0pt;font-family:"Courier New";color:#535353">> </span><br>
<span style="font-size:10.0pt;font-family:"Courier New";color:#535353">>Placing tenancy inside a COE seems interesting, but no COE does that</span><br>
<span style="font-size:10.0pt;font-family:"Courier New";color:#535353">>today. Maybe in the future they will. Magnum was designed to present an</span><br>
<span style="font-size:10.0pt;font-family:"Courier New";color:#535353">>integration point between COEs and OpenStack today, not five years down</span><br>
<span style="font-size:10.0pt;font-family:"Courier New";color:#535353">>the road. Its not as if we took shortcuts to get to where we are.</span><br>
<span style="font-size:10.0pt;font-family:"Courier New";color:#535353">> </span><br>
<span style="font-size:10.0pt;font-family:"Courier New";color:#535353">>I will grant you that density is lower with the current design of Magnum</span><br>
<span style="font-size:10.0pt;font-family:"Courier New";color:#535353">>vs a full on integration with OpenStack within the COE itself. However,</span><br>
<span style="font-size:10.0pt;font-family:"Courier New";color:#535353">>that model which is what I believe you proposed is a huge design change to</span><br>
<span style="font-size:10.0pt;font-family:"Courier New";color:#535353">>each COE which would overly complicate the COE at the gain of increased</span><br>
<span style="font-size:10.0pt;font-family:"Courier New";color:#535353">>density. I personally don¡¯t feel that pain is worth the gain.</span><br>
<br>
<br>
<span style="font-family:"Helvetica","sans-serif"">___________________________________________________________________</span><br>
<span style="font-family:"Helvetica","sans-serif"">Kris Lindgren</span><br>
<span style="font-family:"Helvetica","sans-serif"">Senior Linux Systems Engineer</span><br>
<span style="font-family:"Helvetica","sans-serif"">GoDaddy</span><br>
<span style="font-size:13.5pt;font-family:"Helvetica","sans-serif""><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: </span><a href="mailto:OpenStack-dev-request@lists.openstack.org"><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif"">OpenStack-dev-request@lists.openstack.org</span></a><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif"">?subject:unsubscribe<u><span style="color:blue"><br>
</span></u></span><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif"">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</span></a><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif""><br>
</span><tt>__________________________________________________________________________</tt><br>
<tt>OpenStack Development Mailing List (not for usage questions)</tt><br>
<tt>Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a></tt><br>
<tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></tt><br>
<br>
<br>
<o:p></o:p></p>
</div>
</body>
</html>