Also manage the controller and daemonset manifests

[jlebon]

See https://github.com/jlebon/bootc-operator/pull/12#discussion_r3192607381. It's a common operator pattern. E.g. for OCP, the CVO just updates the manifest for the MCO operator itself, and the latter is what updates the manifests for the MCD, MCS, MCC, etc...

[alicefr]

@jlebon we haven't decided if the daemon set is deployed separately or by the operator. I would be in favor that the operator does it. It would also help for the upgrades (of the operator and the daemon set). The new version of the operator needs to take care to update the image of the daemon set, (and maybe eventually the daemon set definition as well)

[jlebon]

We discussed this a bit today. IIRC, Alice mentioned that KubeVirt directly builds the resource objects and creates them that way. OTOH, the MCO has actual YAML manifests which get baked into the operator image and then read and applied, though there are concerns around memory due to the deserialization and serialization.

[alicefr]

I think one of the advantages is when we update the operator. It can controls when the daemon is updated. If you update the image of the daemon set the daemon pods will be restarted. We might not want to do that if there there are nodes that are in staging/booting phase

[jlebon]

We discussed this more today. We reached consensus on matching the MCO, i.e.:

• shove all the manifests in the container image
• add a new cmd/operator binary that syncs its baked manifests
• add a deployment manifest for the operator

Then, updating is just updating the operator deployment manifest.

This also ties into https://github.com/jlebon/bootc-operator/issues/38. Once we have published images, the manifests can reference a specific pullspec.