<font size=2 face="sans-serif">On second thought, I should revise and
extend my remarks. This message supersedes my previous two replies.</font>
<br>
<br><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><font size=3>
<br>
</font><font size=2 face="sans-serif"><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 size=2 face="sans-serif">By "activate" I mean, for
a VM instance for example, to start running it. </font><font size=3><br>
</font><font size=2 face="sans-serif"><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 size=2 face="sans-serif"><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><font size=2 face="sans-serif"><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 size=2 face="sans-serif">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 size=2 face="sans-serif">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 size=2 face="sans-serif"><br>
Thanks,</font><font size=3> </font><font size=2 face="sans-serif"><br>
Mike</font><font size=3> </font>
<br>
<br><tt><font size=2>"Yathiraj Udupi (yudupi)" <yudupi@cisco.com>
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 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: 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><tt><font size=2>> <br>
> </font></tt>