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 > For IPv4 it will always imply DHCP, but for IPv6 the method > to tell the port user (instance) the address might be SLAAC (for the > "slaac" and "dhcpv6-stateless" modes) or Stateful DHCPv6 (for the > "dhcpv6-stateful" mode). > > I think it would indeed be useful to convey the ipv6_address_mode (and > maybe also ipv6_ra_mode) in the metadata; but in principle a system > should be able to infer the supported mode by looking at the flags in > the RAs (Router Advertisements). It's just that most GNU/Linux > distributions ignore what the RAs say :-( Which is sad but true indeed, but IMO would be the correct solution in the long run, that's we the flags are there in the first place. FWIW there is a beta version of cirros that tries to implement this, but it has not been released yet. __________________________________________________________________________ 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