cloud-init team mailing list archive

[Robert Schweikert <rjschwei@xxxxxxxx>]

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