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

[Jan Zelený]

On 19. 1. 2015 at 11:30:22, Colin Walters wrote:
> 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.

You are probably right, I might have misunderstood what you actually propose. 
Does it mean that you actually don't require this part to be implemented at 
all and you can go with what's in /var without any distribution-wide changes? 
In other words, do you propose this change to be gradually implemented where 
it makes sense?

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

Yes, it does. Thank you

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

Thank you for the additional explanation. Now I think that the problem is not 
in what you want but in possibly ambiguous specification. What I'm afraid of is 
that some people will use this opportunity to push through fully transient 
/var.

Jan