Open Stack

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