Open Stack

On second thought, I should revise and extend my remarks.  This message 
supersedes my previous two replies.

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?  Is there a way to activate a 
resource that has already been scheduled but not activated? By "activate" 
I mean, for a VM instance for example, to start running 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 
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? 

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

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?

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?

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/0060ae42/attachment.html>