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

[Colin Walters]

On Mon, Jan 19, 2015, at 07:02 AM, Jan Zelený wrote:

> 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 wouldn't say ostree problems exactly.  I certainly could change ostree
to write to /var.  But I think the benefits of it not doing so are worth the change
in terms of getting a much cleaner separation between what's owned by the OS
and what's user data.

> 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.

Yep, I too made changes for UsrMove.  

> 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. 

Storing data in /var is fine!

> 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.

Hmm, there may be confusion on this, which is understandable because
documentation is very thin.  This isn't about making /var transient
by default.  In the default OSTree model it's fully persistent.  It *can*
be optionally transient, or reset explicitly.

> 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.

Does the above help to address your concerns?

>  If there is a 
> strong demand for the factory reset feature, it should be proposed, decided 
> and implemented separately.

Fair enough, again to be clear this is only partly about factory reset; it's
also about making upgrades more reliable by having it be clear who
owns data and when it's modified, which is why the ostree model uses it.