This includes the two commits from #1519 so just review the last two commits here. I'll rebase once 1519 merges.

I think we should make the detection action explicit. Having automatic behaviour that fills in the blanks when an option is omitted is generally avoided as a design decision in osbuild. I expanded a bit on this here: #1475 (comment)

What this means practically is that whenever possible we assume that the tool that is generating the manifest has all the information about the sources it's going to use. So, as an example, osbuild-composer or osbuild-mpp resolve packages, find the version of the kernel that's going to be installed, and that is used as an option for bootloader configurations etc.

In this case, I understand the convenience of reading the tree to get the info from the source ostree commit/container that's already been deployed. But even in that case, I think the behaviour of the stage should be a set on the stage options. It makes it much easier to predict what a stage will do without needing to trace the pipeline before it and it puts the decision on the manifest generator to say "there is only one deployment and I know this wont fail".
Removing the options completely makes it impossible to run the bootupd stage in a situation where there are multiple deployments. I wont try to predict valid (or even invalid) situations where that might happen, but in my experience these are the kinds of decisions that end up coming around and making things "impossible" in new situations.

So all that said, my solution would be: keep the deployment options in the stage but also add an option that tells the stage to read/sniff the deployment from the tree. So the stage options for bootupd for example would be a oneOf of the following two objects:

"deployment": {
  "osname": ...,
  "ref": ...
  "serial": ... (default 0)
}

or

"detect-deployment": true (default false)

Pinging others for thoughts: @thozza @ondrejbudai @mvo5 @supakeen

I'd call it default-deployment: true or so. There is actually work on using multiple stateroots ("osname") in OCP today; but not in disk images generated by default.

I think if there are multiple, we would operate on the default, not that we'd error out.

💯 to what @achilleas-k wrote, specifically that the we try to not make osbuild stages too smart and expect the tool that generates the osbuild manifest to make all choices explicit by specifying them in the osbuild stage options.

On top of what @achilleas-k wrote, I would mention a probably rare situation when the smartness of a stage may hide a subtle bug in the tool generating the manifest by producing a manifest which will successfully build the image, but with unexpected result.

So the concensus is something like OneOf:

"deployment": {
  "osname": ...,
  "ref": ...
  "serial": ... (default 0)
}

or

"default-deployment": true (default false)

If we have agreement I can look into updating things here.

So the concensus is something like OneOf:

"deployment": {
  "osname": ...,
  "ref": ...
  "serial": ... (default 0)
}

or

"default-deployment": true (default false)

If we have agreement I can look into updating things here.

Yes. I think we can all agree on that.

obsoleted by #1553