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

Jan Zelený jzeleny at redhat.com
Thu Jan 22 16:05:34 UTC 2015


On 20. 1. 2015 at 08:40:30, Colin Walters wrote:
> On Tue, Jan 20, 2015, at 06:27 AM, Jan Zelený wrote:
> > 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?
> Fedora 21 Atomic does work with a current F21 packageset.  For example
> Docker stores state in /var/lib/docker, and no changes were required to the
> docker RPM or or rpm-ostree for this.
> 
> (Although an aside, Fedora 21 Atomic also stores docker images in a LVM
> volume which means they would need special factory reset handling if the
> feature was implemented)
> 
> > In other words, do you propose this change to be gradually implemented
> > where it makes sense?
> 
> Right, on demand.  If there's a Fedora RPM that doesn't work with this
> scheme and is desirable to use by a 3rd party or by the Fedora Atomic
> subproject, we'd engage with the RPM maintainer to figure out a solution.
> 
> > 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.
> 
> There's a commit to OSTree which does make fully transient /var happen out
> of the box if the underlying / is read-only:
> https://git.gnome.org/browse/ostree/commit/?id=ff6883ca0655ac8844cd783caf6a7
> d8815515ba3
> 
> Which is pretty nice for some use cases, but definitely not the default =)
> 
> At a high level, I do agree this part of the change needs analysis, and
> I'm glad you brought it up.  In the end I think the risk here is going to
> vary a lot per package.
> 
> For example, I need to look closely at the alternatives system.
> 
> But I certainly don't want to break the traditional install model - among
> other things, it's going to be a while before rpm-ostree would be a usable
> way to run my desktop, and also packages need to be backportable to older
> branches, etc.


Thanks again for the detailed explanation, I really appreciate it :-)

Jan


More information about the devel mailing list