Open Stack

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.

However...

>If there's some other option that I somehow missed please suggest it.

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?


On Tue, May 17, 2016 at 1:07 PM, Brandon Logan <brandon.logan at rackspace.com>
wrote:

> As part of the routed networks work [1], the DHCP agent and scheduling
> needs to be segment aware.  Right now, the dhcpagentscheduler extension
> exposes API resources to manage networks:
>
> - List networks hosted by an agent
>         - GET /agents/{agent_id}/dhcp-networks
>         - Response Body: {"networks": [{...}]}
>
> - List agents hosting a network - GET /network
>         - GET /networks/{network_id}/dhcp-agents
>         - Response Body: {"agents": [{...}]}
>
> - Add a network to an agent
>         - POST /agents/{agent_id}/dhcp-networks
>         - Request Body: {"network_id": "NETWORK_UUID"}
>
> - Remove a network from an agent
>         - DELETE /agents/{agent_id}/dhcp-networks/{network_id}
>
> This same functionality needs to also be exposed for working with
> segments.  We need some opinions on the best way to do this.  The
> options are:
>
> A) Expose new resources for segment dhcp agent manipulation
>         - GET /agents/{agent_id}/dhcp-segments
>         - GET /segments/{segment_id}/dhcp-agents
>         - POST /agents/{agent_id}/dhcp-segments
>         - DELETE /agents/{agent_id}/dhcp-segments/{segment_id}
>
> B) Allow segment info gathering and manipulation via the current network
> dhcp agent API resources. No new API resources.
>
> C) Some combination of A and B.
>
> My current opinion is that option C shouldn't even be an option but I
> just put it on here just in case someone has a strong argument.  If
> we're going to add new resources, we may as well do it all the way,
> which is what C implies would happen.
>
> Option B would be great to use if segment support could easily be added
> in while maintaining backwards compatibility.  I'm not sure if that is
> going to be possible in a clean way.  Regardless, an extension will have
> to be created for this.
>
> Option A is the cleanest strategy IMHO.  It may not be the most user
> friendly though because some networks may have multiple segments while
> others may not.  If a network is made up of just a single segment then
> the current network dhcp agent calls will be fine.  However, once a
> network is made up of multiple segments, it wouldn't make sense for the
> current network dhcp agent calls to be valid, they'd need to be made to
> the new segment resources.  This same line of thinking would probably
> have to be considered with Option B as well, so it may be a problem for
> both.
>
> Anyway, I'd like to gather suggestions and opinions on this.  If there's
> some other option that I somehow missed please suggest it.
>
> Thanks,
> Brandon
>
> [1]
>
> https://specs.openstack.org/openstack/neutron-specs/specs/newton/routed-networks.html#dhcp-scheduling
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160517/bd109e16/attachment.html>