[PATCH 4/6] bootloader/payload: Add Payload.handlesBootloaderConfiguration() boolean

Vratislav Podzimek vpodzime at redhat.com
Mon May 5 11:51:45 UTC 2014


On Wed, 2014-04-30 at 20:20 +0000, Colin Walters wrote:
> On Wed, Apr 30, 2014 at 3:09 AM, Vratislav Podzimek
> <vpodzime at redhat.com> wrote:
> 
> > Still, that doesn't mean there won't be anything better/different in
> > the future. From what comes to my mind now -- one could for example
> > distribute XFS fs snaphots or LV snapshots or whatsoever.
> 
> 
> Sure, one case some people were talking about is using "btrfs send"
> for OS updates.
> 
> 
> I think what these people don't realize is while a large component of
> operating system updates is just getting data from A to B (relatively
> efficiently), there are really a lot of other things that need to
> happen.  For example, you need some code that handles the bootloader
> configuration (what we're talking about here).  And you need tooling
> around things like GPG verification, TLS certificates, etc.
> 
> 
> OSTree also has special handling for /etc to perserve configuration
> while also giving you new config files.
> 
> 
> And rpm-ostree takes this a whole step farther by linking to
> librpm/hawkey and doing a *package* level diff of the two RPM
> databases in the two trees - something still important for sysadmins.
>    See:
> http://fedorapeople.org/~walters/project-atomic-package-diff.png
> (For a demo update, I removed tmux and added screen)
> 
> 
> And even better, it will have the capability to layer packages on top,
> which is pretty essential to make the whole thing practical.
> 
> 
> Finally, Linux storage is such a wide world that I think there's a
> really strong case for update systems remaining storage independent
> (as rpm and OSTree are).  Locking yourself into XFS, BTRFS, LVM or
> whatever greatly decreases the flexibility available to client
> systems.    That said at least for OSTree I plan to aggressively take
> advantage of any optional APIs offered by the storage layer.   I'm
> hoping for open(..., O_OBJECT).
I'm not telling that there are better solutions than OSTree, that's not
my point. But however great the OSTree is and however great you consider
it to be, you shouldn't expect it to be the ultimate solution for the
rest of the Linux/Anaconda/human time and thus an API should be a real
API and not just a wrong name for a method.
> 
> > If you want to have the class somehow abstract and versatile you
> > cannot fit it to one particular case. Otherwise you could name the
> > property "isOSTree" and make it's meaning more obvious.
> 
> 
> I can do something that if you think that's best, but based on the
> above I think there's a pretty strong argument against adding further
> payload types.  Further if anyone *did* add any other payload types
> that weren't yum/dnf, it seems highly likely to me they wouldn't
> want /etc/sysconfig/kernel either.  Right?
Why not? I can for example imagine using a tarball or something similar
with a way to choose from multiple kernels. And one never knows what
will come from the ARM world.

-- 
Vratislav Podzimek

Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic



More information about the anaconda-patches mailing list