search

coreos / fedora-coreos-docs

Documentation for Fedora CoreOS
https://docs.fedoraproject.org/en-US/fedora-coreos/
Other
50 stars 121 forks source link

Add a doc for container provisioning and updates #540

Open cgwalters opened 1 year ago

cgwalters commented 1 year ago

The layering model is an entirely new way to do systems management. Let's document the current state.

cgwalters commented 1 year ago

I'm still not sure we should doc this (we were making progress on https://github.com/coreos/fedora-coreos-tracker/issues/1263

I commented on the issue. Indeed, documenting this is tantamount to support. But I think the state of things will be pretty clear to users from the docs.

If we do I think we should call out more clearly the need to implement your own build system and the loss of managed autoupdates (update graph). The autoupdates part is kind of implied because of the documented update unit/timer, but we should make it clearer.

I think automatic updates are still present, it just requires slightly more work. But I believe that anyone who is doing anything nontrivial with a FCOS like system will already be invested in systems management infrastructure, and specifically using containers.

cgwalters commented 1 year ago

and nodes may in the future require reprovisioning.

Breaking this one out to the toplevel because I disagree with it the most. Everything done on the (rpm-)ostree side for this has been with an eye to compatibility and making things a seamless transition. Many people are using it for various use cases, from their personal desktops and it shipped in OpenShift 4.12.

Saying that reprovisioning may be required is in fundamental conflict with that. I personally am signed up and committed to debug any problems from this that may arise in the future. I don't understand why others on the team don't feel the same way.

cgwalters commented 1 year ago

but its integration into Fedora CoreOS are subject to change

Also of course, merging this is effectively saying that's not the case; the butane configuration here is proposed to work into the forseeable future.

The auto-update unit is pretty lame, but definitely functional. I've got some PRs up to try to clean this up and more directly support it in https://github.com/coreos/rpm-ostree/pull/4392 but I wouldn't consider that a blocker, because ultimately the users pursuing this path are already in a position where they likely want to "own" more of the OS update logic, so these sample units are just a starting point. In effect actually layering is kind of saying that things like the zincati remote locking API is instead something that can be just owned by 3rd party agent logic; we provide lower level tools. This also relates to https://github.com/coreos/zincati/pull/904

So the integration will certainly hopefully improve, from my PoV, but I would not say "change" as in "possibly breaking change".

cgwalters commented 1 year ago

OK, I've updated this with a "Understanding Ignition versus container content" section, and moved the autoupdate code into https://github.com/coreos/layering-examples/pull/58

cgwalters commented 1 year ago

OK, fleshed out the "When to use Ignition" section even more!

cgwalters commented 1 year ago

I reworked https://github.com/coreos/fedora-coreos-tracker/issues/1363 to be a tracker that includes this PR

travier commented 1 year ago

From my perspective, this is blocked on https://github.com/coreos/fedora-coreos-tracker/issues/1367

cgwalters commented 1 year ago

From my perspective, this is blocked on https://github.com/coreos/fedora-coreos-tracker/issues/1367

blocked is IMO a strong term. Why is it blocked on that versus it just being a nice-to-have?

That's a pretty easy thing for someone who is not us to do on their own infrastructure. In fact I'd say supporting "mirror the base image to a custom registry and control it using tooling you know" is really a lot of the point of this.

travier commented 1 year ago

For me this is really blocking any real usage of ostree native containers for FCOS.

Users need tags for FCOS releases to be able to test / run previous releases, use Git Ops to test their updates, use fixed versions in their CI, etc.

We have the same issue for Silverblue & friends.

navaati commented 10 months ago

Hi. @cgwalters in https://github.com/coreos/rpm-ostree/pull/4392 you said:

This is aiming to help replace the hacky systemd unit created in https://github.com/coreos/fedora-coreos-docs/pull/540

I have no idea how it relates, now that the aforementioned PR is merged can you update this one to make use of it ? I may very well missing something :).

Also I see that https://github.com/coreos/butane/issues/428 is closed, does that mean that the idea of easily using that feature from ignition is abandoned ? What would the end-game UX look like ?

Thanks y’all FCOS team for carrying the dream of immutable infrastructure !