Hi! Currently, I have IceHouse up and running (Ubuntu 14.04.1) with VLAN Provider Network + static IPv6.
I created the subnet(s) like this (one for each tenant): -- neutron net-create --tenant-id $ID --provider:physical_network=physnet1 --provider:network_type=vlan --provider:segmentation_id=200 physnet1-vlan200 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 -- This new BUGs means that, after upgrading to Juno, I'll not be able to "update / convert" this static network to SLAAC ?!?! If yes, how can I force the update without breaking the production environment? Is there a procedure to follow? 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. Thanks! Thiago On 7 October 2014 13:21, Henry Gessau <ges...@cisco.com> wrote: > A number of bugs[1][2][3] have been filed which are related to updating the > IPv6 attributes after a subnet has been created. > > In the reviews[4][5] for the fixes for [1] and [2] some shortcomings and > questions have been raised, which were discussed in today's IPv6 IRC > meeting[6]. > > Summary: > In Juno we are not ready for allowing the IPv6 attributes on a subnet to be > updated after the subnet is created, because: > - The implementation for supporting updates is incomplete. > - Perceived lack of usefulness, no good use cases known yet. > - Allowing updates causes more complexity in the code. > - Have not tested that radvd, dhcp, etc. behave OK after update. > > Therefore we are proposing to change 'allow_put' to False for the two IPv6 > attributes, ipv6_ra_mode and ipv6_address_mode. This will prevent the modes > from being updated via the PUT:subnets API. > > We would be interested to hear of any disagreements or questions. > > > [1] https://launchpad.net/bugs/1362966 > [2] https://launchpad.net/bugs/1363064 > [3] https://launchpad.net/bugs/1373417 > [4] https://review.openstack.org/125328 > [5] https://review.openstack.org/117799 > [6] > > http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.2014-10-07-15.01.log.html > > _______________________________________________ > 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