Open Stack

I'm only part way through reviewing this, but I think there's a fundamental
error in it.  We were at one point going to use 'enable_dhcp' in the
current set of flags to indicate something meaningful, but eventually we
decided that its current behaviour (despite the naming) really meant 'no
address assignment protocols are active' - which is why setting
enable_dhcp=False completely disables DHCP and RA activity in Neutron.  (I
believe Mark pointed that out, and agitated for backward compatibility,
though I couldn't tell you which forum it was in.)  Your proposal reverses
that decision, and says that it can be set to false and yet RAs will still
be sent out.

It's also why there are two additional attributes, because a single option
isn't really expressive enough once you consider the provider network
cases.  You are, in your own way, also using two attributes, by repurposing
enable_dhcp - your attribute values are different, but you're doing it for
similar reasons.

I'll put up my other review comments a bit later on when I've had another
think.
-- 
Ian.



On 11 June 2014 06:07, Robert Li (baoli) <baoli at cisco.com> wrote:

>  Hi,
>
>  I was mistakenly reusing the Blueprint
> https://blueprints.launchpad.net/neutron/+spec/neutron-ipv6-radvd-ra to
> draft up the ipv6 RA support in neutron. I apologize for any confusion that
> this may have caused. To correct it, I created a new blueprint
> https://blueprints.launchpad.net/neutron/+spec/neutron-ipv6-ra and linked
> it to a neutron spec https://review.openstack.org/92164.
>
>  The basic idea behind this blueprint is that neutron dhcp service as it
> is can hand out IPv6 addresses either in IPv6 only data network or in a
> dual stack data network. But the RA service including SLAAC support is
> missing in neutron. This service is important. Without RA, VMs won’t be
> able to automatically install default routes. Without SLAAC, a deployment
> that prefers SLAAC won’t be able to do it with neutron. The BP takes a
> straightforward approach to achieve that without requiring significant
> change to the existing dhcp service.
>
>  Any feedback is appreciated.
>
>  thanks,
> Robert
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140613/e2948f3a/attachment.html>