yahoo-eng-team team mailing list archive

[Antti Myyrä <1912545@xxxxxxxxxxxxxxxxxx>]

Caused by a mistake elsewhere, not a bug.

** Changed in: cloud-init
       Status: In Progress => Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1912545

Title:
  accept_ra dropped in network config conversion

Status in cloud-init:
  Invalid

Bug description:
  Hi!

  Cloud-init's eni renderer converts version 2 network config to version
  1 before rendering. This is eventually done by the _v2_to_v1_ipcfg
  function within net/network_state.py. When version 2's dhcp6 is set to
  True, it proceeds to add possible dhcp6-overrides and then continues,
  disregarding the accept_ra option. This makes specifying the stateless
  DHCPv6 (ipv6_dhcpv6-stateless in v1 config's subnet type) impossible.
  Following shortened log shows the issue:

  2021-01-19 17:57:02,769 - stages.py[DEBUG]: applying net config names for {'version': 2, 'ethernets': {'ens5': {'match': {'macaddress': '3a:d6:ba:4a:67:23'}, 'dhcp6': True, 'accept_ra': True}}}
  2021-01-19 17:57:02,770 - __init__.py[DEBUG]: no interfaces to rename
  2021-01-19 17:57:02,770 - stages.py[INFO]: Applying network configuration from ds bringup=False: {'version': 2, 'ethernets': {'ens5': {'match': {'macaddress': '3a:d6:ba:4a:67:23'}, 'dhcp6': True, 'accept_ra': True}}}
  2021-01-19 17:57:02,770 - __init__.py[DEBUG]: Selected renderer 'eni' from priority list: None
  2021-01-19 17:57:02,774 - network_state.py[DEBUG]: v2(ethernets) -> v1(physical):
  {'type': 'physical', 'name': 'ens5', 'mac_address': '3a:d6:ba:4a:67:23', 'match': {'macaddress': '3a:d6:ba:4a:67:23'}, 'subnets': [{'type': 'dhcp6'}]}

  (For some reason, converted v1 config also contains v2's match part,
  which v1 doesn't need, but it shouldn't affect anything.)

  My suggested fix would be to have _v2_to_v1_ipcfg use the
  "ipv6_dhcpv6-stateless" as type when both dhcp6 and accept_ra are
  present. There's also another SLAAC mode (ipv6_slaac in v1) that uses
  accept_ra without DHCP, so it should be handled in the same function
  when accept_ra is set to True but dhcp6 isn't.

  I can make a PR to cloud-init's Github repo for this, but would like
  to hear if anyone sees problems with the suggested approach. Thank
  you!

  Best regards,
  Antti Myyrä

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1912545/+subscriptions