kairos-io / kairos

:penguin: The immutable Linux meta-distribution for edge Kubernetes.
https://kairos.io
Apache License 2.0
1.05k stars 91 forks source link

Don't scan the whole `/run/initramfs/live/` for configs #2064

Open jimmykarily opened 8 months ago

jimmykarily commented 8 months ago

./kairos-agent upgrade produces lots of warnings like:

warning: skipping /run/initramfs/live/EFI/BOOT/MokManager.efi (extension).
warning: skipping /run/initramfs/live/EFI/BOOT/bootx64.efi (extension).
warning: skipping /run/initramfs/live/EFI/BOOT/grub.cfg (extension).
warning: skipping /run/initramfs/live/EFI/BOOT/grub.efi (extension).
warning: skipping /run/initramfs/live/boot/arm64/loader/grub2/fonts/unicode.pf2 
(extension).
warning: skipping /run/initramfs/live/boot/grub2/grub.cfg (extension).
warning: skipping /run/initramfs/live/boot/grub2/i386-pc/acpi.mod (extension).
warning: skipping /run/initramfs/live/boot/grub2/i386-pc/adler32.mod (extension)
...

because we scan /run /initramfs/live for config files: https://github.com/kairos-io/kairos-agent/blob/e6b3e5092e5f566f8f266108e91eb86d3c6a371d/main.go#L36

This was done so that people can bake in a config in the iso but that directory includes many more files that are not configs.

Either we drop that path completely (if we don't support that feature anymore) or we change to a more specific path which is dedicated to configs.

Itxaka commented 8 months ago

Maybe its not only upgrade but the other scans have the NoLogs ?

mauromorales commented 8 months ago

Could this be dropped now that we use AuroraBoot? Or is anyone relying on it? It doesn't seem to be a documented feature, so maybe it's safe to remove.

Itxaka commented 3 months ago

This cant be really done because we agreed to scan that dir as it can help when bundling the config file in the livecd directly.

But upgrade should probably use Nologs when scanning the dirs and only fail if there is an error

jimmykarily commented 3 months ago

Why not use a directory dedicated to actual cloud-configs like the description suggests? Then there is no reason to skip logs, since any file that is skipped in a directory dedicated for files that should be respected...well that's something we should log.

Itxaka commented 3 months ago

becuase we would break backwards compatibility I think, its been assumed since the start that dir as a source for cdrom based injected cc, so we cannot easily move away from that. But we can hider those warning which should be ok as there is no point in making that much noise for something expected?

Upgrade should not print a thousands warning in any case, unless debug is specified which is used for more info. This is the same as someone doing a run-stage against a systemd dir. Those warnings do not really help anything and we have not stated that your cc files should be in a dir dedicated to them, they can be anywhere. So we backed ourselves into a corner here :D

jimmykarily commented 3 months ago

The only problem is that sometimes people forget to put the header at the top of the file or things like that and the file they expected to be run was actually skipped.

Newer versions of Kairos will only be shipped a newer ISO images. Whoever is creating isos with bundled configs could make sure they put them in the new location. I don't see why we are forced to use that dir forever. Alternatively, we could:

Itxaka commented 3 months ago

Im wondering about the tooling in place to bundle those files into existing isos. i.e. your product could be just download the kairos iso and injecting the file, plain and simple. No matter if we ship a newer iso file or version, the tooling in place will still do the same :D

The header thing seems more like an error or warning, rather than the extension one.

IMHO:

So maybe its more about adjusting what the collector considers as a warning?

jimmykarily commented 3 months ago

This is a good middle ground. I would still prefer to avoid parsing a thousand different files to discover only those that look like cloud config files. But given the main point was to not show irrelevant warnings, then I'm fine with your suggestion.

Itxaka commented 3 months ago

This is a good middle ground. I would still prefer to avoid parsing a thousand different files to discover only those that look like cloud config files. But given the main point was to not show irrelevant warnings, then I'm fine with your suggestion.

we dont parse those no? We skip them based on the extension, so it should be pretty "free" lets say xD

We could still move it away from there and support both things meanwhile, a new folder at the root of the iso called configs or something and the old one...but we may run into issues with duplication (like we dont have those still lol)