Open Stack

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.

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