<font size=2 face="sans-serif">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>
<br>
<br><font size=2 face="sans-serif">That draft says the VMs are created
before the group.  Is there a way today to create a VM without scheduling
it?</font>
<br>
<br><font size=2 face="sans-serif">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 arrange them into groups, then schedule
& activate them.  By "activate" I mean, for a VM instance,
to start running it.  That ordering must hold independently for each
resource.  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>
<br>
<br><font size=2 face="sans-serif">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>
<br>
<br><font size=2 face="sans-serif">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 activations
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>
<br>
<br><font size=2 face="sans-serif">Thanks,</font>
<br><font size=2 face="sans-serif">Mike</font>
<br>
<br><tt><font size=2>"Yathiraj Udupi (yudupi)" <yudupi@cisco.com>
wrote on 10/07/2013 11:10:20 PM:</font></tt>
<br><tt><font size=2>> <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 href=https://docs.google.com/document/d/><tt><font size=2>https://docs.google.com/document/d/</font></tt></a><tt><font size=2><br>
> 17OIiBoIavih-1y4zzK0oXyI66529f-7JTCVj-BcXURA/edit?usp=sharing </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:  https://<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>