Open Stack

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

Segments could be L2 adjacent, but I think it would be pretty uncommon for
a DHCP agent to have access to multiple L2 adjacent segments for the same
network. But even if that happens, the main use case I see for the
scheduler API is taking networks off of dead agents, agents going under
maintenance, or agents under heavy load. With the introduction of segments,
all of those are still possible via the network-based API.

>Do you feel like it'd be beneficial to show what segment a dhcp agent is
bound to in the API?

Probably useful in some cases. This will already be possible by showing the
port details for the DHCP agent's port, but it might be worth adding in
just to eliminate the extra steps.

On Wed, May 18, 2016 at 12:11 PM, Brandon Logan <brandon.logan at rackspace.com
> wrote:

> 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
>
> __________________________________________________________________________
> 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/20160518/a5a51f76/attachment.html>