Open Stack

(resending with reply-all)

The routed networks work will include a change to the DHCP scheduler
which will work something like this:

1. Neutron subnets will have optional affinity to a segment
2. DHCP agents will (somewhat indirectly) report which segments to
which they are attached*.
3. Where today, DHCP schedules networks to DHCP agents, tomorrow DHCP
will schedule each segment to an agent that can reach it.  This will
be predicated on 'enable_dhcp' being set on the subnets.

There is an implicit assumption here that the operator will deploy a
DHCP agent in each of the segments.  This will be documented in the
guide.

Down the road, I really think we should continue to explore other
possibilities like DHCP relay or a DHCP responder on the compute host.
But, that should be considered an independent effort.

Carl

* they already do this by reporting physical_network in bridge mappings

On Thu, Feb 25, 2016 at 11:30 AM, Tim Bell <Tim.Bell at cern.ch> wrote:
>
> The CERN guys had some concerns on how dhcp was working in a segment environment. I’ll leave them to give details.
>
> Tim
>
>
>
>
>
> On 25/02/16 14:53, "Andrew Laski" <andrew at lascii.com> wrote:
>
>>
>>
>>On Thu, Feb 25, 2016, at 05:01 AM, Tim Bell wrote:
>>>
>>> CERN info added.. Feel free to come back for more information if needed.
>>
>>An additional piece of information we're specifically interested in from
>>all cellsv1 deployments is around the networking control plane setup. Is
>>there a single nova-net/Neutron deployment per region that is shared
>>among cells? It appears that all cells users are splitting the network
>>data plane into clusters/segments, are similar things being done to the
>>control plane?
>>
>>
>>>
>>> Tim
>>>
>>>
>>>
>>>
>>> On 24/02/16 22:47, "Edgar Magana" <edgar.magana at workday.com> wrote:
>>>
>>> >It will be awesome if we can add this doc into the networking guide  :-)
>>> >
>>> >
>>> >Edgar
>>> >
>>> >
>>> >
>>> >
>>> >On 2/24/16, 1:42 PM, "Matt Riedemann" <mriedem at linux.vnet.ibm.com> wrote:
>>> >
>>> >>The nova and neutron teams are trying to sort out existing deployment
>>> >>network scenarios for cells v1 so we can try and document some of that
>>> >>and get an idea if things change at all with cells v2.
>>> >>
>>> >>Therefore we're asking that deployers running cells please document
>>> >>anything you can in an etherpad [1].
>>> >>
>>> >>We'll try to distill that for upstream docs at some point and then use
>>> >>it as a reference when talking about cells v2 + networking.
>>> >>
>>> >>[1] https://etherpad.openstack.org/p/cells-networking-use-cases
>>> >>
>>> >>--
>>> >>
>>> >>Thanks,
>>> >>
>>> >>Matt Riedemann
>>> >>
>>> >>
>>> >>_______________________________________________
>>> >>OpenStack-operators mailing list
>>> >>OpenStack-operators at lists.openstack.org
>>> >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>> >_______________________________________________
>>> >OpenStack-operators mailing list
>>> >OpenStack-operators at lists.openstack.org
>>> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>> _______________________________________________
>>> OpenStack-operators mailing list
>>> OpenStack-operators at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>> Email had 1 attachment:
>>> + smime.p7s
>>>   4k (application/pkcs7-signature)
>>
>>_______________________________________________
>>OpenStack-operators mailing list
>>OpenStack-operators at lists.openstack.org
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>