Nvidia Bluefield ignition provider

[Okoyl]

nvidiabluefield is an ignition provider for Nvidia BlueField DPUs.

It uses the bootfifo device provided by the mlxbf-bootctl kernel module to pull the ignition.

Previous discussion is at issue #2148

[gemini-code-assist]

Code Review

This pull request introduces a new Ignition provider for Nvidia BlueField DPUs. The provider reads the Ignition config from the bootfifo device. The implementation is straightforward and correct. I've made a couple of suggestions to improve code style and maintainability: one regarding Go's idiomatic error handling, and another about package naming conventions for consistency with other providers in the project.

[dustymabe]

CI is reporting:

Undocumented platform ID: nvidiabluefield

which I think wants you to update https://github.com/coreos/ignition/blob/main/docs/supported-platforms.md

[dustymabe]

I'm testing this now. Can you squash all commits down into 1?

[Okoyl]

All of the previous commits are now squashed into one :)

[dustymabe]

I hit trouble here because the mlxbf_bootctl kernel module wasn't loaded. I think we need to get it into the initramfs with something like

ignition/dracut/30ignition/module-setup.sh

Line 117 in c43db71

instmods -c vsock

and then maybe conditionally load it here like

ignition/internal/providers/qemu/qemu_fwcfg.go

Lines 53 to 56 in c43db71

	// load qemu_fw_cfg module
	if _, err = f.Logger.LogCmd(exec.Command(distro.ModprobeCmd(), "qemu_fw_cfg"), "loading QEMU firmware config module"); err != nil {
	return
	}

[Okoyl]

I added the dracut generation step and it worked immediately on an RHCOS pullspec image, even without the modprobe section. I included the modprobe part afterward just to be safe.

[dustymabe]

I think typically underscores are used here:

Suggested change

	instmods -c mlxbf-bootctl
	instmods -c mlxbf_bootctl

[dustymabe]

also, are we sure this won't apply to x86_64 at some point?

[Okoyl]

It’ll likely stay aarch64 for the foreseeable future, given that current BlueField models are based on ARM SoCs.
It seems like this kernel module is not built on x86 at the major distros.

[dustymabe]

Can you update the release notes with an entry for this new platform?

https://github.com/coreos/ignition/blob/main/docs/release-notes.md

[prestist]

From my perspective the changes make sense and are conforming to my expectation for adding this platform.

LGTM, thank you all for working through this.

My only nit is the commit message.

I would prefer it to look more like "providers/nvidiabluefield: add initial support" but not a blocker.

[dustymabe]

I tested this in RHCOS by running a version of the make_bfb.sh with:

printf "systemd.mask=systemd-udev-trigger.service console=hvc0 initrd=initramfs permissive=1 ignition.firstboot ignition.platform.id=nvidiabluefield systemd.journald.forward_to_console=1" > "$boot_args2"

and providing an Ignition config like:

variant: fcos
version: 1.6.0
storage:
  files:
    - path: /etc/coreos/installer.d/install.yaml 
      contents:
        inline: |
          ignition-file: /var/lib/config.ign
          platform: metal
          console: [hvc0]
          append-karg: [systemd.mask=systemd-vconsole-setup.service, systemd.mask=systemd-udev-trigger.service]
          offline: true
          dest-device: /dev/nvme0n1
    - path: /var/lib/config.ign
      contents:
        inline: |
          {"ignition":{"version":"3.5.0"},"kernelArguments":{"shouldExist":["systemd.mask=systemd-udev-trigger.service","console=hvc0"]},"systemd":{"units":[{"dropins":[{"contents":"[Service]\n# Override Execstart in main unit\nExecStart=\n# Add new Execstart with `-` prefix to ignore failure\nExecStart=-/usr/sbin/agetty --autologin core --noclear %I $TERM\nTTYVTDisallocate=no\n","name":"autologin-core.conf"}],"name":"[email protected]"}]}}

Basically this is the Ignition config for the install boot that drops down an installer config and then also the Ignition for the first boot delivered to /var/lib/config.ign.

Here's the outdated make_bfb.sh

[dustymabe]

LGTM