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" <[email protected]> wrote: >On Fri, May 20, 2016 at 1:44 PM, Brandon Logan ><[email protected]> wrote: >> On Thu, 2016-05-19 at 14:16 -0600, Carl Baldwin wrote: >>> On Wed, May 18, 2016 at 1:36 PM, Kevin Benton <[email protected]> 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: [email protected]?subject:unsubscribe >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
