build-iso still pulls from quay.io

[kkaempf]

elemental build-iso should run offline when the base image is available in the local image cache. Currently it still pulls data from quay.io (grub2 files apparently).

Not sure why this happens. Either elemental looks at the wrong places in the image (or not at all :wink:)

Everything needed for ISO building should be provided by node-image and builder-image.

[Itxaka]

Im not sure this is possible without changes to elemental. @davidcassany this should be possible to override via config file or env var?

I know that env vars are currently off for the ISO config and not sure if the config file accepts the iso.UEFI var....

[davidcassany]

All right, the bare minimum elemental build-iso requires is a set of three images (or local folders or luet packages). See the manifest.yaml file below:

iso:
  uefi:
    - channel:live/grub2-efi-image
  image:
    - channel:live/grub2
    - channel:live/grub2-efi-image
  label: "COS_LIVE"

repositories:
  - uri: quay.io/costoolkit/releases-green

IIRC something like that are elemental build-iso defaults if no manifest.yaml (yes the repository is no even teal...). So these live/grub2-efi-image and live/grub2 are pulled from the green quay repository. Note the respository is configurable with the manifest.yaml file as shown above and the uefi and image packages list can be a dir:, docker: or channel:. So for offline builds you either have all this data in different folders, docker images or luet packages. Folders are obviously working off line, then luet packages and docker images can also be instructed to be offline, but it is not straight forward because you have to prepare the data, for instance elemental build-iso --local docker:my/image:mytag will attempt to pull all docker images from the local docker daemon. In a similar fashion you could instruct the channel to come from a local luet respository.

So offlione builds are certainly possible, but requires some love to prepare the data. Also note that live/grub2 and live/grub2-efi-image I doubt they have ever been built in OBS and I doubt they are part of the firmware files binares...

[Itxaka]

shouldnt the rootfs(registry.opensuse.org/isv/rancher/elemental/teal52/15.3/rancher/elemental-node-image/5.2:latest) already contain all the files needed for this? like the grub2 package contains the files under /boot and grub2-efi the ones under /EFI

So maybe something like this could work:

iso:
  uefi:
    - dir:/rootfs/EFI
  image:
    - dir:/rootfs/boot

[kkaempf]

What is in live/grub2-efi-image and live/grub2 that wouldn't be available in SLE Micro for Rancher ? 🤔

[davidcassany]

What is in live/grub2-efi-image and live/grub2 that wouldn't be available in SLE Micro for Rancher ? thinking

live/grub2 contains the grub configuration files for the live boot and live/grub2-efi-image files just contains the files we include into the EFI image, this is a convenience package in the sense it abstracts elemental build-iso of having to find/cretae these files from the root-tree as context. build-iso is dumb regarding EFI artifacts it just includes the given assets to the EFI image.

[kkaempf]

That means that we should be able to provide an "offline build" script for inclusion into Rancher Manager (callable from the UI) later.

[Itxaka]

so configuring this via manifest.yaml works as expected but.... node-image does NOT provide the required files.

No EFI dir on it.

Grub packages are available under /usr/share/grub2/

If we were to generate the EFI dir with all the proper files...we may as well drop teh elemental-toolkit altogether as there is some caveats in there, some templates that we run, etc... looks ugly IMO

[kkaempf]

so configuring this via manifest.yaml works as expected but.... node-image does NOT provide the required files.

No EFI dir on it.

That's just a mkdir away :wink:

Grub packages are available under /usr/share/grub2/

And they should be complete. 🤞🏻

If we were to generate the EFI dir with all the proper files

We have to since they're on a separate (FAT-formatted) partition.

...we may as well drop the elemental-toolkit altogether

Yes !? 🤔

as there is some caveats in there, some templates that we run, etc... looks ugly IMO

Any other options to achieve offline builds (and not duplicating binaries that are already part of the image, like grub2-x86_64-efi) ?

[Itxaka]

Not that I can think of, we may need to recreate what we do on the elemental-toolkit as a package on OBS :/

[Itxaka]

moved this into elemental as elemental-cli already provides this.

Ok this is what I thougth about.

Because you can set the dirs in the manifest.yaml file we only need the proper artifacts in the TOOL IMAGE, as thats the one that its used to build the iso. So lets have a package that ships the artifacts that we used to have from the toolkit repos: https://build.opensuse.org/package/show/home:itxaka/elemental-efi And then on offline build or whatever you want to call it, we can either add on the fly a manifest.yaml file with those dirs so it doesnt need to go to the internet to pick anything, or we can even add flags to the build-iso file to provide those dirs on the command line as flags.

Still, having the build-iso callable from rancher manager is...weird. Like wht is the usecase there, do everything via the UI? Who does that? How would that work? Where is the iso created and stored? Where are the images pulled to? and a hunderd questions more....

As usual with elemental features, this has no use case nor its urgent nor it has a clear workflow or requirements, so IMHO this is low prio, incomplete request. Why not wait until we have a real request for something like this and then discuss if its feasible, how would it work and so on? i.e. plan the feature?

[kkaempf]

Still, having the build-iso callable from rancher manager is...weird. Like what is the usecase there, do everything via the UI?

Yes, exactly this, do everything via the UI.

Who does that?

Every single Rancher customer. :wink: Managing k8s clusters with a UI is why Rancher Manager exists.

How would that work?

You select a machineRegistration and have a "download ISO" button.

Where is the iso created and stored?

It's created by elemental-operator and downloaded to the user's system.

[Itxaka]

You select a machineRegistration and have a "download ISO" button.

Then this should be moved to the operator then :D

IMO this requires a clear workflow in how it would work and the steps required. Also, this would require an UI implementation, Im not sure we know how to do so so it may involve more rancher folks on the UI side.

[davidcassany]

Some comments regarding the above discussion:

• creating ISOs from the elemental-operator is an unrelated topic, an interesting feature though, but requires a proper design as this is not alight task that can be embedded anywhere. This deserves its own epic and discussion.
• The real problem is that the bootloader artifacts from the ISO are downloaded from quay.io. We need to provide them from OBS or consume them from the base image. Few rough ideas on this topic:
  • package everything as RPMs
  • add logic in elemental build-iso and consume everything from the base image. This adds constraints to the base image to include requires packages and it is damn hard to be distro agnostic. See rancher/elemental-cli#316
  • Explore building container images with the required content in OBS (with kiwi and some scripting it should be possible). See #316
  • Add Luet packaging in OBS (it will be a damn huge epic including autobuild team into the picture...)

[davidcassany]

Done by rancher/elemental-cli#316 and some follow ups to adapt rancher/elemental. Opening a new card to ensure the code is also adapted in rancher/elemental-toolkit.