test: limit temp dhcp6 changes to < NOBLE

[TheRealFalcon]

Proposed Commit Message

test: limit temp dhcp6 changes to < NOBLE

#4474 landed in Noble, so this block isn't needed.

Additional Context

https://jenkins.canonical.com/server-team/view/cloud-init/job/cloud-init-integration-noble-gce/49/testReport/junit/tests.integration_tests/test_upgrade/test_clean_boot_of_upgraded_package/

Merge type

• Squash merge using "Proposed Commit Message"
• Rebase and merge unique commits. Requires commit messages per-commit each referencing the pull request number (#<PR_NUM>)

[a-dubs]

Nice catch! Looks good. My eyes don't work too well tho...

[blackboxsw]

@TheRealFalcon @holmanb don't we need to patch #4474 behavior related to dhcp6: true in network config from generate_fallback_config to avoid change in behavior on stable releases? I see no applicable quilt patches in our ubuntu/* branches to limit this behavior to just NOBLE.

[TheRealFalcon]

Is there reason to think this would break anything? I didn't think we needed to patch this one.

[blackboxsw]

Is there reason to think this would break anything? I didn't think we needed to patch this one.

As long as our rendered network config definition is not blocking/waiting indefinitely on marking the network interface "up" on having a viable dhcp6 route/response from the DHCP server, then it shouldn't impact anything such as boot time while we await for network-online.target.

[TheRealFalcon]

not blocking/waiting indefinitely on marking the network interface "up"

Yeah, that's a valid concern. I initially reverted this one because it would cause exactly that on NetworkManager, but we were able to get that fixed in a follow-up to #4474

[aciba90]

LGTM!

[blackboxsw]

Thanks for this. I found the supplemental commit that fixed this issue for NetworkManager rendered config 29dd5ac. And also confirmed that on systemd-networkd environments rendered from netplan config, we don't see issues with timing in environments with no dhcp6 provided from the dhcp service with /run/systemd/network/*.network config setting [Network]\nDHCP=yes which is generated due to dhcp6 and dhcp4 vs just DHCP=ipv4 which is rendered when we only specific dhcp4: true config in netplan.

I approve that it doesn't appear we need to stub out or disable this behavior on stable releases given the fix that already landed relative to NM, networkd and netplan rendering will be rendered with DHCP=yes when both dhcp6 and dhcp4 config is requested. This change doesn't appear to introduce boot-time cost when comparing multiple runs with and without dhcp6 config requested when the DHCP service doesn't provide and DHCPv6 config.