2017-03-24 17:17 GMT+00:00 Clark Boylan <cboy...@sapwetik.org>: > On Fri, Mar 24, 2017, at 05:24 AM, Jens Rosenboom wrote: >> 2017-03-24 9:48 GMT+00:00 Jens Rosenboom <j.rosenb...@x-ion.de>: >> > 2017-03-24 9:30 GMT+00:00 Simon Leinen <simon.lei...@switch.ch>: >> >> Clark Boylan writes: >> >> [...] >> >>> { >> >>> "id": "network1", >> >>> "link": "tap14b906ba-8c", >> >>> "network_id": "7ee08c00-7323-4f18-94bb-67e081520e70", >> >>> "type": "ipv6_dhcp" >> >>> } >> >>> ], >> >>> "services": [] >> >>> } >> >> >> >>> You'll notice that the network1 entry has a type of ipv6_dhcp; however, >> >>> if you ask the neutron api it tells slaac is the ipv6_address_mode and >> >>> ipv6_ra_mode. But enable_dhcp is also set to True. So which is it? Is >> >>> there a bug here or am I missing something obvious? At the very least it >> >>> appears that the config drive info is incomplete and does not include >> >>> the slaac info. >> > >> > Two small notes: >> > >> > 1. The enable_dhcp must be true also for slaac, its real meaning >> > is not "dhcp is enabled", but "neutron will take care of address >> > assignments". >> > >> > 2. The situation is not specific to the config drive being used, the >> > identical >> > information is presented at >> > http://169.254.169.254/openstack/latest/network_data.json >> > >> >> Here's my hypothesis... "type ipvX_dhcp" really means "Neutron will >> >> manage ipvX addresses", not necessarily that it will use the DHCP >> >> protocol. >> > >> > Right, this is the code part that produces the info: >> > http://git.openstack.org/cgit/openstack/nova/tree/nova/virt/netutils.py#n267 >> >> Actually, there seems to be a bug here, or maybe two. >> >> There is a dhcp_server address set in the info for the subnet even when >> it >> has type slaac, which cause the logic above to output type "ipv6_dhcp" >> instead >> of "ipv6". Either that is a bug in Neutron or there is some hidden reason >> to >> also have a DHCP server address for slaac. >> >> It certainly is a bug in Nova to rely on that attribute in order to >> decide upon >> the network type, as for dhcpv6-stateless we would certainly have a >> dhcp_server >> defined additional information, but still the address configuration >> type is slaac >> and so the network type should be "ipv6" and the address for that subnet >> be included in the metadata. >> >> P.S.: I vaguely remember a discussion that the dhcp_server should also >> send RAs in case of networks not having a router, maybe that is the >> reason >> for the behaviour above. Though I consider that scenario broken, RAs are >> "*router* advertisements" and thus should only be sent by routers. If >> people decide to deploy IPv6 on an isolated subnet, they should either >> be using DHCP or no auto-configuration at all. > > Thank you for looking into this. As mentioned earlier in the thread > glean needs to be able to configure the Linux interfaces explicitly for > auto or dhcp so ideally the metadata info would also be explicit. I > think that setting the type to "ipv6_dhcp" when using slaac has to be a > bug when considering this because it means glean and other tools like > cloud init will not be able to configure Linux interfaces properly. > > Are you going to be filing the bugs against nova and/or neutron? I think > you understand the fine details better than I do, but I am happy to help > out filing and pushing things as this would affect our use case quite a > bit. Just let me know how I can help.
IMO this is a nova bug, neutron does provide all the information that is needed, its just that nova chooses to filter some of it: https://bugs.launchpad.net/nova/+bug/1676363 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev