Open Stack

During last week's IRC meeting, we ran into a question about validating
the configuration options for ipv6_address_mode[1] and ipv6_ra_mode[1] for
IPv6 networks. This brought up a few issues, but after mulling it over for
a while I think it breaks down into 2 distinct questions.

Question 1) Should we allow the user to build a potentially broken
network, knowing that there may be a use case we haven't covered? The
example of this is a service VM or corner case where it's absolutely
mandatory that an administrator use an external routing/addressing
mechanism that doesn't fit under our configuration options.

I was asked to put together a list of cases where a "potentially invalid"
configuration for OpenStack is still valid when external entities are in
use.  One of these is setting ipv6_address_mode to stateful and
ipv6_ra_mode to none.  Normally, this means a neutron network would never
have addressed clients as no RA means no address.  However, a provider
network with an external router would provide this.  So having the
addressing mode in any state without an RA is still valid.  The opposite
case would also be true, where an external source could be providing
dhcpv6 information.  In this case, addressing could be set to off, but RA
could be set to stateful/stateless.  The only case where I see a collision
is where the two attributes are on but in entirely different modes.  For
example, RA set to SLAAC but addressing set to stateful.

Question 2) How do we alert the user of either a potentially invalid
configuration or a configuration that we have blocked?

Something else that came up in a Review[2] was that we need to honor
enable_dhcp and alert the user as well.  Per ijw[3], we are supposed to
treat enable_dhcp as an overriding flag.  If it's set to false, we don't
even check the other two attributes, because we should be disabling
addressing for this network.  I think the answer to #2 should apply here
as well, but I wanted to point out that we should be treating enable_dhcp
= False as a killswitch.


[1] https://blueprints.launchpad.net/neutron/+spec/ipv6-two-attributes
[2] https://review.openstack.org/#/c/52983/22/neutron/api/v2/attributes.py
[3] 
http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.2014
-01-21-14.00.log.html timestamp 14:23:54