[openstack-dev] [Neutron] Improving dhcp agent scheduling interface

Eugene Nikanorov enikanorov at mirantis.com
Wed Nov 5 11:07:52 UTC 2014


Hi folks,

I'd like to raise a discussion kept in irc and in gerrit recently:
https://review.openstack.org/#/c/131944/

The intention of the patch is to clean up particular scheduling
method/interface:
schedule_network.

Let me clarify why I think it needs to be done (beside code api consistency
reasons):
Scheduling process is ultimately just a two steps:
1) choosing appropriate agent for the network
2) adding binding between the agent and the network
To perform those two steps one doesn't need network object, network_id is
satisfactory for this need.

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.

See the TODO for the reference:
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.
Currently scheduler is only interested in ID, if there is another
scheduling driver,
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.
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
needs using the id. For existing scheduling drivers it's a no-op.

I think l3 scheduling is an example of interface done in the more right
way; to me it looks clearer and more consistent.

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


More information about the OpenStack-dev mailing list