Open Stack

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" <gkotton at vmware.com> 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" <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
>
> __________________________________________________________________________
> 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/20160523/e12ed0fb/attachment.html>