Open Stack

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?

That draft says the VMs are created before the group.  Is there a way 
today to create a VM without scheduling it?

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?

Couldn't we simplify this into a two phase process: create groups and 
resources with scheduling, then activate the resources in an acceptable 
order?

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...

Thanks,
Mike

"Yathiraj Udupi (yudupi)" <yudupi at cisco.com> wrote on 10/07/2013 11:10:20 
PM:
> 
> Hi, 
> 
> Based on the discussions we have had in the past few scheduler sub-
> team meetings,  I am sharing a document that proposes an updated 
> Instance Group Model and API extension model. 
> This is a work-in-progress draft version, but sharing it for early 
feedback. 
> https://docs.google.com/document/d/
> 17OIiBoIavih-1y4zzK0oXyI66529f-7JTCVj-BcXURA/edit?usp=sharing 
> 
> This model support generic instance types, where an instance can 
> represent a virtual node of any resource type.  But in the context 
> of Nova, an instance refers to the VM instance. 
> 
> This builds on the existing proposal for Instance Group Extension as
> documented here in this blueprint:  https://
> blueprints.launchpad.net/nova/+spec/instance-group-api-extension 
> 
> Thanks,
> Yathi. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131008/71c6a632/attachment.html>