<div dir="ltr">My comments inline:<div><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote"><div>I would argue that it isn't, actually. </div><div><br></div><div>You may need to know the state of the network to make that placement decision. </div></div></div></div></div></blockquote><div>Yes, I could agree with that - and that's just a particular scheduling implementation, not a requirement for the interface.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote"><div>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.</div></div></div></div></div></blockquote><div>Yes, i may cause scheduling logic to issue a query, *iff* it needs it.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote"><div>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</div></div></div></div></div></blockquote><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote"><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>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. </div></div></blockquote><div><br></div></span><div>That's the whole point of scheduling, is it not?</div></div></div></div></div></blockquote><div>Right, and we are just arguing, who should prepare the data needed to make the scheduling decision.</div><div>I just think that scheduling logic may potentially require more than just network object.</div><div><br></div><div>In my concrete example, i want to schedule a network which my code moves from a dead agent to some alive agent.</div><div>I only have a network id during that operation. I'd like to avoid issuing DB query as well - just as you.</div><div>My first thought was something like:</div><div>    self.schedule_network(context, {'id': network_id}) - which is clearly a dirty hack!</div><div>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.</div><div>That's why I want scheduling decide, whether it needs additional data or not.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote"><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><a href="https://github.com/openstack/neutron/blob/master/neutron/scheduler/dhcp_agent_scheduler.py#L64" target="_blank">https://github.com/openstack/neutron/blob/master/neutron/scheduler/dhcp_agent_scheduler.py#L64</a><br></div><div><br></div><div>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.</div></div></blockquote><div><br></div></span><div>Why is it incorrect? We should move away from dictionaries and passing objects </div></div></div></div></div></blockquote><div>Passing objects is for sure much stronger api contract, however I think it leads to the same level of overhead, if not worse!</div><div>For instance, will network object include the collection of its subnet objects? Will they, in turn, include ipallocations and such?</div><div>If the answer is No (and my opinion that it *must* be No), then we don't win much with object approach.</div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote"><div>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. </div></div></div></div></div></blockquote><div>That's for sure, the question is only about who prepares the data: caller or the scheduler.</div><div><br></div><div>Thanks,</div><div>Eugene.</div><div><br></div></div></div></div></div>