Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

networkd: Implement ipv6-address-generation: stable-privacy #480

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

tatokis
Copy link

@tatokis tatokis commented Jun 16, 2024

Description

The relevant systemd pull request has long been merged, so add support for IPv6Token=prefixstable in the networkd generator.

systemd/systemd#16618

Checklist

  • Runs make check successfully.
  • Retains 100% code coverage (make check-coverage).
  • New/changed keys in YAML format are documented.
  • (Optional) Adds example YAML for new feature.
  • (Optional) Closes an open bug in Launchpad.

The relevant systemd pull request has long been merged, so add support
for IPv6Token=prefixstable in the networkd generator.

systemd/systemd#16618
@tatokis tatokis force-pushed the networkd-ipv6-stable-privacy branch from 69b6ab0 to 9cb7136 Compare June 16, 2024 06:30
@slyon slyon added the community This PR has been proposed by somebody outside of the Netplan team and roadmap commitments. label Jun 18, 2024
@slyon slyon self-requested a review June 18, 2024 09:16
Copy link
Collaborator

@slyon slyon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you very much for your contribution to Netplan!

I very much like this PR and the fact that you're fixing an existing TODO. Kudos!

When checking the context of this PR, I found that the [Network].IPv6Prefix= setting isn't listed anymore in the most recent man-page. It seems like the logic was shuffled a little to make use of a Token= setting instead, see: https://www.freedesktop.org/software/systemd/man/latest/systemd.network.html (and systemd/systemd#20778)

There might still be some legacy-fallback, which might keep this PR totally valid!
Are we certain that it actually works, though? Would you mind creating an integration test around it, e.g. similar to tests/integration/ethernets.py:test_dhcp6, but then checking for the stable prefix?

return FALSE;
} else {
switch (def->ip6_addr_gen_mode) {
case NETPLAN_ADDRGEN_DEFAULT:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nitpick: We should potentially keep the original comment about "EUI-64" here.

Suggested change
case NETPLAN_ADDRGEN_DEFAULT:
/* EUI-64 mode is enabled by default, if no IPv6Token= is specified */
case NETPLAN_ADDRGEN_DEFAULT:

@@ -1055,17 +1055,6 @@ def test_bridge_non_ovs_bond(self):
'ovs-br.network': ND_EMPTY % ('ovs-br', 'ipv6'),
'non-ovs-bond.netdev': '[NetDev]\nName=non-ovs-bond\nKind=bond\n'})

def test_ovs_invalid_networkd_config(self):
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

todo: We need to keep this test-case, in order to not decrease src/openvswitch.c code-coverage, checking that the OVS "cleanup" unit is created in failure case, too.

Of course, we cannot use the current failure case any more, as that got fixed :)

I'd suggest using something like this, which will trigger a similar failure-case:

    def test_ovs_invalid_networkd_config(self):
        err = self.generate('''network:
  version: 2
  bridges:
    br0:
      openvswitch: {}
      dhcp4: true
      dhcp4-overrides:
        use-domains: true
      dhcp6: true
      dhcp6-overrides:
        use-domains: false
''', expect_fail=True)
        self.assert_ovs({'cleanup.service': OVS_CLEANUP % {'iface': 'cleanup'}})
        self.assertIn('br0: networkd requires that use-domains has the same value', err)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
community This PR has been proposed by somebody outside of the Netplan team and roadmap commitments.
Projects
None yet
2 participants