Open Stack

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<mailto: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<mailto: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<mailto: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/dd0b0c0c/attachment.html>