<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; ">
<div>Mike, Sylvain, </div>
<div><br>
</div>
<div>I think some of Mike's questions were answered during today's scheduler team meeting. </div>
<div><br>
</div>
<div><i>Mike: </i></div>
<div><i>>> <span style="font-family: sans-serif; font-size: small; ">Thanks. I have a few questions. First, I am a bit stymied by the style of API documentation used in that document and many others: it shows the first line of an HTTP request but says nothing
about all the other details. I am sure some of those requests must have interesting bodies, but I am >> not always sure which ones have a body at all, let alone what goes in it. I suspect there may be some headers that are important too. Am I missing something?</span></i></div>
<div>Yathi: Do see some of the existing code written up for instance group here in this review, there are a few request/response examples of the older model - <a href="https://review.openstack.org/#/c/30028">https://review.openstack.org/#/c/30028</a>/ This
code will be revived and the effort will be similar incorporating the newer model. </div>
<div><br>
</div>
<div><i>Mike: </i></div>
<div><i>>><font face="sans-serif" size="2">That draft says the VMs are created before the group. Is there a way today to create a VM without scheduling it? Is there a way to activate a resource that has already been scheduled but not activated?</font><font size="3"></font><font face="sans-serif" size="2">By
"activate" I mean, for a VM instance for example, to start running it. </font></i></div>
<div><font face="sans-serif" size="2"><i>Sylvain:</i></font></div>
<div><i><font face="sans-serif" size="2">>> </font><span style="font-size: medium; ">I c</span><font size="3" style="font-size: medium; ">an't answ<font size="3">er for <font size="3">it, but as<font size="3"> far as I can understand the dra<font size="3">ft,
there is no clear understand<font size="3">ing that we <font size="3">have to<font size="3"> po<font size="3">stpone the VM boot *after* creating the <font size="3">Groups.</font></font></font></font></font></font></font></font></font></font></i></div>
<font size="3" style="font-size: medium; "><font size="3"><font size="3"><font size="3"><font size="3"><font size="3"><font size="3"><font size="3"><font size="3"><font size="3"><font size="3"><i>>>As s<font size="3">ta<font size="3">ted in the document, <font size="3">there
is a strong prere<font size="3">q<font size="3"> which is that all the resources mapped <font size="3">to the Group m<font size="3">ust <font size="3">have their o<font size="3">wn uuids<font size="3">, <font size="3">but t<font size="3">he<font size="3">re
is no clear outs<font size="3">tanding tha<font size="3">t it should prevent the VMs to actual<font size="3">ly boot.<br>
<font size="3">>>At the moment, <font size="3">deferring <font size="3">a boot<font size="3">able state in Nova is not <font size="3">yet impleme<font size="3">nted and that's part of Climate folks to i<font size="3">mplement it<font size="3">, <font size="3">s<font size="3">o
I can<font size="3">'t get your point.<br>
</font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></i></font></font></font></font></font></font></font></font></font></font></font>
<div>Yathi: I guess Gary Kotton can comment more here, but this is probably implementation detail. As long as the group is defined and registered, the actual activation can take care of assigning the created UUIDs for the instances.. But I do see there are
internal DB APIs to save the instances and thereby creating uuids, but not actually activating them. my documentation assumes, that the instances need to be registered. The reason why we want to defer the instance boot, is because we want to get the complete
big picture and do a unified scheduling taking all the parameters into consideration (read this as smart resource placement). </div>
<div><br>
</div>
<div>This document does not yet mention anything about the actual process involved in the activation of the group. That will involve whole lot of work in terms of reservation, ordering of creation, etc, and it is here where we need to have clean interfaces
to plug in external support to accomplish this. </div>
<div><br>
</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Yathi. </div>
<div><br>
</div>
<div><br>
</div>
<div><font face="sans-serif" size="2"><br>
</font></div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><font size="3"><br>
</font></div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Sylvain Bauza <<a href="mailto:sylvain.bauza@bull.net">sylvain.bauza@bull.net</a>><br>
<span style="font-weight:bold">Date: </span>Tuesday, October 8, 2013 12:08 AM<br>
<span style="font-weight:bold">To: </span>OpenStack Development Mailing List <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Cc: </span>Mike Spreitzer <<a href="mailto:mspreitz@us.ibm.com">mspreitz@us.ibm.com</a>>, Yathiraj Udupi <<a href="mailto:yudupi@cisco.com">yudupi@cisco.com</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [openstack-dev] [scheduler] APIs for Smart Resource Placement - Updated Instance Group Model and API extension model - WIP Draft<br>
</div>
<div><br>
</div>
<div>
<div text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi Mike,<br>
<br>
Le 08/10/2013 08:51, Mike Spreitzer a écrit :<br>
</div>
<blockquote cite="mid:OF3EF1E2D0.9D3F9F95-ON85257BFE.0024C2D5-85257BFE.0025B310@us.ibm.com" type="cite">
<font face="sans-serif" size="2">On second thought, I should revise and extend my remarks. This message supersedes my previous two replies.</font><br>
<br>
<font face="sans-serif" size="2">Thanks. I have a few questions. First, I am a bit stymied by the style of API documentation used in that document and many others: it shows the first line of an HTTP request but says nothing about all the other details. I
am sure some of those requests must have interesting bodies, but I am not always sure which ones have a body at all, let alone what goes in it. I suspect there may be some headers that are important too. Am I missing something?</font><font size="3"><br>
</font><font face="sans-serif" size="2"><br>
That draft says the VMs are created before the group. Is there a way today to create a VM without scheduling it? Is there a way to activate a resource that has already been scheduled but not activated?</font><font size="3"></font><font face="sans-serif" size="2">By
"activate" I mean, for a VM instance for example, to start running it. </font><font size="3"><br>
</font><font face="sans-serif" size="2"><br>
As I understand your draft, it lays out a three phase process for a client to follow: create resources without scheduling or activating them, then present the groups and policies to the service for joint scheduling, then activate the resources. With regard
to a given resource, things must happen in that order; between resources there is a little more flexibility. Activations are invoked by the client in an order that is consistent with (a) runtime dependencies that are mediated directly by the client (e.g.,
string slinging in the heat engine) and (b) the nature of the resources (for example, you can not attach a volume to a VM instance until after both have been created). Other than those considerations, the ordering and/or parallelism is a degree of freedom
available to the client. Have I got this right?</font><font size="3"> <br>
</font><font face="sans-serif" size="2"><br>
Couldn't we simplify this into a two phase process: create groups and resources with scheduling, then activate the resources in an acceptable order?</font><font size="3"><br>
</font></blockquote>
<br>
<font size="3"><font size="3"><font size="3">I c<font size="3">an't answ<font size="3">er for
<font size="3">it, but as<font size="3"> far as I can understand the dra<font size="3">ft, there is no clear understand<font size="3">ing that we
<font size="3">have to<font size="3"> po<font size="3">stpone the VM boot *after* creating the
<font size="3">Groups.<br>
<font size="3">As s<font size="3">ta<font size="3">ted in the document, <font size="3">
there is a strong prere<font size="3">q<font size="3"> which is that all the resources mapped
<font size="3">to the Group m<font size="3">ust <font size="3">have their o<font size="3">wn uuids<font size="3">,
<font size="3">but t<font size="3">he<font size="3">re is no clear outs<font size="3">tanding tha<font size="3">t it should prevent the VMs to actual<font size="3">ly boot.<br>
<br>
<font size="3">At the moment, <font size="3">deferring <font size="3">a boot<font size="3">able state in Nova is not
<font size="3">yet impleme<font size="3">nted and that's part of Climate folks to i<font size="3">mplement it<font size="3">,
<font size="3">s<font size="3">o I can<font size="3">'t get your point.<br>
<br>
<font size="3">-Sylvain<br>
<br>
</font></font></font>
<blockquote cite="mid:OF3EF1E2D0.9D3F9F95-ON85257BFE.0024C2D5-85257BFE.0025B310@us.ibm.com" type="cite">
<font size="3"></font><font face="sans-serif" size="2"><br>
FYI: my group is using Weaver as the software orchestration technique, so there are no runtime dependencies that are mediated directly by the client. The client sees a very simple API: the client presents a definition of all the groups and resources, and the
service first schedules it all then activates in an acceptable order. (We already have something in OpenStack that can do resource invocations in an acceptable order, right?) Weaver is not the only software orchestration technique with this property. The
simplicity of this API is one reason I recommend software orchestration techniques that take dependency mediation out of the client's hands. I hope that with coming work on HOT we can get OpenStack to this level of API simplicity. But that struggle lies
farther down the roadmap...</font><font size="3"> <br>
</font><br>
<font face="sans-serif" size="2">I was wondering if you could explain why you included all those integer IDs; aren't the UUIDs sufficient? Do you intend that clients will see/manipulate the integer IDs?</font><br>
<br>
<font face="sans-serif" size="2">If I understand your UML correctly, an InstanceGroup owns its metadata but none of the other subsidiary objects introduced. Why not? If an InstanceGroup is deleted, shouldn't all those other subsidiary objects be deleted too?</font><br>
<font face="sans-serif" size="2"><br>
Thanks,</font><font size="3"> </font><font face="sans-serif" size="2"><br>
Mike</font><font size="3"> </font><br>
<br>
<tt><font size="2">"Yathiraj Udupi (yudupi)" <a class="moz-txt-link-rfc2396E" href="mailto:yudupi@cisco.com">
<yudupi@cisco.com></a> wrote on 10/07/2013 11:10:20 PM:<br>
> Hi, </font></tt><br>
<tt><font size="2">> <br>
> Based on the discussions we have had in the past few scheduler sub-<br>
> team meetings, I am sharing a document that proposes an updated <br>
> Instance Group Model and API extension model. </font></tt><br>
<tt><font size="2">> This is a work-in-progress draft version, but sharing it for early feedback.
</font></tt><br>
<tt><font size="2">> </font></tt><a moz-do-not-send="true" href="https://docs.google.com/document/d/17OIiBoIavih-1y4zzK0oXyI66529f-7JTCVj-BcXURA/edit?usp=sharing"><tt><font size="2">https://docs.google.com/document/d/17OIiBoIavih-1y4zzK0oXyI66529f-7JTCVj-BcXURA/edit?usp=sharing</font></tt></a><tt><font size="2"></font></tt><br>
<tt><font size="2">> <br>
> This model support generic instance types, where an instance can <br>
> represent a virtual node of any resource type. But in the context <br>
> of Nova, an instance refers to the VM instance. </font></tt><br>
<tt><font size="2">> <br>
> This builds on the existing proposal for Instance Group Extension as<br>
> documented here in this blueprint: <a class="moz-txt-link-freetext" href="https://">https://</a><br>
> blueprints.launchpad.net/nova/+spec/instance-group-api-extension </font></tt><br>
<tt><font size="2">> <br>
> Thanks,</font></tt> <br>
<tt><font size="2">> Yathi. </font></tt><br>
<tt><font size="2">> <br>
> </font></tt><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>
</font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></div>
</div>
</span>
</body>
</html>