<div dir="ltr">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. <br><br>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. <br>
<div class="gmail_extra"><br></div><div class="gmail_extra">Xuhan<br><br></div><div class="gmail_extra"><div class="gmail_quote">On Tue, Feb 11, 2014 at 4:38 AM, Veiga, Anthony <span dir="ltr"><<a href="mailto:Anthony_Veiga@cable.comcast.com" target="_blank">Anthony_Veiga@cable.comcast.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">During last week's IRC meeting, we ran into a question about validating<br>
the configuration options for ipv6_address_mode[1] and ipv6_ra_mode[1] for<br>
IPv6 networks. This brought up a few issues, but after mulling it over for<br>
a while I think it breaks down into 2 distinct questions.<br>
<br>
Question 1) Should we allow the user to build a potentially broken<br>
network, knowing that there may be a use case we haven't covered? The<br>
example of this is a service VM or corner case where it's absolutely<br>
mandatory that an administrator use an external routing/addressing<br>
mechanism that doesn't fit under our configuration options.<br>
<br>
I was asked to put together a list of cases where a "potentially invalid"<br>
configuration for OpenStack is still valid when external entities are in<br>
use.  One of these is setting ipv6_address_mode to stateful and<br>
ipv6_ra_mode to none.  Normally, this means a neutron network would never<br>
have addressed clients as no RA means no address.  However, a provider<br>
network with an external router would provide this.  So having the<br>
addressing mode in any state without an RA is still valid.  The opposite<br>
case would also be true, where an external source could be providing<br>
dhcpv6 information.  In this case, addressing could be set to off, but RA<br>
could be set to stateful/stateless.  The only case where I see a collision<br>
is where the two attributes are on but in entirely different modes.  For<br>
example, RA set to SLAAC but addressing set to stateful.<br>
<br>
Question 2) How do we alert the user of either a potentially invalid<br>
configuration or a configuration that we have blocked?<br>
<br>
Something else that came up in a Review[2] was that we need to honor<br>
enable_dhcp and alert the user as well.  Per ijw[3], we are supposed to<br>
treat enable_dhcp as an overriding flag.  If it's set to false, we don't<br>
even check the other two attributes, because we should be disabling<br>
addressing for this network.  I think the answer to #2 should apply here<br>
as well, but I wanted to point out that we should be treating enable_dhcp<br>
= False as a killswitch.<br>
<br>
<br>
[1] <a href="https://blueprints.launchpad.net/neutron/+spec/ipv6-two-attributes" target="_blank">https://blueprints.launchpad.net/neutron/+spec/ipv6-two-attributes</a><br>
[2] <a href="https://review.openstack.org/#/c/52983/22/neutron/api/v2/attributes.py" target="_blank">https://review.openstack.org/#/c/52983/22/neutron/api/v2/attributes.py</a><br>
[3]<br>
<a href="http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.2014
-01-21-14.00.log.html" target="_blank">http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.2014<br>
-01-21-14.00.log.html</a> timestamp 14:23:54<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div></div>