Are you seeing cloud-id misbehave when this happens? It's been a long time since I've looked at cloud-id, so I'm not sure how it works with ds-identify.
Aside: after digging into it to respond to your previous email, I started a conversation about getting improved DMI support with some openstack folks; with any luck this situation might improve in the next cycle or two. I also tossed a patch [1] at the libvirt mailing list to try to get DMI support on some other arches (risc-v and mips) too so that openstack can pass through DMI on them as well. I think it's waiting on more reviews at the moment, but I'm not well versed in the mailing list contribution process. If you happen to know anyone that might be interested/qualified to review it on the list that would also be helpful. [1] https://lists.libvirt.org/archives/list/[email protected]/message/G6GPDHYL7CT7MFRECAPL7ZDSXOWQUABG/ Cheers, Brett On Thu, Mar 14, 2024, 05:19 Robert Schweikert <[email protected]> wrote: > Hi, > > On 3/13/24 19:59, Brett Holman wrote: > >> 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. > > > > Thanks for confirmation. When the responsibility for seraching for a > data source is passed from ds-identify to cloud-init it is my > understanding that cloud-init will write the cloud-id file, which is > symlinked form /run/cloud-init/cloud-id. The file will contain "none" if > an only if no data source if found, at least that is what I think based > on looking through the data sources code. > > This means, we could trigger of this to run a different setup process to > isolate us from the format of the status.json file. > > Is this correct? > > Thanks, > Robert > > > > > 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 <[email protected]> > 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 > >> [email protected] > >> IRC: robjo > >> > >> -- > >> Mailing list: https://launchpad.net/~cloud-init > >> Post to : [email protected] > >> Unsubscribe : https://launchpad.net/~cloud-init > >> More help : https://help.launchpad.net/ListHelp > > -- > Robert Schweikert MAY THE SOURCE BE WITH YOU > Distinguished Engineer LINUX > [email protected] > IRC: robjo >
-- Mailing list: https://launchpad.net/~cloud-init Post to : [email protected] Unsubscribe : https://launchpad.net/~cloud-init More help : https://help.launchpad.net/ListHelp
