Open Stack

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_Veiga at 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 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/20140211/c4763c30/attachment.html>