Ah okay... That's seems to be perfect fine... Thank you! :-) On 9 October 2014 10:22, Robert Li (baoli) <ba...@cisco.com> wrote:
> Hi Thiago, > > A couple of things to consider: > — As it is now, it doesn’t seem to be fully functional if you change > your subnet to use SLAAC. The addresses that were assigned to your existing > ports in neutron wouldn’t be updated/changed. So basically, you can not > simply make an API call to change the subnet and expect that everything > will be setup correctly. Not mention that currently subnet api to update > the modes can’t even be invoked. > > — if you want to use SLAAC, there might be a couple of ways to do that > . Once multiple prefix is supported, you can create a new slaac > subnet in the same network. Obviously you need to use a different prefix. > Later, you can remove the previous subnet. > . For now, you can create a new network with a slaac subnet. And > attach your VMs to this new network. Once it’s done, you can remove the > previous network. > > Hope that it helps > Robert > > On 10/8/14, 10:25 PM, "Martinx - ジェームズ" <thiagocmarti...@gmail.com> > wrote: > > 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 > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
