cloud-init team mailing list archive

[Robert Schweikert <rjschwei@xxxxxxxx>]

Hi,

On 4/1/24 22:30, Brett Holman wrote:
> 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/

Thanks. I have shared the patch with our virtualization team asking for 
help to get it moving upstream.

Later,
Robert

> 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

--
Robert Schweikert                   MAY THE SOURCE BE WITH YOU
Distinguished Engineer                       LINUX
rjschwei@xxxxxxxx
IRC: robjo