F22 System Wide Change: RpmOstree - Server side composes and atomic upgrades

[Jan Zelený]

On 13. 1. 2015 at 16:41:46, Colin Walters wrote:
> On Tue, Jan 13, 2015, at 04:06 PM, Miloslav Trmač wrote:
> > > == Scope ==
> > > * Other developers:
> > > *** Use systemd-tmpfiles instead of placing content in /var  (TODO:
> > > better docs for this)
> > 
> > Is this a strict dependency or a nice-to-have item?  That is, are we
> > talking about having to change all such packages in Fedora (or some
> > specific subset) within the next ~month?
> If the package is just installing an empty directory hierarchy, it's a nice
> to have - rpm-ostree auto-synthesizes tmpfiles.d snippets.
> 
> If it's installing a regular file, then it won't work - the package (daemon)
> needs to create it on start.
> 
> The goal of this is:
>  - Support "factory reset"
>  - Make it clear that (rpm-)ostree itself never touches /var, not on install
> or upgrade. It's the sole province of 1) The daemon writing the content 2)
> The administrator's chosen backup system. (We use systemd-tmpfiles 
because
> it's a convenient way to ensure correct SELinux labeling for initial
> directories)

I have hard time figuring out what exactly is the purpose of including the 
factory reset feature in your proposal. No offense but unless I'm missing 
something, it seems to me that you are trying to solve some of ostree problems 
in the rest of the distribution rather than in ostree itself.

I think this part of the proposed change has implications as severe as those 
the infamous UsrMove had. And from what I can remember, some of us spent 
another two releases fixing that up. In this particular case, I foresee 
problems with all databases (they store data in /var) and web servers 
(/var/www). For me personally the most immediate blocker is the rpm stack 
which stores its data in /var on multiple different levels. Even if we consider 
something as unimportant as metadata cache, re-downloading it because of 
transient /var is not something our users will be happy about. Also linking 
stuff to /usr is not an option, as /usr is often read-only and 

All in all, I'm rather against this part of the proposal. In my opinion, 
ostree should take /var as it is now instead of re-designing it. If there is a 
strong demand for the factory reset feature, it should be proposed, decided 
and implemented separately.

Thanks
Jan