[openstack-dev] [Neutron] Proposing to disallow updates of IPv6 attributes on subnets

Martinx - ジェームズ thiagocmartinsc at gmail.com
Thu Oct 9 16:25:50 UTC 2014


Ah okay... That's seems to be perfect fine... Thank you!   :-)

On 9 October 2014 10:22, Robert Li (baoli) <baoli at 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 - ジェームズ" <thiagocmartinsc at 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 <gessau at 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 at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> _______________________________________________
> 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/20141009/aa3be32d/attachment-0001.html>


More information about the OpenStack-dev mailing list