<div dir="ltr">Hi!<div><br></div><div>Currently, I have IceHouse up and running (Ubuntu 14.04.1) with VLAN Provider Network + static IPv6.</div><div><br></div><div>I created the subnet(s) like this (one for each tenant):</div><div><br></div><div>--</div><div><font face="courier new, monospace">neutron net-create --tenant-id $ID --provider:physical_network=physnet1 --provider:network_type=vlan --provider:segmentation_id=200 physnet1-vlan200<br></font></div><div><font face="courier new, monospace"><br></font></div><div><font face="courier new, monospace">neutron subnet-create --ip-version 6 --disable-dhcp --tenant-id $ID physnet1-vlan200 2001:db8:1::/64 --allocation-pool start=2001:db8:1::8000,end=2001:db8:1:0:ffff:ffff:ffff:fffe</font><br></div><div>--</div><div><br></div><div>This new BUGs means that, after upgrading to Juno, I'll not be able to "update / convert" this static network to SLAAC ?!?!</div><div><br></div><div>If yes, how can I force the update without breaking the production environment? Is there a procedure to follow?</div><div><br></div><div>I'm not using Neutron L3 Router and I have no plans to use GRE/VXLAN, neither a radvd controlled by Neutron. My upstream router already have radvd ready.</div><div><br></div><div>Thanks!</div><div>Thiago</div><div class="gmail_extra"><br><div class="gmail_quote">On 7 October 2014 13:21, Henry Gessau <span dir="ltr"><<a href="mailto:gessau@cisco.com" target="_blank">gessau@cisco.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A number of bugs[1][2][3] have been filed which are related to updating the<br>
IPv6 attributes after a subnet has been created.<br>
<br>
In the reviews[4][5] for the fixes for [1] and [2] some shortcomings and<br>
questions have been raised, which were discussed in today's IPv6 IRC meeting[6].<br>
<br>
Summary:<br>
In Juno we are not ready for allowing the IPv6 attributes on a subnet to be<br>
updated after the subnet is created, because:<br>
- The implementation for supporting updates is incomplete.<br>
- Perceived lack of usefulness, no good use cases known yet.<br>
- Allowing updates causes more complexity in the code.<br>
- Have not tested that radvd, dhcp, etc. behave OK after update.<br>
<br>
Therefore we are proposing to change 'allow_put' to False for the two IPv6<br>
attributes, ipv6_ra_mode and ipv6_address_mode. This will prevent the modes<br>
from being updated via the PUT:subnets API.<br>
<br>
We would be interested to hear of any disagreements or questions.<br>
<br>
<br>
[1] <a href="https://launchpad.net/bugs/1362966" target="_blank">https://launchpad.net/bugs/1362966</a><br>
[2] <a href="https://launchpad.net/bugs/1363064" target="_blank">https://launchpad.net/bugs/1363064</a><br>
[3] <a href="https://launchpad.net/bugs/1373417" target="_blank">https://launchpad.net/bugs/1373417</a><br>
[4] <a href="https://review.openstack.org/125328" target="_blank">https://review.openstack.org/125328</a><br>
[5] <a href="https://review.openstack.org/117799" target="_blank">https://review.openstack.org/117799</a><br>
[6]<br>
<a href="http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.2014-10-07-15.01.log.html" target="_blank">http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.2014-10-07-15.01.log.html</a><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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>