Open Stack

My comments inline:

I would argue that it isn't, actually.
>
> You may need to know the state of the network to make that placement
> decision.
>
Yes, I could agree with that - and that's just a particular scheduling
implementation, not a requirement for the interface.


> Just passing the id may cause the scheduling logic to issue an extra DB
> query that can be easily avoided if the right interface between the caller
> of a scheduler and the scheduler itself was in place.
>
Yes, i may cause scheduling logic to issue a query, *iff* it needs it.

For instance we cannot fix [1] (as you pointed out) today because the
> method only accepts a dict that holds just a partial representation of the
> network. If we had the entire DB object we would avoid that and just
> passing the id is going in the opposite direction IMO
>
And here is another issue, I think. Requiring an object is something not
quite clear at this point: if scheduling needs to be aware of subnets -
network object is not enough then, and that's why I think we only need to
provide ids that allow scheduling logic to act on it's own.


>
>> However, there is a concern, that having full dict (or full network
>> object) could allow us to do more flexible things in step 1 like deciding,
>> whether network should be scheduled at all.
>>
>
> That's the whole point of scheduling, is it not?
>
Right, and we are just arguing, who should prepare the data needed to make
the scheduling decision.
I just think that scheduling logic may potentially require more than just
network object.

In my concrete example, i want to schedule a network which my code moves
from a dead agent to some alive agent.
I only have a network id during that operation. I'd like to avoid issuing
DB query as well - just as you.
My first thought was something like:
    self.schedule_network(context, {'id': network_id}) - which is clearly a
dirty hack!
But that's what the interface is forcing me to do. Or, it forces me to
fetch the network which I'd like to avoid as well.
That's why I want scheduling decide, whether it needs additional data or
not.


>
>>
>> https://github.com/openstack/neutron/blob/master/neutron/scheduler/dhcp_agent_scheduler.py#L64
>>
>> However, this just puts an unnecessary (and actually, incorrect)
>> requirement on the caller, to provide the network dict, mainly because
>> caller doesn't know what content of the dict the callee (scheduler driver)
>> expects.
>>
>
> Why is it incorrect? We should move away from dictionaries and passing
> objects
>
Passing objects is for sure much stronger api contract, however I think it
leads to the same level of overhead, if not worse!
For instance, will network object include the collection of its subnet
objects? Will they, in turn, include ipallocations and such?
If the answer is No (and my opinion that it *must* be No), then we don't
win much with object approach.
If the answer is yes - we're fetching way too much from the DB to create
network object; it's much bigger overhead then additional db query in a
scheduling driver.

No, the scheduler needs to know about the state of the network to do proper
> placement. It's a side-effect of the default scheduling (i.e. random). If
> we want to do more intelligent placement we need the state of the network.
>
That's for sure, the question is only about who prepares the data: caller
or the scheduler.

Thanks,
Eugene.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141105/3ef3126a/attachment.html>