Re: [openstack-dev] [neutron] DHCP Agent Scheduling for Segments
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
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
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
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
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
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
>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 networks may have multiple > > segments while > >
Re: [openstack-dev] [neutron] DHCP Agent Scheduling for Segments
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 Mailing List (not for usage que
Re: [openstack-dev] [neutron] DHCP Agent Scheduling for Segments
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
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