Re: [atomic-devel] Tree compose questions

[Colin Walters <walters verbum org>]

Hi,

On Thu, Dec 11, 2014, at 04:38 PM, Jon Stanley wrote:
> I've been doing some (perhaps crazy) experimentation with rpm-ostree
> and composing my own trees, since Atomic upgrades are extremely
> attractive to us at $DAYJOB.

Great!  Keep in mind as the README.md says, the tooling is in beta.
Some parts are quite solid, others work but are not optimized
(lack of deltas, see https://bugzilla.gnome.org/show_bug.cgi?id=721799 )
and finally the integration with the rest of the ecosystem is still ongoing (Anaconda, Pulp, etc.)

But I think Fedora 22 should see that sort of thing flesh out significantly.

> It would be nice if one of the pieces
> produced from a tree compose was a text file with what RPM's are in
> that image.

I'm a bit confused; given how easy it is to extract the RPM database,
what would be the value in creating a text file separately?  This is just:

# rpm-ostree compose --repo=repo tree --save-rpm-list=somerpmlist.txt sometreefile.json

Versus:

# rpm-ostree compose --repo=repo tree sometreefile.json
# rpm-ostree db --repo=repo list sometreefile.json > somerpmlist.txt

The advantages to having the RPM database in the commit itself are:

- The content description is always bound tightly with the commit; they
  can't get separated or lost.  They're an immutable pair capturing a state.
- We need to ship it to the client anyways, so it has to be in the tree

Also with the "list" command it'd be easy to influence the output.  For
example, I already have a bug request to have a format that has the epoch,
even if it's 0:, since it's easy to diff then.

> It would also be useful (read: required - some software is very poorly
> behaved wrt expecting a writable /usr) to specify some additional
> writable directories - how are the symlinks created? 

The first question is; does this app need to run directly on the host, or
can it be run in a container?  That maximizes flexibility in several ways.
If you want to store data to a host-mounted filesystem, you can use
bind mounts.

Say the app is hardcoded to write to /myapp, you can make /mnt/nfs/myapp a NFS (or whatever) mount, then:

# docker run -v /mnt/nfs/myapp:/myapp myapp ...


If you can not for some reason use a container, then:

Currently the rpm-ostree layout is hardcoded for the FHS directories like /srv, /mnt, /opt, etc.  These all link into /var.

Again if this application write somewhere outside of those, then 
the way I would do this is to make an RPM that contains solely:
/myapp
as an empty directory.

Then add to your /etc/fstab:
/var/local/myapp /myapp none bind 0 0

I know this might seem awkward at first, but the value is
that you know where *all* of the system local state is; it's in /var and /etc.  Period.
It's easy to back up.   

You know that rpm-ostree will never touch /var, so rollbacks will never roll back
your data.  This is in contrast to other programs that operate at the filesystem/block
level and thus tend to blend together the OS/data.  (Which in some cases makes
sense, it'd be quite possible to create a tool that combines ostree+[backup solution]).

> What tells it
> what to create and how to create them?

Basically, the RPMs.  There is some built-in postprocessing for some content
in /var.  If you really *really* need it, I added a "postprocess-script", but I
would think of this as a last resort.

>  Also, pretend I mounted a NFS
> share (or block device, or whatever - just something that is not the
> OS and is designed for storage of data) at /blah - would I be able to
> write to /blah? (I haven't quite tried this yet)

Per above I think containerizing gives you a lot of app flexibility.  But
if you do need to do the host, then the bind mount solution should
work.   Let me know if it does!