Open Stack

2017-03-24 17:17 GMT+00:00 Clark Boylan <cboylan at 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.rosenboom at x-ion.de>:
>> > 2017-03-24 9:30 GMT+00:00 Simon Leinen <simon.leinen at 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