Align codebase with openshift/cincinnati (prepare for folding back there)

[lucab]

Once the development dust settles here, this project should be folded back into https://github.com/openshift/cincinnati.

A list of things that need to happen before being able to do that:

• [x] split into two binaries, fcos-graph-builder and fcos-policy-engine
• [x] decommission dumnati binary
• [ ] rework graph-processing logic into plugins

[junjiequ]

Hi there,

I am new to Fedora CoreOS. I am trying to understand the update paradigm currently.

Could you help me with a couple of puzzles I have at the moment?

• What's the use case of this dumnati binary at the moment? Is it only intended for development purpose?
• Compared to the upstream Cincinnati repo, I could see that dumnati has customization to download the release from the release endpoints, i.e.: https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/31.20200127.3.0/release.json.
  • Is this releases.json file an artifact generated by the coreos-assembler?
  • In the release definition of each build, there are different types of artifacts, i.e. pxe, iso, does that mean the Zincati client will pull the whole OS image down to the host machine? I couldn't figure out how rpm-ostree comes to play in this case.
• I might be confused by the advertising words of rpm-ostree: rpm-ostree is a hybrid image/package system., does the word image actually refers to the system image, not the docker image? As far as I understand, Cincinnati naturally supports container image updates.

Or am I way off the track of understanding the whole thing?

Thanks in advance for some clarifications.

[lucab]

Could you help me with a couple of puzzles I have at the moment?

Sure! But this kinds of general questions are better suited for https://discussion.fedoraproject.org/c/server/coreos.

* What's the use case of this dumnati binary at the moment? Is it only intended for development purpose?

It's the backend behind https://updates.coreos.stg.fedoraproject.org. At this point you are not supposed to run it on your own.

  * Is this releases.json file an artifact generated by the coreos-assembler?

Almost, it is generated by the FCOS build pipeline at https://github.com/coreos/fedora-coreos-pipeline.

  * In the release definition of each build, there are  different types of artifacts, i.e. pxe, iso, does that mean the Zincati client will pull the whole OS image down to the host machine? I couldn't figure out how `rpm-ostree` comes to play in this case.

Zincati determines which update is available for a machine, and the corresponding OSTree commit. It asks rpm-ostree to pull and deploy such commit from the Fedora OStree repository. It doesn't re-download the whole OS image on updates, those artifacts are only used for new installs.

* I might be confused by the advertising words of rpm-ostree: _rpm-ostree is a hybrid image/package system._, does the word `image` actually refers to the system image, not the docker image? As far as I understand, Cincinnati naturally supports container image updates.

That refers to OS images. Cincinnati is just a protocol for updates hinting. What is being updated depends on the client.

[lucab]

Ratcheting changes here, I think a good first step would be introducing fcos-graph-builder binary first and capturing the shared logic in a commons library. That can be deployed to fedora-infra in order to check that everything is fine, without impacting clients.

Once there, the next thing is landing fcos-policy-engine and routing request to it instead of dumnati. This is the most sensitive step as it impacts clients, so we should keep that in mind and make it easy to switch (perhaps running all the three components for some time and just switching the endpoint service in openshift).

After that, if all goes well, we can remove the dumnati crate.