Technical Spec, better upgrade/rollback control

[Colin Walters]

On Fri, Mar 14, 2014 at 12:16 AM, Chris Murphy 
<lists at colorremedies.com> wrote:
> 
> How about hard link deletion time? When a tree is to be discarded, we 
> may be talking about tens of thousands of hardlinks being unlinked, 
> right? Snapshot deletion is nearly instant (some background clean-up 
> does happen).
> 

Yep, just try the reverse operation:
cp -al /usr /usr2
time rm -rf /usr2

It's ~8s for me on XFS+LVM on Samsung SSD, which I'm happy enough with. 
 When we get to the point where we're consistently debating update 
performance and not reliability, I'll be happy.

> What about permissions/selinux policy updates, or relabeling? A hard 
> link can't have different permissions/context than the file it points 
> to. If an update requires file metadata update, then I'm guessing to 
> preserve the original state of a tree, this would require creating a 
> copy of the file rather than a hard link?
> 

Yes...but the OSTree client and server don't "know" that it's a copy.  
OSTree is object-based, not delta based.  Every time any RPM changes, 
we redo a full install, and relabel on the server side, then commit 
that.  

(I do this because I demand there is *zero difference* between a fresh 
install and an upgrade - this removes a lot of potential package 
failure modes)

So a permission change will show up as a new object in 
objects/$checksum.

This does mean that if a file changes permission or SELinux label in an 
RPM, clients redownload the entire file content.  Honestly, this 
doesn't happen very often, and most individual files are small anyways. 
Static deltas will address this as well.

> If so that brings up this thread I brought up on the Fedora security 
> list. The gist is asking whether there's a security risk/concern if 
> old binaries with vulnerabilities are persistently available. 
> 

Yep, this came up before:
https://bugzilla.gnome.org/show_bug.cgi?id=722984

> And yet another topic, loosely related to the needed tree switching 
> semantics and booting. There is a thread on Discoverable Partitions 
> Spec on the systemd list:
> http://lists.freedesktop.org/archives/systemd-devel/2014-March/017677.html
> 

Discoverable Partitions pretty much orthogonal to OSTree.

> I'm kinda liking the part of this being self-describing, usable by 
> bootloaders and systemd, rather than utilities like OSTree, snapper, 
> and so on, having to become familiar with and responsible for 
> updating myriad bootloader configuration scripts
> 

OSTree already uses the BLS: 
http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/

Once syslinux and u-boot gain awareness of it, then the 
bootloader-specific code can be dropped from the OSTree core.

>  and updating fstab properly.
> 

OSTree doesn't touch fstab - it writes a new bootloader configuration 
with a new ostree= argument that points to the correct root.

>  But you know more about these pitfalls so this is mostly a heads up 
> to see if you have some opinions on whether the main two suggestions 
> are better or worse than what we have to deal with now.
> 

Ah...which "main two" suggestions and what precisely is "what we have 
to deal with now"?  Are we talking about traditional yum+rpm?  yum but 
on BTRFS?  yum on BTRFS but writing to a new snapshot, and then editing 
the bootloader configuration to make that new snapshot available on the 
next boot? 

The most useful thing I think is to compare *complete systems* (such as 
the latter vs OSTree). It gets hard to discuss individual pieces of 
technology that can be combined in many ways.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/desktop/attachments/20140314/bf5adcf8/attachment.html>