many: drop the workload.Workload type entirely

[mvo5]

Note that this is only a first step, we can do more here
(and probably should) but for now this is a really
low-hanging fruit. It ties into the whole discussion
of unifying workload/oscustomization/imageconfig
and seems like a step in the right direction to me.

But I'm open for discussion of course, maybe it
should be part of a bigger refactor, idk.

---

many: drop the workload.Workload type entirely

Workloads are no longer used in the images library and there
is no appetite to use them. So this commit removes the last
use of them: the workload.Custom{} that was used to pass
image type configuration to the images functions.

The workload.Custom is replaces with the regular
manifest.OSCustomizations that already contains (almost)
anything that is needed. So instead of having two concepts
to configure the image we consolidate it to one.

---

many: rename workload usage to imgTypeCustomizations

Now that the workload concept is removed and everything the
initial image type configuration is done via OSCustomization
we need to rename "workload" as it will be confusing without
the historic context (and arguably it was always a bit
confusing).

The new name needs to capture that the OSCustomizations
applied here come from the initial imagetype. I picked
imgTypeCustomizations as it seems to capture best
what this is doing. But its long and I'm open for more
ideas, I initially used seed as its short but its
probably too abstract and it captures the concept poorly.

Its also unclear how long-lived this name will be,
ideally it all will be merged into a single OSCustomizations
variable inside the various images but that needs to
happen in followups or the churn is too big.

[supakeen]

Sure, though I feel this could have dropped the idiom entirely and just apply them to img.OSCustomizations directly. Let's do that as a follow up since you already mentioned it.

[mvo5]

Sure, though I feel this could have dropped the idiom entirely and just apply them to img.OSCustomizations directly. Let's do that as a follow up since you already mentioned it.

I agree, I would like to merge it into a single thing. One reason why its not currently is https://github.com/osbuild/images/blob/main/pkg/manifest/os.go#L338 - the workload packages are resolved in their own transaction so we need something new in OSCustomizations (ImageTypePackages?). I will look into it.

[thozza]

I agree, I would like to merge it into a single thing. One reason why its not currently is https://github.com/osbuild/images/blob/main/pkg/manifest/os.go#L338 - the workload packages are resolved in their own transaction so we need something new in OSCustomizations (ImageTypePackages?). I will look into it.

These are now effectively the "custom packages" requested by the user in the Blueprint. These are not related to the Image Type. Something along the lines of "custom packages", "additional packages", "user packages", or "blueprint packages" would, in my opinion, be more descriptive of what the package set represents.

[thozza]

Thanks for doing this first step.

All in all, I think that this is a reasonable first step. However, there are some parts that are IMO not accurate (mainly comments or variable names). But more importantly, I think that we should get rid of imgTypeCustomizations completely, since it is duplicating existing functionality. In my opinion, the OSCustomizations struct should contain the "final" image type customizations after processing user-provided input (mainly extra repos and the Blueprint). Keeping imgTypeCustomizations overlaps with this functionality and makes the code more complex.

I'm OK with merging this as is and iterating on the implementation.

[thozza]

In practice, we should not need to pass workload at all to any ImageKind generator. The custom workload used to carry user-specified packages, custom repos, and systemd unit config. Besides custom repos, all of these are already obtainable from the Blueprint, which is already passed as an argument to the generator.

[thozza]

This is incorrect AFAICT. BaseModules aims to replace Workload.GetEnabledModules(), but enabling a module does not necessarily mean installing it. It must still be specified in the package list to be installed. Enabling modules means "making the module stream available for installation", so it is more like enabling a repository.

[mvo5]

Fwiw, I agree to all points, working on a followup that will be a bit more involved (unfortunately)

[mvo5]

[..]

All in all, I think that this is a reasonable first step. However, there are some parts that are IMO not accurate (mainly comments or variable names). But more importantly, I think that we should get rid of imgTypeCustomizations completely, since it is duplicating existing functionality. In my opinion, the OSCustomizations struct should contain the "final" image type customizations after processing user-provided input (mainly extra repos and the Blueprint). Keeping imgTypeCustomizations overlaps with this functionality and makes the code more complex.
[..]

Thanks for the excellent feedback. I was indeed meant as a first step and I opened a followup now (and the naming was indeed pretty bad, sorry for that!), c.f. #1780