I think this is getting written up to the enhancement on installer + manifests gen changes. This is mostly done, so will be updated once the enhancement is. Below is a best attempt at articulating it.

https://docs.google.com/document/d/1Wtu33-LyhTbJRBvZMDE8aZcWjXN-oXzEDiDAgxgey-0/edit?tab=t.0 

Why

• We need to be able to know which versions of manifests are deployed at a given time, baking them into images allows us to do so.
• Currently we use transport configmaps +  CVO, which doesn't give us this ability

Steps

• Update manifests-gen to produce a payload that can be baked into an image
  • We produce a 'profile', which is a collection of a metadata.yaml and a bundle of manifests (manifests.yaml). Mechanics described in more detail in 1918
  • We can have multiple profiles per operand. This is to (in future) allow for feature-gating certain manifests, or multiple (potentially layered) sets of manifests per operand.
• Update the CAPI installer to support both this new image/ profile manifests flow, as well as the existing transport configmap flow (so we can merge things without breaking everything when migrating)
• ???

Definition of done

Testing

And also tiny change to capiinstaller to support new and old metadata concurrently.

New metadata described in https://hackmd.io/fgUVINKYQOCkzxNo5WPK3Q