<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: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;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.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;}
--></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="MsoNormal">>Totally agreed with this. However, I'm not sure having clustered<br>
>hypervisors expose individual resources is something they want to do.<br>
>It's in conflict with what the underlying system we're talking to wants<br>
>to be in control of.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">>I disagree. I think those systems are trying to pass control up the stack to us -- to use the OpenStack API, and all the richness that adds (eg, Heat), to interact with a bunch of compute >resources. So it seems to me that exposing the
individual resources inside the clustered hypervisor is specifically important to meeting that goal. Whether those resources are _also_ managed >by something else is orthogonal to whether they are exposed as individual or aggregated resources to Nova. <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">>But as I'm not working on vSphere or Hyper-V, perhaps I should be quiet and let them answer :)<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">It’s a choice point we have whether to expose individual resources of a cluster or not. For an “admin” user it is important to expose the underlying individual
resources from a monitoring, metering and performance purpose. However from a provisioning perspective sticking to “nova-compute” perspective is good enough where it needs to provide a view of available capacity for making allocation and scheduling decisions.
When we closely look at the Clustering features provided by some of hypervisors, we see that there is no point in directing the workload to an individual hypervisor host as it is not guaranteed that the newly created instance is powered on in that host.
Due to cluster policies newly created instances may power-on in another available hypervisor host in the cluster. So it makes sense to direct the scheduling to the cluster itself and leave the cluster to manage the scheduling within the cluster. Further,
<b>Healthnmon</b> comes in handy from monitoring, metering and performance perspective with this approach wherein it provides a drilldown for a nova-compute and provides insights into associated Clusters, Hypervisor hosts and Resource pools.
<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">Thanks,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Divakar<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> Friday, May 10, 2013 12:01 AM<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 10:44 AM, Russell Bryant <<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</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 12:30 PM, Devananda van der Veen wrote:<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">><br>
> I don't feel like a new project is needed here -- the ongoing discussion<br>
> about moving scheduling/orchestration logic out of nova-compute and into<br>
> conductor-or-something-else seems to frame this discussion, too.<br>
><br>
> The biggest change to Nova that I recall around adding the Baremetal<br>
> code was the addition of the "node" aka "hypervisor_hostname" concept --<br>
> that a single nova compute host might control more than one discrete<br>
> thing, which thereby need to be identified as (host, node). That change<br>
> opened the door for other cluster drivers to fit under the virt<br>
> interface. IMBW, but I believe this is exactly what the vCenter and<br>
> Hyper-V folks are looking at. It's also my current plan for Ironic.<br>
> However, I also believe that this logic doesn't necessarily have to live<br>
> under the virt API layer; I think it's a really good fit for the<br>
> orchestration/conductor discussions....<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal">Yep, that was the change that had the most impact on the rest of Nova.<br>
I think there's a big difference between baremetal and these other<br>
drivers. In the case of baremetal, the Nova component is still in full<br>
control of all nodes. There's not another system that is also (or<br>
instead of Nova) in control of the individual nodes.<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">With Ironic, there will be another system in control of the individual hardware nodes. It'll have an API. The operator will talk to that API (eg. for enrollment, status, and management). Nova will talk to that API, and so will some other
OpenStack services. At least that's the plan ...<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <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">
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
> We were talking about this a few days ago in -nova, particularly how<br>
> moving some of the ComputeManager logic out to conductor might fit<br>
> together with simplifying the (host, node) complexities, and help make<br>
> nova-compute just a thin virt API layer. Here is a very poor summary of<br>
> what I recall...<br>
> * AMQP topic is based on "nodename", not "hostname"<br>
> * for local hypervisors (KVM, etc), the topic identifies the local host,<br>
> and the local nova-compute agent subscribes to it<br>
> * for clustered hypervisors (ironic, vCenter, etc), the topic identifies<br>
> the unique resource, and any nova-compute which can manage that resource<br>
> subscribes to the topic.<br>
><br>
> This would also remove the SPoF that nova-compute currently has for any<br>
> cluster-of-discrete-things it manages today (eg, baremetal).<o:p></o:p></p>
</div>
<p class="MsoNormal">Totally agreed with this. However, I'm not sure having clustered<br>
hypervisors expose individual resources is something they want to do.<br>
It's in conflict with what the underlying system we're talking to wants<br>
to be in control of.<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I disagree. I think those systems are trying to pass control up the stack to us -- to use the OpenStack API, and all the richness that adds (eg, Heat), to interact with a bunch of compute resources. So it seems to me that exposing the individual
resources inside the clustered hypervisor is specifically important to meeting that goal. Whether those resources are _also_ managed by something else is orthogonal to whether they are exposed as individual or aggregated resources to Nova. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">But as I'm not working on vSphere or Hyper-V, perhaps I should be quiet and let them answer :)<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>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">-Deva<o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</body>
</html>