<div dir="ltr">Ah okay... That's seems to be perfect fine... Thank you! :-)</div><div class="gmail_extra"><br><div class="gmail_quote">On 9 October 2014 10:22, Robert Li (baoli) <span dir="ltr"><<a href="mailto:baoli@cisco.com" target="_blank">baoli@cisco.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
<div>Hi Thiago,</div>
<div><br>
</div>
<div>A couple of things to consider:</div>
<div> — 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.</div>
<div><br>
</div>
<div> — if you want to use SLAAC, there might be a couple of ways to do that</div>
<div> . 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.</div>
<div> . 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. </div>
<div><br>
</div>
<div>Hope that it helps</div><span class="HOEnZb"><font color="#888888">
<div>Robert</div></font></span><div><div class="h5">
<div><br>
</div>
<span>
<div>
<div>On 10/8/14, 10:25 PM, "Martinx - ジェームズ" <<a href="mailto:thiagocmartinsc@gmail.com" target="_blank">thiagocmartinsc@gmail.com</a>> wrote:</div>
</div>
<div><br>
</div>
<blockquote style="BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0 0 5">
<div>
<div>
<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>
</div>
</div>
</blockquote>
</span>
</div></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">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>
<br></blockquote></div><br></div>