Drop tmpfiles var

[cgwalters]

ostree-tmpfiles.conf: Drop var entry

We are backing away from this semantic, and moving towards
/var only being initialized at initial provisioning.

---

docs/var: Update for latest

This reorients things here around the latest VOLUME /var approach.

---

[travier]

(I'm still reading and trying to understand the new implications of this change).

[cgwalters]

Makes sense! Happy to chat btw

[jmarrero]

The main changes already landed, so lgtm. I think we could have a meeting to make sure we all understand what this means.
But as I understand it.

Now when doing a deployment from a container we will copy whatever thing is in /var in the container to the host's /var. However the container is not the source of truth for /var and it also does not work like we do with /etc. It will not touch var as long as there is content in it. If someone wants to get the content in /var from each container update they would need to delete /var before each reeboot after a deployment.

[cgwalters]

If someone wants to get the content in /var from each container update they would need to delete /var before each reeboot after a deployment.

Yeah...though in theory one could manually grab updated content, it'd just be annoying to do because it's somewhat "hidden". Unlike the ostree semantics where /usr/etc always has the new content. Hmm. I guess we could make up something that's mounted at runtime dynamically like /usr/var or so that always has the latest, so if anyone wants to sync it they can just cp (or write a systemd unit etc.)

[jmarrero]

Hmm. I guess we could make up something that's mounted at runtime dynamically like /usr/var or so that always has the latest, so if anyone wants to sync it they can just cp (or write a systemd unit etc.)

Why would /var acting more like /etc would not be a good idea?

I guess the whole "container is the source of truth" makes me think that if I put something in the container it will land in my host, If we are going to preserve state in /etc and /var would be interesting to see how we can make them more similar behaviors.

[cgwalters]

On Mon, Feb 12, 2024, at 8:03 PM, Joseph Marrero Corchado wrote: > Hmm. I guess we could make up something that's mounted at runtime dynamically like `/usr/var` or so that always has the latest, so if anyone wants to sync it they can just `cp` (or write a systemd unit etc.) > Why would /var acting more like /etc would not be a good idea?

A big difference between the two right now is there is only one copy of files in /var. I don’t see us changing that by default. The story is that /var holds arbitrary user data like home directories or databases. I think we don’t want to be in a position where we overwrite or roll it back on OS upgrades/rollback. Versus config files are more a mixture of OS and user owned (or local state). The state overlay approach is allowing some parts of /var to opt into something like /etc merge semantics. In the end all we can really do is offer sensible defaults combined with a toolbox of documented techniques to apply for exceptions.

[jlebon]

I think this makes sense overall, though I also suspect like @jmarrero that people will probably be surprised to not see their updated /var container content show up on their host. One seemingly obvious thing to do is enforce that /var is marked as a VOLUME in the image itself to make this explicit. But in practice, we'd probably want to define that in our base images, which would make it invisible to derived images. Another simpler approach is to just have ostree container commit print something if /var is non-empty?

Exposing a /usr/var makes a lot of sense to me (I'd even actually literally move /var into /usr/var in the OSTree commit itself to make this clearer -- having it hidden behind the /var mount feels odd).