Open Stack

Hi Yathi,

Thank you for yor example. I have some remarks concerning the JSON format:

1) Member of a group is recursive. A member can be group or an instance. In this case there are two different declaration formats for members, as with http-server-group-1 ("name, "policy", "edge") and Http-Server-1 ("name", "request_spec", "type"). Would it be better if group-typed member also have "type" field to better interpret the member? Like policy which has "type" field to declare that's a egde-typed policy or group-typed policy.

2) The "edge" is not clear to me. It seems to me that "edge" is just a place holder for the edge policy. Does it have some particular configuration like group members (e.g. group-typed member is described by its "member","edge" and "policy", while instance-typed member is described by its "request_spec") ?

3) Members & groups have policy declaration nested in them. Why is edge-policy is declared outside of edge's declaration?

Anyway, good work.

Toan

----- Original Message -----
From: "John Garbutt" <john at johngarbutt.com>
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
Sent: Tuesday, October 29, 2013 12:29:19 PM
Subject: Re: [openstack-dev] [nova][scheduler] Instance Group Model and APIs - Updated document with an example request payload

On 29 October 2013 06:46, Yathiraj Udupi (yudupi) <yudupi at cisco.com> wrote:
> The Instance Group API document is now updated with a simple example request
> payload of a nested group, and some description of how the API
> implementation should handle the registration of the components of a nested
> instance group.
> https://docs.google.com/document/d/17OIiBoIavih-1y4zzK0oXyI66529f-7JTCVj-BcXURA/edit
>
> Hope we will have a good API design session at the summit, and also continue
> the discussion face-to-face over there.

Its looking good, but I was thinking about a slightly different approach:

* I would like to see instance groups be used to describe all
scheduler hints (including, please run on cell X, or please run on
hypervisor Y)

* passing old scheduler hints to the API will just create a new
instance group to persist the request

* ensure live-migrate/migrate never lets you violate the rules in the
user hints, at least don't allow it to happen by accident

* I was expecting to see hard and soft constraints/hints, like: try
keep in same switch, but make sure on separate servers

* Would be nice to have admin defined global options, like: "ensure
tenant does note have two servers on the same hypervisor" or soft

* I expected to see the existing boot server command simply have the
addition of a reference to a group, keeping the existing methods of
specifying multiple instances

* I aggree you can't change a group's spec once you have started some
VMs in that group, but you could then simply launch more VMs keeping
to the same policy

* New task API (see summit session) should help with the reporting if
the VM actually could be started or not, and the reason why it was not
possible

* augment the server details (and group?) with more location
information saying where the scheduler actually put things, obfuscated
on per tenant basis. So imagine nova, cinder, neutron exposing ordered
(arbitrary tagged) location metadata like nova: (("host_id", "foo"),
("switch_group_id": "bar"), ("power_group": "bas"))

* the above should help us define the "scope" of a constraint relative
to either a nova, cinder or neutron resource.

* Consider a constraint that includes constraints about groups, like
must be separate to group X, in the scope of the switch, or something
like that

* Need more thought on constraints between volumes, servers and
networks, I don't think edges are the right way to state that, I think
it would be better as a cross group constraint, where the scope of the
constraint is related to neutron.


Anyways, just a few thoughts I was having. Does that fit in with what
you were thinking?

John

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev