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 _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
