Hi Mike,
Le 08/10/2013 08:51, Mike Spreitzer a écrit :
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?
I can't answer for it, but asfar as I can understand the draft, there is
no clear understanding that we have topostpone the VM boot *after*
creating the Groups.
As stated in the document, there is a strong prereqwhich is that all the
resources mapped to the Group must have their own uuids, but there is no
clear outstanding that it should prevent the VMs to actually boot.
At the moment, deferring a bootable state in Nova is not yet implemented
and that's part of Climate folks to implement it, so I can't get your point.
-Sylvain
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)" <yud...@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.
>
>
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
