Open Stack

On Tue, 2016-05-17 at 13:29 -0700, Kevin Benton wrote:
> 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?

I may have wrongly assumed that segments MAY have the possibility of
being l2 adjacent, even if the entire network they are in is not, which
would mean that viewing and scheduling these in the context of a segment
could be useful.  However, if that is not the case I fully agree that
those calls are not needed and it can just be left up to the scheduler
to do that.  Do you feel like it'd be beneficial to show what segment a
dhcp agent is bound to in the API?  I have no use case, but I wonder if
operators may want that knowledge since they will be able to list
segments.

> 
> 
> 
> 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
> 
> 
> __________________________________________________________________________
> 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