Open Stack

On 29 October 2013 20:18, Mike Spreitzer <mspreitz at us.ibm.com> wrote:
> John Garbutt <john at johngarbutt.com> wrote on 10/29/2013 07:29:19 AM:
>> ...
>
>> 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)
>
> 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.

I think its important we unite the old and new world behind a single
backend implementation, in this case.

>> * passing old scheduler hints to the API will just create a new
>> instance group to persist the request
> Yes, implementation re-org is easier that retiring old API.

I would save remove the hints in v3, but I like them too much. They
are a nice shorthand.

>> * ensure live-migrate/migrate never lets you violate the rules in the
>> user hints, at least don't allow it to happen by accident
>
> Right, that's why we are persisting the policy information.

Sure, I just wanted to raise that. Its why I would like to see the
exisiting hints migrated to the new "persisted policy" world.

>> * I was expecting to see hard and soft constraints/hints, like: try
>> keep in same switch, but make sure on separate servers
>
> Good point, I forgot to mention that in my earlier reviews of the model!

No worries.

>> * Would be nice to have admin defined global options, like: "ensure
>> tenant does note have two servers on the same hypervisor" or soft
>
> That's the second time I have seen that idea in a week, there might be
> something to it.

I think it could replace some of the existing filters, in a nice
descriptive way, that could open up the ability of users to override
such a decision, in a controlled way.

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

Yes, the 1-stage would amount to scheduler hints today, that then
auto-create the instance groups.

>> * 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
>
> Not if a joint decision was already made based on the totality of the group.

So in some cases you would have to reject the request, but in some
cases you might be able to spread out a few extra VMs, without moving
the old ones. I am thinking about people setting up their hadoop
system, then looking to quickly add capacity into particular existing
clusters.

>> * 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"))
>
> +1

So see these all being used to "scope" a constraint, like:
* all on the same switch (in the nova sense)
* but also on different hypervisors (in the nova sense)

You could then widen the scope bringing in Cinder and Neutron
"location" information.
* all on different hypervisors
* close to volume X and volume Y
* able to connect to private network Z

>> * the above should help us define the "scope" of a constraint relative
>> to either a nova, cinder or neutron resource.
>
> I am lost.  What "above", what scope definition problem?

Sorry, bad description, hopefully I described the scope better in the
description above?

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

I agree we are targeting Nova first, but I would hate to change the
API again, if we don't have to.

My main objection is the concept of the "edge". If we can have a
constraint that references other groups, then I don't see why we need
the special case of the "edge". For example:

Group A (DB)
* all on same switch
* not on same hypervisor

Group B (Web)
* all on same switch
* not on same hypervisor

Group C (network interconnect)
* private network Z is available on both group A and group B nodes

OK, so if an "edge" is a constraint, in a group that involves two
scopes, that seems reasonable.

John