Open Stack

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