fix(cloudstack): get domain name and vr information from network manager leases by ani-sinha · Pull Request #6829 · canonical/cloud-init

ani-sinha · 2026-04-07T05:10:42Z

This is a series of four independent commits.
The first commit adds helper functions in dhcp module to get dhcp lease information from network manager.
The second commit fixes a mock leak in existing cloudstack unit test code.
The third commit adds ability in cloud stack code trying to get domain name use network manager leases as well (in addition to trying networtkd and isa dhclient as it does today already).
The fourth commit adds support in cloud stack code to get VR information from network manager lease information.

This change has been tested by our (Red Hat) customer. After the change, we see logs of this type:

2026-04-04 15:19:54,813 - DataSourceCloudStack.py[DEBUG]: FQDN requested
2026-04-04 15:19:54,813 - DataSourceCloudStack.py[DEBUG]: Try obtaining domain name from networkd leases
2026-04-04 15:19:54,813 - DataSourceCloudStack.py[DEBUG]: Could not obtain FQDN from networkd leases. Falling back to ISC dhclient
2026-04-04 15:19:54,813 - DataSourceCloudStack.py[DEBUG]: Could not obtain FQDN from ISC dhclient leases. Falling back to Network Manager leases
2026-04-04 15:19:54,814 - subp.py[DEBUG]: Running command ['/usr/bin/nmcli', '-f', 'DHCP4', 'd', 'show'] with allowed return codes [0] (shell=False, capture=True)
2026-04-04 15:19:54,827 - performance.py[DEBUG]: Running ['/usr/bin/nmcli', '-f', 'DHCP4', 'd', 'show'] took 0.014 seconds
2026-04-04 15:19:54,828 - DataSourceCloudStack.py[DEBUG]: Obtained the following FQDN: foo.bar.baz.com
2026-04-04 15:19:54,828 - xxx[DEBUG]: XYZ hostname: foo.bar.baz.com

Proposed Commit Message

Commit 1:

feat(dhcp): Add network manager lease parsing capability

DHCP leases can be directly obtained from network manager through appropriate
command to the network manager cli. Add a couple of helper functions to get
the lease information from network manager.

In a subsequent patch, we will use the helper function from cloud stack
datasource to get the lease information from network manager.

Commit 2:

test: fix test_get_domainname_isc_dhclient mock leak

Without mocking out dhcp.IscDhclient.get_newest_lease_file_from_distro, the
functions on some platforms returns None. This means
get_key_from_latest_lease() bails out early without calling parse_leases()
to parse the lease file. Fix it.

Commit 3:

fix(cloudstack): get domain name information from network manager leases

Red Hat uses network manager as the supported dhcp client. If network manager
cli is available, we should try to get domain name information directly from
the network manager leases before asking distro specific dhcp client
(dhcpcd by default).

Commit 4:

fix(cloudstack): get vr information from network manager leases (#6829)

Red Hat distributions uses network manager to manage DHCP leases. This change
adds support for obtaining vr address information from DHCP leases maintained
by network manager.

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>)

) DHCP leases can be directly obtained from network manager through appropriate command to the network manager cli. Add a couple of helper functions to get the lease information from network manager. In a subsequent patch, we will use the helper function from cloud stack datasource to get the lease information from network manager. Signed-off-by: Ani Sinha <anisinha@redhat.com>

Without mocking out dhcp.IscDhclient.get_newest_lease_file_from_distro, the functions on some platforms returns None. This means get_key_from_latest_lease() bails out early without calling parse_leases() to parse the lease file. Fix it. Signed-off-by: Ani Sinha <anisinha@redhat.com>

…ses (canonical#6829) Red Hat uses network manager as the supported dhcp client. If network manager cli is available, we should try to get domain name information directly from the network manager leases before asking distro specific dhcp client (dhcpcd by default). Signed-off-by: Ani Sinha <anisinha@redhat.com>

ani-sinha · 2026-04-08T02:31:30Z

@holmanb @TheRealFalcon please review

blackboxsw

Thanks for this proposal @ani-sinha. I think it is almost there, but needs a bit more support awareness of multi-NIC environments with two active interfacees and test coverage in test_dhcp.py.

blackboxsw · 2026-04-14T18:24:21Z

+        line = line.split(":", 1)[-1].strip()
+        content.append(line)
+
+    return dict(configobj.ConfigObj(content, list_values=False))


While this processing works for single interface systems, it falls over on systems that have multiple devices because we have output like the following containing non-unique keys and each separate device is only separated by a blank newline

DHCP4.OPTION[1]: dhcp_client_identifier = 01:6c:ff:dd:aa> DHCP4.OPTION[2]: dhcp_lease_time = 86400 DHCP4.OPTION[3]: dhcp_server_identifier = 192.168.1.1 DHCP4.OPTION[4]: domain_name_servers = 192.168.1.1 DHCP4.OPTION[5]: expiry = 1776277372 DHCP4.OPTION[6]: ip_address = 192.168.1.44 DHCP4.OPTION[7]: requested_broadcast_address = 1 DHCP4.OPTION[8]: requested_domain_name = 1 DHCP4.OPTION[9]: requested_domain_name_servers = 1 DHCP4.OPTION[10]: requested_domain_search = 1 DHCP4.OPTION[11]: requested_host_name = 1 DHCP4.OPTION[12]: requested_interface_mtu = 1 DHCP4.OPTION[13]: requested_ms_classless_static_routes = 1 DHCP4.OPTION[14]: requested_nis_domain = 1 DHCP4.OPTION[15]: requested_nis_servers = 1 DHCP4.OPTION[16]: requested_ntp_servers = 1 DHCP4.OPTION[17]: requested_rfc3442_classless_static_rout> DHCP4.OPTION[18]: requested_root_path = 1 DHCP4.OPTION[19]: requested_routers = 1 DHCP4.OPTION[20]: requested_static_routes = 1 DHCP4.OPTION[21]: requested_subnet_mask = 1 DHCP4.OPTION[22]: requested_time_offset = 1 DHCP4.OPTION[23]: requested_wpad = 1 DHCP4.OPTION[24]: routers = 192.168.1.1 DHCP4.OPTION[25]: subnet_mask = 255.255.255.0 DHCP4.OPTION[1]: dhcp_client_identifier = 01:38:cc:nn:aa> DHCP4.OPTION[2]: dhcp_lease_time = 86400 DHCP4.OPTION[3]: dhcp_server_identifier = 192.168.1.1 DHCP4.OPTION[4]: domain_name_servers = 192.168.1.1 DHCP4.OPTION[5]: expiry = 1776255526 DHCP4.OPTION[6]: ip_address = 192.168.1.17 DHCP4.OPTION[7]: requested_broadcast_address = 1 DHCP4.OPTION[8]: requested_domain_name = 1 DHCP4.OPTION[9]: requested_domain_name_servers = 1 DHCP4.OPTION[10]: requested_domain_search = 1 DHCP4.OPTION[11]: requested_host_name = 1 DHCP4.OPTION[12]: requested_interface_mtu = 1 DHCP4.OPTION[13]: requested_ms_classless_static_routes = 1 DHCP4.OPTION[14]: requested_nis_domain = 1 DHCP4.OPTION[15]: requested_nis_servers = 1 DHCP4.OPTION[16]: requested_ntp_servers = 1 DHCP4.OPTION[17]: requested_rfc3442_classless_static_rout> DHCP4.OPTION[18]: requested_root_path = 1 DHCP4.OPTION[19]: requested_routers = 1 DHCP4.OPTION[20]: requested_static_routes = 1 DHCP4.OPTION[21]: requested_subnet_mask = 1 DHCP4.OPTION[22]: requested_time_offset = 1 DHCP4.OPTION[23]: requested_wpad = 1 DHCP4.OPTION[24]: routers = 192.168.1.1 DHCP4.OPTION[25]: subnet_mask = 255.255.255.0

This results in ConfgObj failures due to being unable to process the content:

Traceback (most recent call last): File "<string>", line 1, in <module> File "./cloud-init/cloudinit/net/dhcp.py", line 187, in network_manager_load_leases return dict(configobj.ConfigObj(content, list_values=False)) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/configobj/__init__.py", line 1228, in __init__ self._load(infile, configspec) File "/usr/lib/python3/dist-packages/configobj/__init__.py", line 1317, in _load raise error configobj.ConfigObjError: Parsing failed with several errors. First error at line 27.

Copilot

Pull request overview

This PR extends CloudStack hostname/FQDN discovery by adding NetworkManager (nmcli) DHCP lease parsing helpers and using them as an additional fallback when determining the DHCP-provided domain name. It also adjusts CloudStack unit tests to avoid a mock leak and to cover the new NetworkManager fallback behavior.

Changes:

Add nmcli-based DHCP4/DHCP6 lease parsing helpers in cloudinit/net/dhcp.py.
Update DataSourceCloudStack._get_domainname() to attempt NetworkManager leases after ISC dhclient leases.
Fix/extend unit tests to properly mock ISC dhclient lease file selection and to validate the NetworkManager path.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
`cloudinit/net/dhcp.py`	Adds helper functions to run `nmcli` and parse NetworkManager DHCP lease output.
`cloudinit/sources/DataSourceCloudStack.py`	Adds a NetworkManager lease fallback when determining domain name for FQDN construction.
`tests/unittests/sources/test_cloudstack.py`	Updates mocks to avoid platform-dependent behavior and adds a test for the NetworkManager fallback path.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

) DHCP leases can be directly obtained from network manager through appropriate command to the network manager cli. Add a couple of helper functions to get the lease information from network manager. In a subsequent patch, we will use the helper function from cloud stack datasource to get the lease information from network manager. Signed-off-by: Ani Sinha <anisinha@redhat.com> Co-authored-by: Chad Smith <chad.smith@canonical.com>

Without mocking out dhcp.IscDhclient.get_newest_lease_file_from_distro, the functions on some platforms returns None. This means get_key_from_latest_lease() bails out early without calling parse_leases() to parse the lease file. Fix it. Signed-off-by: Ani Sinha <anisinha@redhat.com>

…ses (canonical#6829) Red Hat uses network manager as the supported dhcp client. If network manager cli is available, we should try to get domain name information directly from the network manager leases before asking distro specific dhcp client (dhcpcd by default). Signed-off-by: Ani Sinha <anisinha@redhat.com> Co-authored-by: Chad Smith <chad.smith@canonical.com>

blackboxsw

Thank you @ani-sinha. I think what remains is a request for type hints for new functions and params and a couple of additional unittest requests.

) DHCP leases can be directly obtained from network manager through appropriate command to the network manager cli. Add a couple of helper functions to get the lease information from network manager. In a subsequent patch, we will use the helper function from cloud stack datasource to get the lease information from network manager. Signed-off-by: Ani Sinha <anisinha@redhat.com> Co-authored-by: Chad Smith <chad.smith@canonical.com>

Without mocking out dhcp.IscDhclient.get_newest_lease_file_from_distro, the functions on some platforms returns None. This means get_key_from_latest_lease() bails out early without calling parse_leases() to parse the lease file. Fix it. Signed-off-by: Ani Sinha <anisinha@redhat.com>

…ses (canonical#6829) Red Hat uses network manager as the supported dhcp client. If network manager cli is available, we should try to get domain name information directly from the network manager leases before asking distro specific dhcp client (dhcpcd by default). Signed-off-by: Ani Sinha <anisinha@redhat.com> Co-authored-by: Chad Smith <chad.smith@canonical.com>

) DHCP leases can be directly obtained from network manager through appropriate command to the network manager cli. Add a couple of helper functions to get the lease information from network manager. In a subsequent patch, we will use the helper function from cloud stack datasource to get the lease information from network manager. Signed-off-by: Ani Sinha <anisinha@redhat.com> Co-authored-by: Chad Smith <chad.smith@canonical.com>

Without mocking out dhcp.IscDhclient.get_newest_lease_file_from_distro, the functions on some platforms returns None. This means get_key_from_latest_lease() bails out early without calling parse_leases() to parse the lease file. Fix it. Signed-off-by: Ani Sinha <anisinha@redhat.com>

…ses (canonical#6829) Red Hat uses network manager as the supported dhcp client. If network manager cli is available, we should try to get domain name information directly from the network manager leases before asking distro specific dhcp client (dhcpcd by default). Signed-off-by: Ani Sinha <anisinha@redhat.com> Co-authored-by: Chad Smith <chad.smith@canonical.com>

holmanb

Thanks for the proposal. I haven't looked closely at the tests, but one thing about this change that stands out is that networkd code exists to select the virtual router and for domain name, but this implements only the domain name portion. Is there a plan for a followup to implement the other part?

holmanb · 2026-04-22T13:59:58Z

+                return domain_name.strip()
+
+        LOG.debug(
+            "Could not obtain FQDN from NM leases. Falling back to %s",


Why is this inserted before the client rather than after?

Why is this inserted before the client rather than after?

You lost me here. Its how the debug logs are added for others like IscDHClient etc as well.

I was referring to fallback order. This adds NetworkManager before the dhcp client.

I was referring to fallback order. This adds NetworkManager before the dhcp client.

This is correct. This aligns with other dhcp clients in the function. Default client is dhcpcd but on RHEL, its network manager that primarily gives out the leases. We do not have full support for network manager as a client yet. There is a plan to implement it but won't happen anytime soon.

holmanb · 2026-04-22T14:07:20Z

+        # skip loopback
+        if dev_name == "lo":
+            continue
+        # if no device name is passed, use the first one found.


Do we know what order these will be printed in?

Do we know what order these will be printed in?

From what I have seen, its mostly active devices, then loopback and then deactivated devices. But I am not sure if this order is true for all versions of nmcli across all distributions.

ani-sinha · 2026-04-22T14:48:53Z

Thanks for the proposal. I haven't looked closely at the tests, but one thing about this change that stands out is that networkd code exists to select the virtual router and for domain name, but this implements only the domain name portion. Is there a plan for a followup to implement the other part?

I can n look into it yes. The idea is to fix all the gaps where network manager support is inadequate

) DHCP leases can be directly obtained from network manager through appropriate command to the network manager cli. Add a couple of helper functions to get the lease information from network manager. In a subsequent patch, we will use the helper function from cloud stack datasource to get the lease information from network manager. Signed-off-by: Ani Sinha <anisinha@redhat.com> Co-authored-by: Chad Smith <chad.smith@canonical.com>

Without mocking out dhcp.IscDhclient.get_newest_lease_file_from_distro, the functions on some platforms returns None. This means get_key_from_latest_lease() bails out early without calling parse_leases() to parse the lease file. Fix it. Signed-off-by: Ani Sinha <anisinha@redhat.com>

) DHCP leases can be directly obtained from network manager through appropriate command to the network manager cli. Add a couple of helper functions to get the lease information from network manager. In a subsequent patch, we will use the helper function from cloud stack datasource to get the lease information from network manager. Signed-off-by: Ani Sinha <anisinha@redhat.com> Co-authored-by: Chad Smith <chad.smith@canonical.com>

Without mocking out dhcp.IscDhclient.get_newest_lease_file_from_distro, the functions on some platforms returns None. This means get_key_from_latest_lease() bails out early without calling parse_leases() to parse the lease file. Fix it. Signed-off-by: Ani Sinha <anisinha@redhat.com>

…ses (canonical#6829) Red Hat uses network manager as the supported dhcp client. If network manager cli is available, we should try to get domain name information directly from the network manager leases before asking distro specific dhcp client (dhcpcd by default). Signed-off-by: Ani Sinha <anisinha@redhat.com> Co-authored-by: Chad Smith <chad.smith@canonical.com>

…nical#6829) Red Hat distributions uses network manager to manage DHCP leases. This change adds support for obtaining vr address information from DHCP leases maintained by network manager. Signed-off-by: Ani Sinha <anisinha@redhat.com>

ani-sinha · 2026-04-23T08:50:55Z

Thanks for the proposal. I haven't looked closely at the tests, but one thing about this change that stands out is that networkd code exists to select the virtual router and for domain name, but this implements only the domain name portion. Is there a plan for a followup to implement the other part?

I can n look into it yes. The idea is to fix all the gaps where network manager support is inadequate

I have added support for this in the 4th patch.

…nical#6829) Red Hat distributions uses network manager to manage DHCP leases. This change adds support for obtaining vr address information from DHCP leases maintained by network manager. Signed-off-by: Ani Sinha <anisinha@redhat.com>

ani-sinha · 2026-04-30T03:58:17Z

@blackboxsw ping.

blackboxsw

Looks good @ani-sinha thank you for the updates and test improvements.

One minor test nit and this will be good to merge.

holmanb

This results in ConfgObj failures due to being unable to process the content:

I don't see any test for this behavior that was previously mentioned by @blackboxsw. Was it fixed?

ani-sinha · 2026-05-05T16:16:41Z

This results in ConfgObj failures due to being unable to process the content:

I don't see any test for this behavior that was previously mentioned by @blackboxsw. Was it fixed?

Yes. Test cases were also added.

holmanb · 2026-05-05T16:22:05Z

This results in ConfgObj failures due to being unable to process the content:

I don't see any test for this behavior that was previously mentioned by @blackboxsw. Was it fixed?

Yes. Test cases were also added.

Which test covers this case?

ani-sinha · 2026-05-05T17:13:02Z

This results in ConfgObj failures due to being unable to process the content:

I don't see any test for this behavior that was previously mentioned by @blackboxsw. Was it fixed?

Yes. Test cases were also added.

Which test covers this case?

find_correct_device_firstmatch() etc. they all deal with multi connected device cases. The output is specific to a device so it does not have to parse an output that contains results from more than one interface. Hence it does not result in the exception previously we were seeing.

blackboxsw · 2026-05-05T18:33:42Z

This results in ConfgObj failures due to being unable to process the content:

I don't see any test for this behavior that was previously mentioned by @blackboxsw. Was it fixed?

Yes. Test cases were also added.

Which test covers this case?

find_correct_device_firstmatch() etc. they all deal with multi connected device cases. The output is specific to a device so it does not have to parse an output that contains results from more than one interface. Hence it does not result in the exception previously we were seeing.

@holmanb, additionally @ani-sinha changed the original logic proposed by first calling find_correct_device_nmcli to limit the device chosen to the first connected inside network_manager_load_leases which now takes a required dev positional param. That dev param now limits multiple device output from the command nmcli --fields DHCP4 device show ens4 instead of the former commands which showed all devices nmcli --fields DHCP4 device show. And again, the tests Ani added cover the correct multiple device processing of nmcli --terse devices .

blackboxsw · 2026-05-05T18:58:00Z

@ani-sinha one final miss in testing is that we now have to re-enable the previously commented mock.patch or get_vr_address with something like the following diff. Without this patch we'll see issues from tox -e py3-fast which leak subp.subp calls due to nmcli --terse device.

--- a/tests/unittests/sources/test_cloudstack.py
+++ b/tests/unittests/sources/test_cloudstack.py
@@ -744,11 +744,11 @@ class TestDataSourceCloudStackLocal:
         MOD_PATH + ".EphemeralIPNetwork",
         autospec=True,
     )
-    @mock.patch(MOD_PATH + ".net.find_fallback_nic")
-    # @mock.patch(MOD_PATH + ".get_vr_address", return_value="10.1.37.131")
+    @mock.patch(MOD_PATH + ".net.find_fallback_nic", return_value="enp0s1")
+    @mock.patch(MOD_PATH + ".get_vr_address", return_value="10.1.37.131")
     def test_local_datasource_success(
         self,
-        # m_get_vr_address,
+        m_get_vr_address,
         m_find_fallback_nic,
         m_dhcp,
         m_wait_for_mds,
@@ -762,7 +762,6 @@ class TestDataSourceCloudStackLocal:
             {}, distro, helpers.Paths({"run_dir": tmpdir})
         )
 
-        m_find_fallback_nic.return_value = "enp0s1"
         m_dhcp.return_value.__enter__.side_effect = (None,)
         m_wait_for_mds.return_value = (True,)
         m_get_userdata.return_value = "ud"

) DHCP leases can be directly obtained from network manager through appropriate command to the network manager cli. Add a couple of helper functions to get the lease information from network manager. In a subsequent patch, we will use the helper function from cloud stack datasource to get the lease information from network manager. Signed-off-by: Ani Sinha <anisinha@redhat.com> Co-authored-by: Chad Smith <chad.smith@canonical.com>

Without mocking out dhcp.IscDhclient.get_newest_lease_file_from_distro, the functions on some platforms returns None. This means get_key_from_latest_lease() bails out early without calling parse_leases() to parse the lease file. Fix it. Signed-off-by: Ani Sinha <anisinha@redhat.com>

…ses (canonical#6829) Red Hat uses network manager as the supported dhcp client. If network manager cli is available, we should try to get domain name information directly from the network manager leases before asking distro specific dhcp client (dhcpcd by default). Signed-off-by: Ani Sinha <anisinha@redhat.com> Co-authored-by: Chad Smith <chad.smith@canonical.com>

…nical#6829) Red Hat distributions uses network manager to manage DHCP leases. This change adds support for obtaining vr address information from DHCP leases maintained by network manager. Signed-off-by: Ani Sinha <anisinha@redhat.com>

ani-sinha · 2026-05-06T03:25:57Z

@ani-sinha one final miss in testing is that we now have to re-enable the previously commented mock.patch or get_vr_address with something like the following diff. Without this patch we'll see issues from tox -e py3-fast which leak subp.subp calls due to nmcli --terse device.

--- a/tests/unittests/sources/test_cloudstack.py
+++ b/tests/unittests/sources/test_cloudstack.py
@@ -744,11 +744,11 @@ class TestDataSourceCloudStackLocal:
         MOD_PATH + ".EphemeralIPNetwork",
         autospec=True,
     )
-    @mock.patch(MOD_PATH + ".net.find_fallback_nic")
-    # @mock.patch(MOD_PATH + ".get_vr_address", return_value="10.1.37.131")
+    @mock.patch(MOD_PATH + ".net.find_fallback_nic", return_value="enp0s1")
+    @mock.patch(MOD_PATH + ".get_vr_address", return_value="10.1.37.131")
     def test_local_datasource_success(
         self,
-        # m_get_vr_address,
+        m_get_vr_address,
         m_find_fallback_nic,
         m_dhcp,
         m_wait_for_mds,
@@ -762,7 +762,6 @@ class TestDataSourceCloudStackLocal:
             {}, distro, helpers.Paths({"run_dir": tmpdir})
         )
 
-        m_find_fallback_nic.return_value = "enp0s1"
         m_dhcp.return_value.__enter__.side_effect = (None,)
         m_wait_for_mds.return_value = (True,)
         m_get_userdata.return_value = "ud"

Fixed.

ani-sinha · 2026-05-06T03:37:55Z

For alternate distros, the failure seems to be in test infra

  File "/usr/lib/python3.14/site-packages/tox/run.py", line 20, in run
    result = main(sys.argv[1:] if args is None else args)
  File "/usr/lib/python3.14/site-packages/tox/run.py", line 39, in main
    state = setup_state(args)
  File "/usr/lib/python3.14/site-packages/tox/run.py", line 53, in setup_state
    options = get_options(*args)
  File "/usr/lib/python3.14/site-packages/tox/config/cli/parse.py", line 38, in get_options
    guess_verbosity, log_handler, source = _get_base(args)
                                           ~~~~~~~~~^^^^^^
  File "/usr/lib/python3.14/site-packages/tox/config/cli/parse.py", line 58, in _get_base
    from tox.plugin.manager import MANAGER  # load the plugin system right after we set up report  # noqa: PLC0415
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.14/site-packages/tox/plugin/manager.py", line 11, in <module>
    from tox.session.cmd.run import parallel, sequential
  File "/usr/lib/python3.14/site-packages/tox/session/cmd/run/parallel.py", line 14, in <module>
    from .common import env_run_create_flags, execute
  File "/usr/lib/python3.14/site-packages/tox/session/cmd/run/common.py", line 19, in <module>
    from tox.session.cmd.run.single import ToxEnvRunResult, run_one
  File "/usr/lib/python3.14/site-packages/tox/session/cmd/run/single.py", line 11, in <module>
    from tox.tox_env.python.virtual_env.package.pyproject import ToxBackendFailed
  File "/usr/lib/python3.14/site-packages/tox/tox_env/python/virtual_env/package/pyproject.py", line 28, in <module>
    from tox.tox_env.python.package import (
    ...<5 lines>...
    )
  File "/usr/lib/python3.14/site-packages/tox/tox_env/python/package.py", line 13, in <module>
    from .api import NoInterpreter, Python
  File "/usr/lib/python3.14/site-packages/tox/tox_env/python/api.py", line 14, in <module>
    from virtualenv.discovery.py_spec import PythonSpec
  File "/usr/lib/python3.14/site-packages/virtualenv/discovery/py_spec.py", line 5, in <module>
    from python_discovery import PythonSpec
ModuleNotFoundError: No module named 'python_discovery'

For the integration test, not sure why this ssh-import-id is failing

E           AssertionError: 
E           Found unexpected errors: ('ssh_import_id', ProcessExecutionError("Unexpected error while running command.\nCommand: ['sudo', '--preserve-env=https_proxy', '-Hu', 'ubuntu', 'ssh-import-id', 'gh:blackboxsw']\nExit code: 1\nReason: -\nStdout: -\nStderr: -"))

) DHCP leases can be directly obtained from network manager through appropriate command to the network manager cli. Add a couple of helper functions to get the lease information from network manager. In a subsequent patch, we will use the helper function from cloud stack datasource to get the lease information from network manager. Signed-off-by: Ani Sinha <anisinha@redhat.com> Co-authored-by: Chad Smith <chad.smith@canonical.com>

Without mocking out dhcp.IscDhclient.get_newest_lease_file_from_distro, the functions on some platforms returns None. This means get_key_from_latest_lease() bails out early without calling parse_leases() to parse the lease file. Fix it. Signed-off-by: Ani Sinha <anisinha@redhat.com>

…ses (canonical#6829) Red Hat uses network manager as the supported dhcp client. If network manager cli is available, we should try to get domain name information directly from the network manager leases before asking distro specific dhcp client (dhcpcd by default). Signed-off-by: Ani Sinha <anisinha@redhat.com> Co-authored-by: Chad Smith <chad.smith@canonical.com>

…nical#6829) Red Hat distributions uses network manager to manage DHCP leases. This change adds support for obtaining vr address information from DHCP leases maintained by network manager. Signed-off-by: Ani Sinha <anisinha@redhat.com>

ani-sinha mentioned this pull request Apr 7, 2026

test: fix test_get_domainname_isc_dhclient mock leak #6824

Closed

2 tasks

ani-sinha force-pushed the parse_nm_leases branch from d9e4324 to 0056499 Compare April 7, 2026 05:49

blackboxsw requested changes Apr 14, 2026

View reviewed changes

blackboxsw requested a review from Copilot April 14, 2026 18:37

Copilot started reviewing on behalf of blackboxsw April 14, 2026 18:38 View session

blackboxsw self-assigned this Apr 14, 2026

Copilot AI reviewed Apr 14, 2026

View reviewed changes

Comment thread cloudinit/sources/DataSourceCloudStack.py

Comment thread cloudinit/net/dhcp.py

Comment thread tests/unittests/sources/test_cloudstack.py Outdated

ani-sinha force-pushed the parse_nm_leases branch from b95f3bd to 96a8a02 Compare April 17, 2026 08:33

ani-sinha requested a review from blackboxsw April 17, 2026 08:39

blackboxsw requested changes Apr 21, 2026

View reviewed changes

Comment thread cloudinit/net/dhcp.py Outdated

Comment thread cloudinit/net/dhcp.py Outdated

Comment thread tests/unittests/sources/test_cloudstack.py

Comment thread tests/unittests/net/test_dhcp.py

ani-sinha force-pushed the parse_nm_leases branch from 96a8a02 to f7a881b Compare April 22, 2026 11:35

ani-sinha force-pushed the parse_nm_leases branch from f7a881b to c7dc84d Compare April 22, 2026 12:12

ani-sinha requested a review from blackboxsw April 22, 2026 13:22

holmanb requested changes Apr 22, 2026

View reviewed changes

ani-sinha force-pushed the parse_nm_leases branch from e0451af to ae8aa9e Compare April 23, 2026 08:50

ani-sinha force-pushed the parse_nm_leases branch from ae8aa9e to 595624b Compare April 23, 2026 10:29

ani-sinha changed the title ~~fix(cloudstack): get domain name information from network manager leases~~ fix(cloudstack): get domain name and vr information from network manager leases Apr 23, 2026

blackboxsw requested changes May 5, 2026

View reviewed changes

Comment thread tests/unittests/net/test_dhcp.py Outdated

holmanb requested changes May 5, 2026

View reviewed changes

Comment thread cloudinit/net/dhcp.py Outdated

ani-sinha force-pushed the parse_nm_leases branch from 595624b to 454055d Compare May 6, 2026 03:24

ani-sinha requested a review from blackboxsw May 6, 2026 03:41

ani-sinha and others added 4 commits May 7, 2026 08:49

ani-sinha force-pushed the parse_nm_leases branch from 454055d to ee55b6b Compare May 7, 2026 03:20

Conversation

ani-sinha commented Apr 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Proposed Commit Message

Merge type

Uh oh!

ani-sinha commented Apr 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

blackboxsw left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

blackboxsw Apr 14, 2026

Choose a reason for hiding this comment

Uh oh!

blackboxsw Apr 14, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

blackboxsw left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

holmanb left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

holmanb Apr 22, 2026

Choose a reason for hiding this comment

Uh oh!

ani-sinha Apr 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

holmanb Apr 23, 2026

Choose a reason for hiding this comment

Uh oh!

ani-sinha Apr 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

holmanb Apr 22, 2026

Choose a reason for hiding this comment

Uh oh!

ani-sinha Apr 23, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

ani-sinha commented Apr 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ani-sinha commented Apr 23, 2026

Uh oh!

ani-sinha commented Apr 30, 2026

Uh oh!

blackboxsw left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

holmanb left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ani-sinha commented Apr 7, 2026 •

edited

Loading

ani-sinha commented Apr 8, 2026 •

edited

Loading

ani-sinha Apr 23, 2026 •

edited

Loading

ani-sinha Apr 24, 2026 •

edited

Loading

ani-sinha commented Apr 22, 2026 •

edited

Loading

blackboxsw commented May 5, 2026 •

edited

Loading

ani-sinha commented May 6, 2026 •

edited

Loading