<tt><font size=2>John Garbutt <john@johngarbutt.com> wrote on 10/29/2013
07:29:19 AM:<br>
> ...<br>
> Its looking good, but I was thinking about a slightly different approach:<br>
> <br>
> * I would like to see instance groups be used to describe all<br>
> scheduler hints (including, please run on cell X, or please run on<br>
> hypervisor Y)</font></tt>
<br>
<br><tt><font size=2>I think Yathi's proposal is open in the sense that
any type of policy can appear (we only have to define the policy types
:-).  Removing old features from the existing API is something that
would have to be done over time, if at all.</font></tt>
<br><tt><font size=2><br>
> * passing old scheduler hints to the API will just create a new<br>
> instance group to persist the request</font></tt>
<br>
<br><tt><font size=2>Yes, implementation re-org is easier that retiring
old API.</font></tt>
<br><tt><font size=2><br>
> * ensure live-migrate/migrate never lets you violate the rules in
the<br>
> user hints, at least don't allow it to happen by accident</font></tt>
<br>
<br><tt><font size=2>Right, that's why we are persisting the policy information.</font></tt>
<br><tt><font size=2><br>
> * I was expecting to see hard and soft constraints/hints, like: try<br>
> keep in same switch, but make sure on separate servers</font></tt>
<br>
<br><tt><font size=2>Good point, I forgot to mention that in my earlier
reviews of the model!<br>
<br>
> * Would be nice to have admin defined global options, like: "ensure<br>
> tenant does note have two servers on the same hypervisor" or
soft</font></tt>
<br>
<br><tt><font size=2>That's the second time I have seen that idea in a
week, there might be something to it.<br>
<br>
> * I expected to see the existing boot server command simply have the<br>
> addition of a reference to a group, keeping the existing methods of<br>
> specifying multiple instances</font></tt>
<br>
<br><tt><font size=2>That was my expectation too, for how a 2-stage API
would work.  (A 1-stage API would not have the client making distinct
calls to create the instances.)<br>
<br>
> * I aggree you can't change a group's spec once you have started some<br>
> VMs in that group, but you could then simply launch more VMs keeping<br>
> to the same policy</font></tt>
<br>
<br><tt><font size=2>Not if a joint decision was already made based on
the totality of the group.<br>
<br>
> ...<br>
> <br>
> * augment the server details (and group?) with more location<br>
> information saying where the scheduler actually put things, obfuscated<br>
> on per tenant basis. So imagine nova, cinder, neutron exposing ordered<br>
> (arbitrary tagged) location metadata like nova: (("host_id",
"foo"),<br>
> ("switch_group_id": "bar"), ("power_group":
"bas"))</font></tt>
<br>
<br><tt><font size=2>+1<br>
<br>
> * the above should help us define the "scope" of a constraint
relative<br>
> to either a nova, cinder or neutron resource.</font></tt>
<br>
<br><tt><font size=2>I am lost.  What "above", what scope
definition problem?<br>
<br>
> * Consider a constraint that includes constraints about groups, like<br>
> must be separate to group X, in the scope of the switch, or something<br>
> like that</font></tt>
<br>
<br><tt><font size=2>I think Yathi's proposal, with the policy types I
suggested, already does a lot of stuff like that.  But I do not know
what you mean by "in the scope of the switch".  I think
you mean a location constraint, but am not sure which switch you have in
mind.  I would approach this perhaps a little more abstractly, as
a collocation constraint between two resources that are known to and meaningful
to the client (yes, we are starting with Nova only in Icehouse, hope to
go holistic later).<br>
<br>
> * Need more thought on constraints between volumes, servers and<br>
> networks, I don't think edges are the right way to state that, I think<br>
> it would be better as a cross group constraint, where the scope of
the<br>
> constraint is related to neutron.</font></tt>
<br>
<br><tt><font size=2>I need more explanation or concrete examples to understand
what problem(s) you are thinking of.  We are explicitly limiting ourselves
to Nova at first, later will add in other services.<br>
</font></tt>
<br><tt><font size=2>Thanks,</font></tt>
<br><tt><font size=2>Mike</font></tt>