<div dir="ltr">I'm leaning towards option A because it keeps things cleanly separated. Also, if a cloud is using a plugin that supports segments, an operator could use the new API for everything (including single segment networks) so it shouldn't be that unfriendly. <div><br></div><div>However...<div><br></div><div>><span style="font-size:12.8px">If there's </span><span style="font-size:12.8px">some other option that I somehow missed please suggest it.</span></div><div><br></div><div>The other option is to not make an API for this at all. In a multi-segment use-case, a DHCP agent will normally have access to only one segment of a network. By using the current API we can still assign/un-assign an agent from a network and leave the segment selection details to the scheduler. What is the use case for exposing this all of the way up to the operator?</div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 17, 2016 at 1:07 PM, Brandon Logan <span dir="ltr"><<a href="mailto:brandon.logan@rackspace.com" target="_blank">brandon.logan@rackspace.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">As part of the routed networks work [1], the DHCP agent and scheduling<br>
needs to be segment aware. Right now, the dhcpagentscheduler extension<br>
exposes API resources to manage networks:<br>
<br>
- List networks hosted by an agent<br>
- GET /agents/{agent_id}/dhcp-networks<br>
- Response Body: {"networks": [{...}]}<br>
<br>
- List agents hosting a network - GET /network<br>
- GET /networks/{network_id}/dhcp-agents<br>
- Response Body: {"agents": [{...}]}<br>
<br>
- Add a network to an agent<br>
- POST /agents/{agent_id}/dhcp-networks<br>
- Request Body: {"network_id": "NETWORK_UUID"}<br>
<br>
- Remove a network from an agent<br>
- DELETE /agents/{agent_id}/dhcp-networks/{network_id}<br>
<br>
This same functionality needs to also be exposed for working with<br>
segments. We need some opinions on the best way to do this. The<br>
options are:<br>
<br>
A) Expose new resources for segment dhcp agent manipulation<br>
- GET /agents/{agent_id}/dhcp-segments<br>
- GET /segments/{segment_id}/dhcp-agents<br>
- POST /agents/{agent_id}/dhcp-segments<br>
- DELETE /agents/{agent_id}/dhcp-segments/{segment_id}<br>
<br>
B) Allow segment info gathering and manipulation via the current network<br>
dhcp agent API resources. No new API resources.<br>
<br>
C) Some combination of A and B.<br>
<br>
My current opinion is that option C shouldn't even be an option but I<br>
just put it on here just in case someone has a strong argument. If<br>
we're going to add new resources, we may as well do it all the way,<br>
which is what C implies would happen.<br>
<br>
Option B would be great to use if segment support could easily be added<br>
in while maintaining backwards compatibility. I'm not sure if that is<br>
going to be possible in a clean way. Regardless, an extension will have<br>
to be created for this.<br>
<br>
Option A is the cleanest strategy IMHO. It may not be the most user<br>
friendly though because some networks may have multiple segments while<br>
others may not. If a network is made up of just a single segment then<br>
the current network dhcp agent calls will be fine. However, once a<br>
network is made up of multiple segments, it wouldn't make sense for the<br>
current network dhcp agent calls to be valid, they'd need to be made to<br>
the new segment resources. This same line of thinking would probably<br>
have to be considered with Option B as well, so it may be a problem for<br>
both.<br>
<br>
Anyway, I'd like to gather suggestions and opinions on this. If there's<br>
some other option that I somehow missed please suggest it.<br>
<br>
Thanks,<br>
Brandon<br>
<br>
[1]<br>
<a href="https://specs.openstack.org/openstack/neutron-specs/specs/newton/routed-networks.html#dhcp-scheduling" rel="noreferrer" target="_blank">https://specs.openstack.org/openstack/neutron-specs/specs/newton/routed-networks.html#dhcp-scheduling</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div>