cloud-init team mailing list archive

[Brett Holman <brett.holman@xxxxxxxxxxxxx>]

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/devel@xxxxxxxxxxxxxxxxx/message/G6GPDHYL7CT7MFRECAPL7ZDSXOWQUABG/

Cheers,
Brett

On Thu, Mar 14, 2024, 05:19 Robert Schweikert <rjschwei@xxxxxxxx> 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 <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
>
> --
> Robert Schweikert                   MAY THE SOURCE BE WITH YOU
> Distinguished Engineer                       LINUX
> rjschwei@xxxxxxxx
> IRC: robjo
>