<div dir="ltr">Hi folks,<div><br></div><div>I'd like to raise a discussion kept in irc and in gerrit recently: <a href="https://review.openstack.org/#/c/131944/">https://review.openstack.org/#/c/131944/</a></div><div><br></div><div>The intention of the patch is to clean up particular scheduling method/interface:</div><div>schedule_network.</div><div><br></div><div>Let me clarify why I think it needs to be done (beside code api consistency reasons):</div><div>Scheduling process is ultimately just a two steps:</div><div>1) choosing appropriate agent for the network</div><div>2) adding binding between the agent and the network</div><div>To perform those two steps one doesn't need network object, network_id is satisfactory for this need.</div><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><br></div><div>See the TODO for the reference:</div><div><a href="https://github.com/openstack/neutron/blob/master/neutron/scheduler/dhcp_agent_scheduler.py#L64">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>Currently scheduler is only interested in ID, if there is another scheduling driver,</div><div>it may now require additional parameters (like list of full subnet dicts) in the dict which may or may not be provided by the calling code.</div><div>Instead of making assumptions about what is in the dict, it's better to go with simpler and clearer interface that will allow scheduling driver to do whatever makes sense to it. In other words: caller provides id, driver fetches everything it</div><div>needs using the id. For existing scheduling drivers it's a no-op.</div><div><br></div><div>I think l3 scheduling is an example of interface done in the more right way; to me it looks clearer and more consistent.</div><div><br></div><div>Thanks,</div><div>Eugene.</div><div><br></div><div><br></div><div><br></div></div>