For Question 1, I think we can allow potential use cases (even OpenStack
doesn't support it for now), but we should not permit the combinations of
modes which don't make any sense.
For Question 2, for modes which don't make sense, I think error messages
and return code are needed. For mode combinations which require external RA
or DHCP, I think it's not OpenStack's job to check the external
configurations so we can just configure as the mode suggested in OpenStack
and leave the user/admin to configure the external server.
Xuhan
On Tue, Feb 11, 2014 at 4:38 AM, Veiga, Anthony
anthony_ve...@cable.comcast.com wrote:
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
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
