<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body 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">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<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></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>
<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>
</body>
</html>