[openstack-dev] [neutron] DHCP Agent Scheduling for Segments
gkotton at vmware.com
Sun May 22 13:31:30 UTC 2016
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?
On 5/22/16, 4:02 AM, "Carl Baldwin" <carl at ecbaldwin.net> wrote:
>On Fri, May 20, 2016 at 1:44 PM, Brandon Logan
><brandon.logan at rackspace.com> wrote:
>> On Thu, 2016-05-19 at 14:16 -0600, Carl Baldwin wrote:
>>> On Wed, May 18, 2016 at 1:36 PM, Kevin Benton <kevin at benton.pub> 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
>I think we've got a general idea of how it should behave. Let's see
>what you come up with.
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev