<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=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:Wingdings;
        panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
        {font-family:Wingdings;
        panose-1:5 0 0 0 0 0 0 0 0 0;}
@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;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
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.MsoPlainText, li.MsoPlainText, div.MsoPlainText
        {mso-style-priority:99;
        mso-style-link:"Plain Text Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";}
span.EmailStyle17
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
span.PlainTextChar
        {mso-style-name:"Plain Text Char";
        mso-style-priority:99;
        mso-style-link:"Plain Text";
        font-family:"Calibri","sans-serif";}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri","sans-serif";}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
/* List Definitions */
@list l0
        {mso-list-id:225067205;
        mso-list-type:hybrid;
        mso-list-template-ids:2073621506 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
        {mso-level-number-format:bullet;
        mso-level-text:\F0B7;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:Symbol;}
@list l0:level2
        {mso-level-number-format:bullet;
        mso-level-text:o;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:"Courier New";
        mso-bidi-font-family:"Times New Roman";}
@list l0:level3
        {mso-level-number-format:bullet;
        mso-level-text:\F0A7;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:Wingdings;}
@list l0:level4
        {mso-level-number-format:bullet;
        mso-level-text:\F0B7;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:Symbol;}
@list l0:level5
        {mso-level-number-format:bullet;
        mso-level-text:o;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:"Courier New";
        mso-bidi-font-family:"Times New Roman";}
@list l0:level6
        {mso-level-number-format:bullet;
        mso-level-text:\F0A7;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:Wingdings;}
@list l0:level7
        {mso-level-number-format:bullet;
        mso-level-text:\F0B7;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:Symbol;}
@list l0:level8
        {mso-level-number-format:bullet;
        mso-level-text:o;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:"Courier New";
        mso-bidi-font-family:"Times New Roman";}
@list l0:level9
        {mso-level-number-format:bullet;
        mso-level-text:\F0A7;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:Wingdings;}
ol
        {margin-bottom:0in;}
ul
        {margin-bottom:0in;}
--></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-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoPlainText">I agree with Devananda here.   Also<span style="color:#1F497D">
</span>I would like to highlight the following with respect to the suggested Blueprints on proxy compute model:<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText" style="margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo1">
<![if !supportLists]><span style="font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">        
</span></span></span><![endif]>All the enhancements that are being talked about are in-line with the nova constructs and works with all the features of nova. 
<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText" style="margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo1">
<![if !supportLists]><span style="font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">        
</span></span></span><![endif]>What we are trying to bring out with the blueprint is to leverage the existing logical openstack construct "nova-compute".<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText" style="margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo1">
<![if !supportLists]><span style="font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">        
</span></span></span><![endif]>We are proposing to have a Cluster or Resourcepool represented as a "nova-compute"  where all the "nova-compute's" traits are kept intact and at the same time expose the hypervisor provided capabilities like DRS / HA etc.,<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoPlainText" style="margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo1">
<![if !supportLists]><span style="font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">        
</span></span></span><![endif]>With this BP implementation no change would be required to nova-scheduler and all the scheduler logic would work the same way as is with the added hidden advantage of leverage hypervisor features.<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoPlainText" style="margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo1">
<![if !supportLists]><span style="font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">        
</span></span></span><![endif]>More use cases possible with the "Host-aggregates" and the "Cluster or Resource pool" represented as "nova-compute".   For eg:  Adding Tenant affinity to a particular CLUSTER / RESOURCE POOL or a group of CLUSTER / Resource pool,   
 Add capability to deploy new instances to a group of DRS / HA enabled Cluster etc.,<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo1">
<![if !supportLists]><span style="font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">        
</span></span></span><![endif]>We have other blueprints wherein we are talking about using Glance, Cinder etc along with vCenter and has been demoed during the Havana Summit.  Following link provides additional details of the related blueprints: 
<span style="font-size:10.0pt;font-family:"Arial","sans-serif""><a href="http://www.openstack.org/summit/portland-2013/session-videos/presentation/proxy-compute-service-managing-multiple-vmware-vcenter-clusters-and-resource-pools"><b>Proxy Compute Service managing
 multiple VMware vCenter Clusters and Resource Pools</b></a></span><o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoPlainText">Hope this helps<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Thanks,<br>
Divakar<o:p></o:p></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"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Devananda van der Veen [mailto:devananda.vdv@gmail.com]
<br>
<b>Sent:</b> Thursday, May 09, 2013 10:01 PM<br>
<b>To:</b> OpenStack Development Mailing List<br>
<b>Subject:</b> Re: [openstack-dev] [Nova] virt driver architecture<br>
<b>Importance:</b> High<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Thu, May 9, 2013 at 8:45 AM, Sean Dague <<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>> wrote:<o:p></o:p></p>
<div>
<div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal">On 05/09/2013 10:53 AM, Russell Bryant wrote:<o:p></o:p></p>
<p class="MsoNormal">Greetings,<br>
<br>
I've been growing concerned with the evolution of Nova's architecture in<br>
terms of the virt drivers and the impact they have on the rest of Nova.<br>
  I've heard these concerns from others in private conversation.  Another<br>
thread on the list today pushed me to where I think it's time we talk<br>
about it:<br>
<br>
<a href="http://lists.openstack.org/pipermail/openstack-dev/2013-May/008801.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2013-May/008801.html</a><br>
<br>
At our last design summit, there was a discussion of adding a new virt<br>
driver to support oVirt (RHEVM).  That seems inappropriate for Nova to<br>
me.  oVirt is a full virt management system and uses libvirt+KVM<br>
hypervisors.  We use libvirt+KVM directly.  Punting off to yet another<br>
management system that wants to manage all of the same things as<br>
OpenStack seems like a broken architecture.  In fact, oVirt has done a<br>
lot of work to *consume* OpenStack resources (glance, quantum), which<br>
seems completely appropriate.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">+1<o:p></o:p></p>
<div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<p class="MsoNormal">Things get more complicated if we take that argument and apply it to<br>
other drivers that we already have in Nova.  In particular, I think this<br>
applies to the VMware (vCenter mode, not ESX mode) and Hyper-V drivers.<br>
  I'm not necessarily proposing that those drivers work significantly<br>
different.  I don't think that's practical if we want to support these<br>
systems.<br>
<br>
We now have two different types of drivers: those that manage individual<br>
hypervisor nodes, and those that proxy to much more complex systems.<br>
<br>
We need to be very aware of what's going on in all virt drivers, even<br>
the ones we don't care about as much because we don't use them.  We also<br>
need to continue to solidify the virt driver interface and be extremely<br>
cautious when these drivers require changes to other parts of Nova.<br>
Above all, let's make sure that evolution in this area is well thought<br>
out and done by conscious decision.<br>
<br>
Comments airing more specific concerns in this area would be appreciated.<o:p></o:p></p>
</blockquote>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">I think we learned a really important lesson in baremetal: putting a different complex management system underneath the virt driver interface is a bad fit, requires nova to do unnatural things, and just doesn't make anyone happy at the
 end of the day. That's since resulted in baremetal spinning out to a new incubated project, Ironic, which I think is really the right long term approach.<br>
<br>
I think we need to take that lesson for what it was, and realize these virt cluster drivers are very much the same kind of problem. They are better served living in some new incubated effort instead of force fitting into the nova-compute virt layer and driving
 a lot more complexity into nova.<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I don't feel like a new project is needed here -- the ongoing discussion about moving scheduling/orchestration logic out of nova-compute and into conductor-or-something-else seems to frame this discussion, too. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The biggest change to Nova that I recall around adding the Baremetal code was the addition of the "node" aka "hypervisor_hostname" concept -- that a single nova compute host might control more than one discrete thing, which thereby need
 to be identified as (host, node). That change opened the door for other cluster drivers to fit under the virt interface. IMBW, but I believe this is exactly what the vCenter and Hyper-V folks are looking at. It's also my current plan for Ironic. However, I
 also believe that this logic doesn't necessarily have to live under the virt API layer; I think it's a really good fit for the orchestration/conductor discussions....<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">We were talking about this a few days ago in -nova, particularly how moving some of the ComputeManager logic out to conductor might fit together with simplifying the (host, node) complexities, and help make nova-compute just a thin virt
 API layer. Here is a very poor summary of what I recall...<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">* AMQP topic is based on "nodename", not "hostname"<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">* for local hypervisors (KVM, etc), the topic identifies the local host, and the local nova-compute agent subscribes to it<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">* for clustered hypervisors (ironic, vCenter, etc), the topic identifies the unique resource, and any nova-compute which can manage that resource subscribes to the topic.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">This would also remove the SPoF that nova-compute currently has for any cluster-of-discrete-things it manages today (eg, baremetal).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Thoughts?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">-Devananda<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
</div>
</body>
</html>