<div dir="ltr">><span style="font-size:12.8px">Our DHCP concern is because currently the DHCP agent needs to be assigned</span><div style="font-size:12.8px">to a network and then it creates a port for each subnet.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">The DHCP agent doesn't create a port per subnet. It only creates a port per network and adds extra IPs to that port as extra subnets are added to the network.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">In the segmentation use case it would only have one port per segment.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 26, 2016 at 5:21 AM, Belmiro Moreira <span dir="ltr"><<a href="mailto:moreira.belmiro.email.lists@gmail.com" target="_blank">moreira.belmiro.email.lists@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi,</div><div>thanks Carl for info about the DHCP plans.</div><div><br></div><div>Our DHCP concern is because currently the DHCP agent needs to be assigned</div><div>to a network and then it creates a port for each subnet.</div><div>In our infrastructure we only consider a network with several hundred subnets. </div><div>By default the DHCP agent runs in the network node however when using provider</div><div>networks and segmentation the DHCP requests will not reach it.</div><div><br></div><div>My understanding is that the plan is to have the DHCP agent per segment. That is great. </div><div>But it will continue to create a port per subnet?</div><div>Looking into our usecase (only provided networks with segmentation) I don't see why it </div><div>should create ports.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Belmiro</div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 26, 2016 at 2:55 AM, Sam Morrison <span dir="ltr"><<a href="mailto:sorrison@gmail.com" target="_blank">sorrison@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
> On 26 Feb 2016, at 9:20 AM, Carl Baldwin <<a href="mailto:carl@ecbaldwin.net" target="_blank">carl@ecbaldwin.net</a>> wrote:<br>
><br>
> (resending with reply-all)<br>
><br>
> The routed networks work will include a change to the DHCP scheduler<br>
> which will work something like this:<br>
><br>
> 1. Neutron subnets will have optional affinity to a segment<br>
> 2. DHCP agents will (somewhat indirectly) report which segments to<br>
> which they are attached*.<br>
> 3. Where today, DHCP schedules networks to DHCP agents, tomorrow DHCP<br>
> will schedule each segment to an agent that can reach it. This will<br>
> be predicated on 'enable_dhcp' being set on the subnets.<br>
><br>
> There is an implicit assumption here that the operator will deploy a<br>
> DHCP agent in each of the segments. This will be documented in the<br>
> guide.<br>
<br>
</span>I assume you’re referring to <a href="https://review.openstack.org/#/c/205631/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/205631/</a><br>
Really keen to get this in, we’re using this in prod and works well for us.<br>
<span><font color="#888888"><br>
Sam<br>
</font></span><div><div><br>
<br>
<br>
<br>
> Down the road, I really think we should continue to explore other<br>
> possibilities like DHCP relay or a DHCP responder on the compute host.<br>
> But, that should be considered an independent effort.<br>
><br>
> Carl<br>
><br>
> * they already do this by reporting physical_network in bridge mappings<br>
><br>
> On Thu, Feb 25, 2016 at 11:30 AM, Tim Bell <<a href="mailto:Tim.Bell@cern.ch" target="_blank">Tim.Bell@cern.ch</a>> wrote:<br>
>><br>
>> The CERN guys had some concerns on how dhcp was working in a segment environment. I’ll leave them to give details.<br>
>><br>
>> Tim<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> On 25/02/16 14:53, "Andrew Laski" <<a href="mailto:andrew@lascii.com" target="_blank">andrew@lascii.com</a>> wrote:<br>
>><br>
>>><br>
>>><br>
>>> On Thu, Feb 25, 2016, at 05:01 AM, Tim Bell wrote:<br>
>>>><br>
>>>> CERN info added.. Feel free to come back for more information if needed.<br>
>>><br>
>>> An additional piece of information we're specifically interested in from<br>
>>> all cellsv1 deployments is around the networking control plane setup. Is<br>
>>> there a single nova-net/Neutron deployment per region that is shared<br>
>>> among cells? It appears that all cells users are splitting the network<br>
>>> data plane into clusters/segments, are similar things being done to the<br>
>>> control plane?<br>
>>><br>
>>><br>
>>>><br>
>>>> Tim<br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>> On 24/02/16 22:47, "Edgar Magana" <<a href="mailto:edgar.magana@workday.com" target="_blank">edgar.magana@workday.com</a>> wrote:<br>
>>>><br>
>>>>> It will be awesome if we can add this doc into the networking guide :-)<br>
>>>>><br>
>>>>><br>
>>>>> Edgar<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> On 2/24/16, 1:42 PM, "Matt Riedemann" <<a href="mailto:mriedem@linux.vnet.ibm.com" target="_blank">mriedem@linux.vnet.ibm.com</a>> wrote:<br>
>>>>><br>
>>>>>> The nova and neutron teams are trying to sort out existing deployment<br>
>>>>>> network scenarios for cells v1 so we can try and document some of that<br>
>>>>>> and get an idea if things change at all with cells v2.<br>
>>>>>><br>
>>>>>> Therefore we're asking that deployers running cells please document<br>
>>>>>> anything you can in an etherpad [1].<br>
>>>>>><br>
>>>>>> We'll try to distill that for upstream docs at some point and then use<br>
>>>>>> it as a reference when talking about cells v2 + networking.<br>
>>>>>><br>
>>>>>> [1] <a href="https://etherpad.openstack.org/p/cells-networking-use-cases" rel="noreferrer" target="_blank">https://etherpad.openstack.org/p/cells-networking-use-cases</a><br>
>>>>>><br>
>>>>>> --<br>
>>>>>><br>
>>>>>> Thanks,<br>
>>>>>><br>
>>>>>> Matt Riedemann<br>
>>>>>><br>
>>>>>><br>
>>>>>> _______________________________________________<br>
>>>>>> OpenStack-operators mailing list<br>
>>>>>> <a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
>>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
>>>>> _______________________________________________<br>
>>>>> OpenStack-operators mailing list<br>
>>>>> <a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
>>>> _______________________________________________<br>
>>>> OpenStack-operators mailing list<br>
>>>> <a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
>>>> Email had 1 attachment:<br>
>>>> + smime.p7s<br>
>>>> 4k (application/pkcs7-signature)<br>
>>><br>
>>> _______________________________________________<br>
>>> OpenStack-operators mailing list<br>
>>> <a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-operators mailing list<br>
>> <a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
>><br>
><br>
> _______________________________________________<br>
> OpenStack-operators mailing list<br>
> <a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
<br>
<br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
<br></blockquote></div><br></div>