Re: [openstack-dev] [neutron] DHCP Agent Scheduling for Segments

[Carl Baldwin]

It would be worth looking at the code that adds AZ awareness to DHCP
scheduling.  There might be something to learn.

However, by design, segments and AZs are orthogonal concepts that don't
force any kind of correlation.  There are segments that span AZs and AZs
that span segments.  I really want to be careful not to make assumptions.

Another very important distinction is that with multiple AZs today, each
DHCP server is generally available to other AZs.  We just wanted a way to
have multiple servers in different failure domains.  With routed segments,
it is different, we need to be sure there is a DHCP server in each segment
with a DHCP enabled subnet.  Otherwise, DHCP will be unreachable from it.

Carl
On May 22, 2016 7:32 AM, "Gary Kotton"  wrote:

> Today the DHCP schedulers have support for ‘AZ hints’. My understanding is
> that a segment is a subset of an AZ. So why are we not able to leverage
> that logic or make it more generic?
> Thanks
> Gary
>
> On 5/22/16, 4:02 AM, "Carl Baldwin"  wrote:
>
> >On Fri, May 20, 2016 at 1:44 PM, Brandon Logan
> > wrote:
> >> On Thu, 2016-05-19 at 14:16 -0600, Carl Baldwin wrote:
> >>> On Wed, May 18, 2016 at 1:36 PM, Kevin Benton 
> wrote:
> >>> >>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.
> >>>
> >>> I think I agree with this.  Let's not change the API at all to begin
> >>> with.  I do think this means that the current API should work with or
> >>> without segments.  I'm not sure that the current approach of doing
> >>> scheduling for segments completely independently of scheduling for
> >>> networks works for this.  Does it?
> >>>
> >>
> >> I still think it does, but we can make it work without making them
> >> separate.  My original plan was to keep them together, but that ended up
> >> causing some unclean code and also the possibility of requiring an
> >> interface change, which would break out-of-tree schedulers like bgp,
> >> that just got moved out of tree.  If I can devise an alternative to
> >> breaking that interface, then I'll go forward without separate
> >> schedulers.
> >
> >I think we've got a general idea of how it should behave.  Let's see
> >what you come up with.
> >
> >Carl
> >
> >__
> >OpenStack Development Mailing List (not for usage questions)
> >Unsubscribe:
> openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] DHCP Agent Scheduling for Segments

[Kevin Benton]

This is a little different because it also requires scheduling to multiple
segments (i.e. one network will have DHCP instances on every segment).
There may be some overlap in filtering candidate agents based on their
connectivity properties, but a lot of it will be orthogonal.

On Sun, May 22, 2016 at 6:31 AM, Gary Kotton  wrote:

> Today the DHCP schedulers have support for ‘AZ hints’. My understanding is
> that a segment is a subset of an AZ. So why are we not able to leverage
> that logic or make it more generic?
> Thanks
> Gary
>
> On 5/22/16, 4:02 AM, "Carl Baldwin"  wrote:
>
> >On Fri, May 20, 2016 at 1:44 PM, Brandon Logan
> > wrote:
> >> On Thu, 2016-05-19 at 14:16 -0600, Carl Baldwin wrote:
> >>> On Wed, May 18, 2016 at 1:36 PM, Kevin Benton 
> wrote:
> >>> >>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.
> >>>
> >>> I think I agree with this.  Let's not change the API at all to begin
> >>> with.  I do think this means that the current API should work with or
> >>> without segments.  I'm not sure that the current approach of doing
> >>> scheduling for segments completely independently of scheduling for
> >>> networks works for this.  Does it?
> >>>
> >>
> >> I still think it does, but we can make it work without making them
> >> separate.  My original plan was to keep them together, but that ended up
> >> causing some unclean code and also the possibility of requiring an
> >> interface change, which would break out-of-tree schedulers like bgp,
> >> that just got moved out of tree.  If I can devise an alternative to
> >> breaking that interface, then I'll go forward without separate
> >> schedulers.
> >
> >I think we've got a general idea of how it should behave.  Let's see
> >what you come up with.
> >
> >Carl
> >
> >__
> >OpenStack Development Mailing List (not for usage questions)
> >Unsubscribe:
> openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] DHCP Agent Scheduling for Segments

[Gary Kotton]

Today the DHCP schedulers have support for ‘AZ hints’. My understanding is that 
a segment is a subset of an AZ. So why are we not able to leverage that logic 
or make it more generic?
Thanks
Gary

On 5/22/16, 4:02 AM, "Carl Baldwin"  wrote:

>On Fri, May 20, 2016 at 1:44 PM, Brandon Logan
> wrote:
>> On Thu, 2016-05-19 at 14:16 -0600, Carl Baldwin wrote:
>>> On Wed, May 18, 2016 at 1:36 PM, Kevin Benton  wrote:
>>> >>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.
>>>
>>> I think I agree with this.  Let's not change the API at all to begin
>>> with.  I do think this means that the current API should work with or
>>> without segments.  I'm not sure that the current approach of doing
>>> scheduling for segments completely independently of scheduling for
>>> networks works for this.  Does it?
>>>
>>
>> I still think it does, but we can make it work without making them
>> separate.  My original plan was to keep them together, but that ended up
>> causing some unclean code and also the possibility of requiring an
>> interface change, which would break out-of-tree schedulers like bgp,
>> that just got moved out of tree.  If I can devise an alternative to
>> breaking that interface, then I'll go forward without separate
>> schedulers.
>
>I think we've got a general idea of how it should behave.  Let's see
>what you come up with.
>
>Carl
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] DHCP Agent Scheduling for Segments

[Carl Baldwin]

On Fri, May 20, 2016 at 1:44 PM, Brandon Logan
 wrote:
> On Thu, 2016-05-19 at 14:16 -0600, Carl Baldwin wrote:
>> On Wed, May 18, 2016 at 1:36 PM, Kevin Benton  wrote:
>> >>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.
>>
>> I think I agree with this.  Let's not change the API at all to begin
>> with.  I do think this means that the current API should work with or
>> without segments.  I'm not sure that the current approach of doing
>> scheduling for segments completely independently of scheduling for
>> networks works for this.  Does it?
>>
>
> I still think it does, but we can make it work without making them
> separate.  My original plan was to keep them together, but that ended up
> causing some unclean code and also the possibility of requiring an
> interface change, which would break out-of-tree schedulers like bgp,
> that just got moved out of tree.  If I can devise an alternative to
> breaking that interface, then I'll go forward without separate
> schedulers.

I think we've got a general idea of how it should behave.  Let's see
what you come up with.

Carl

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] DHCP Agent Scheduling for Segments

[Brandon Logan]

On Thu, 2016-05-19 at 14:16 -0600, Carl Baldwin wrote:
> On Wed, May 18, 2016 at 1:36 PM, Kevin Benton  wrote:
> >>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.
> 
> I think I agree with this.  Let's not change the API at all to begin
> with.  I do think this means that the current API should work with or
> without segments.  I'm not sure that the current approach of doing
> scheduling for segments completely independently of scheduling for
> networks works for this.  Does it?
> 

I still think it does, but we can make it work without making them
separate.  My original plan was to keep them together, but that ended up
causing some unclean code and also the possibility of requiring an
interface change, which would break out-of-tree schedulers like bgp,
that just got moved out of tree.  If I can devise an alternative to
breaking that interface, then I'll go forward without separate
schedulers.

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

This one is a lower priority, but I agree it could be beneficial.

> 
> Carl
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] DHCP Agent Scheduling for Segments

[Carl Baldwin]

On Wed, May 18, 2016 at 1:36 PM, Kevin Benton  wrote:
>>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.

I think I agree with this.  Let's not change the API at all to begin
with.  I do think this means that the current API should work with or
without segments.  I'm not sure that the current approach of doing
scheduling for segments completely independently of scheduling for
networks works for this.  Does it?

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

++

Carl

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] DHCP Agent Scheduling for Segments

[Kevin Benton]

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

Re: [openstack-dev] [neutron] DHCP Agent Scheduling for Segments

[Brandon Logan]

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

Re: [openstack-dev] [neutron] DHCP Agent Scheduling for Segments

[Kevin Benton]

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 
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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] DHCP Agent Scheduling for Segments

[Brandon Logan]

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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev