Re: [atomic-devel] Tree compose questions

[Jon Stanley <jonstanley gmail com>]

On Thu, Dec 11, 2014 at 10:10 PM, Colin Walters <walters verbum org> wrote:

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

Yep, this is more of "are we insane" type stuff going on right now,
not "let's roll this out to prod tomorrow!" :)

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


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

I didn't realize it was that simple. (BTW. the command seems to be
rpm-ostree rpm --repo=repo list <refspec> - is that what you meant??)
>
> 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

That make a lot of sense, and is probably the best way to do it.
Inseparable and immutable is good :)
>
> 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.

This has long been one of my beefs with RPM, add another voice to the
"I want this" crowd :)


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

Yeah, the app in question is OpenAFS. For historical (and probably
completely insane) reasons, the AFS configuration (which is volatile,
including the CellServDB controlling where to locate AFS cells) is
stored in /usr/vice/etc. So I need some way to make that space (at
least appear to be) writable.

Since the OpenAFS RPM carries /usr/vice/etc (and some content in it),
using the method below seems somewhat problematic.
>
> 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]).

Yep, that makes a lot of sense. However, I can think of one problem
here. Let's pretend that some RPM ships something in /var that it
needs to run. A later version of that RPM updates that thing in /var
(and for whatever reason it's not backwards compatible - this is
getting somewhat into fantasy-land, but we all know how fantasy-land
becomes real-world-land! :D). How do you get updated $THING so that
the application continues to function? And pretend that you got
updated $THING, and for whatever reason you needed to rollback. How do
you get old $THING?

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

I'll give the bind mount solution a try!