<p dir="ltr">It would be worth looking at the code that adds AZ awareness to DHCP scheduling. There might be something to learn.</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">Carl</p>
<div class="gmail_quote">On May 22, 2016 7:32 AM, "Gary Kotton" <<a href="mailto:gkotton@vmware.com">gkotton@vmware.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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?<br>
Thanks<br>
Gary<br>
<br>
On 5/22/16, 4:02 AM, "Carl Baldwin" <<a href="mailto:carl@ecbaldwin.net">carl@ecbaldwin.net</a>> wrote:<br>
<br>
>On Fri, May 20, 2016 at 1:44 PM, Brandon Logan<br>
><<a href="mailto:brandon.logan@rackspace.com">brandon.logan@rackspace.com</a>> wrote:<br>
>> On Thu, 2016-05-19 at 14:16 -0600, Carl Baldwin wrote:<br>
>>> On Wed, May 18, 2016 at 1:36 PM, Kevin Benton <kevin@benton.pub> wrote:<br>
>>> >>I may have wrongly assumed that segments MAY have the possibility of being<br>
>>> >> l2 adjacent, even if the entire network they are in is not, which would mean<br>
>>> >> that viewing and scheduling these in the context of a segment could be<br>
>>> >> useful.<br>
>>> ><br>
>>> > Segments could be L2 adjacent, but I think it would be pretty uncommon for a<br>
>>> > DHCP agent to have access to multiple L2 adjacent segments for the same<br>
>>> > network. But even if that happens, the main use case I see for the scheduler<br>
>>> > API is taking networks off of dead agents, agents going under maintenance,<br>
>>> > or agents under heavy load. With the introduction of segments, all of those<br>
>>> > are still possible via the network-based API.<br>
>>><br>
>>> I think I agree with this. Let's not change the API at all to begin<br>
>>> with. I do think this means that the current API should work with or<br>
>>> without segments. I'm not sure that the current approach of doing<br>
>>> scheduling for segments completely independently of scheduling for<br>
>>> networks works for this. Does it?<br>
>>><br>
>><br>
>> I still think it does, but we can make it work without making them<br>
>> separate. My original plan was to keep them together, but that ended up<br>
>> causing some unclean code and also the possibility of requiring an<br>
>> interface change, which would break out-of-tree schedulers like bgp,<br>
>> that just got moved out of tree. If I can devise an alternative to<br>
>> breaking that interface, then I'll go forward without separate<br>
>> schedulers.<br>
><br>
>I think we've got a general idea of how it should behave. Let's see<br>
>what you come up with.<br>
><br>
>Carl<br>
><br>
>__________________________________________________________________________<br>
>OpenStack Development Mailing List (not for usage questions)<br>
>Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div>