cloud-init team mailing list archive
-
cloud-init team
-
Mailing list archive
-
Message #00468
Re: The "maybe trap"
> On aarch64 we are falling into the DS_MAYBE from [1] trap. While I do
> not see any particular reason not to have a
>
> aarch64) :;;
>
> case to make this deterministic on aarch64 it does ultimately only work
> as long as what we are doing sticks to those architectures.
>
> As such I'd really like to get a better understanding why DS_MAYBE
> exists. The way I see it it let's ds-identify kind of bail out and pass
> the responsibility of identifying a data source to cloud-init by
> enabling cloud-init.target.
When this was added, OpenStack was incapable of identifying itself on
non-x86 architectures[1]. The workaround, as you found, was to assume
Openstack is a possible datasource, and pass responsibility to cloud-init.
This unfortunately means that, yes, openstack is assumed on all non-x86
architectures. DMI support on aarch64 has since made its way upstream[2],
however I don't think that anyone has gotten around to verifying whether
OpenStack correctly passes this information through Libvirt.
It looks like Libvirt is aware of aarch64 support for SMBIOS[3], but it doesn't
seem like nova is aware of this yet[4]. I don't know how to go about getting
this fixed, but I naively hope that the attached patch might be a step in the
right direction. Nova's development model / platform isn't intuitive to me,
but if someone knows the right folks to ask about this fix, that would be
helpful towards resolving the issue that you've raised.
Cheers,
Brett
[1] https://bugs.launchpad.net/cloud-init/+bug/1663304
[2] https://bugs.launchpad.net/bugs/1662345
[3] https://github.com/libvirt/libvirt/commit/ec6ce6363a78aaaf6e3aa4c0e2d683d7d0cce183
[4] https://github.com/openstack/nova/blob/db9351ab5191e058994209464aa7fc2b2fa34561/nova/virt/libvirt/driver.py#L6856
On Wed, Mar 13, 2024 at 2:17 PM Robert Schweikert <rjschwei@xxxxxxxx> wrote:
>
> Hi,
>
> On aarch64 we are falling into the DS_MAYBE from [1] trap. While I do
> not see any particular reason not to have a
>
> aarch64) :;;
>
> case to make this deterministic on aarch64 it does ultimately only work
> as long as what we are doing sticks to those architectures.
>
> As such I'd really like to get a better understanding why DS_MAYBE
> exists. The way I see it it let's ds-identify kind of bail out and pass
> the responsibility of identifying a data source to cloud-init by
> enabling cloud-init.target.
>
> And this is where we are tripping over because we check if cloud-init
> got enabled and if it did we skip other stuff. But in this case we need
> other stuff to happen.
>
> So instead of checking on whether or not cloud-init got enabled would it
> make more sense to check what is in /run/cloud-init/cloud-id?
>
> If it contains "none" do our special stuff?
>
> Thanks,
> Robert
>
> [1]
> https://github.com/canonical/cloud-init/blob/main/tools/ds-identify#L1368
>
> --
> Robert Schweikert MAY THE SOURCE BE WITH YOU
> Distinguished Engineer LINUX
> rjschwei@xxxxxxxx
> IRC: robjo
>
> --
> Mailing list: https://launchpad.net/~cloud-init
> Post to : cloud-init@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~cloud-init
> More help : https://help.launchpad.net/ListHelp
From bafa392f935b28300fc783ed9c168eb5fab3a084 Mon Sep 17 00:00:00 2001
From: Brett Holman <bholman.devel@xxxxxxxxx>
Date: Wed, 13 Mar 2024 17:50:05 -0600
Subject: [PATCH] Add pass through DMI identifying information to aarch64
---
nova/virt/libvirt/driver.py | 2 ++
1 file changed, 2 insertions(+)
diff --git a/nova/virt/libvirt/driver.py b/nova/virt/libvirt/driver.py
index 88969306a3..a6508022a0 100644
--- a/nova/virt/libvirt/driver.py
+++ b/nova/virt/libvirt/driver.py
@@ -6865,6 +6865,8 @@ class LibvirtDriver(driver.ComputeDriver):
hw_firmware_type = image_meta.properties.get('hw_firmware_type')
if arch == fields.Architecture.AARCH64:
+ guest.sysinfo = self._get_guest_config_sysinfo(instance)
+ guest.os_smbios = vconfig.LibvirtConfigGuestSMBIOS()
if not hw_firmware_type:
hw_firmware_type = fields.FirmwareType.UEFI
--
2.43.0
Follow ups
References