Re: ostree daemon/shared library approach

[Dan Nicholson <nicholson endlessm com>]

Hi Colin,

My personal thoughts below. I haven't discussed with any of the other
Endless guys.

On Tue, May 5, 2015 at 9:04 AM, Colin Walters <walters verbum org> wrote:
> In
>
> https://github.com/projectatomic/rpm-ostree/pull/116
>
> We're discussing a daemon for rpm-ostree.  This has several intersections
> with ostree, notably around any administrator use of the `ostree admin` CLI.
>
> Now, Endless has had an ostree daemon for some time:
>
> https://github.com/endlessm/ostree/tree/master/src/daemon

Much of our current daemon code is overkill for what we want to use it
for and can often times fit rather awkwardly with our updater service.
IMO, the 3 major features it currently provides us are:

1. Access to ostree's internal admin level APIs. A lot of these have
become available in newer ostree, so this might not be much a problem
anymore.
2. A daemon (obviously) that keeps a single process managing the
ostree repo and deployments.
3. DBus interfaces to query the current status of pulling and upgrading.

We need to retain those features somehow.

> What I'm presently thinking though is that the correct approach
> here is to continue down the path of "ostree as shared library",
> where we expect people to write higher level tools on top.
>
> In that case, the core `libostree` should have all necessary APIs
> to write a useful daemon externally.

Agreed.

> Further, the `ostree admin` commands should be regarded as
> "demonstration only".  In fact, I'd go so far as to suggest
> that for e.g. rpm-ostree managed systems, the `ostree admin`
> commandline should be disabled.
>
> One thing I'm thinking about is a "plugin" model where
> projects like rpm-ostree can drop /usr/lib/ostree/admin-plugins/rpm-ostree.so
>
> OSTree would iterate over these, see if they're "active" (in the
> case of rpm-ostree, that's having the daemon running), and if so
> call into them.
>
> Perhaps the expected admin UX here is then:
>
> # ostree admin status
> error: This system is managed by rpm-ostree; use rpm-ostree status
>
> Ugly, but keeps things clear.

Yeah, for our case, "ostree admin" is only ever used when composing
our images or by developers. That said, as long as interfaces for
deploying are available via libostree, we should be fine. I have a
pipe dream to create something like dpkg-ostree that more natively
handles packages like rpm-ostree, but it's low priority. We're mostly
getting along fine with our "compose via a bunch of scripts
surrounding debootstrap" setup.

> I'm curious about thoughts from Endless people around this.  The
> TL;DR is I'd suggest
>
> - The current daemon code move into https://github.com/endlessm/eos-updater

As long as the required interfaces are available from libostree, that
should be fine. I don't think we fundamentally require that daemon
code to be in ostree proper.

> - We make static deltas work for your use case

I don't think we have any special requirements here.

> - We also merge more of any outstanding size metadata work

This would be really good to have. John is working on that currently,
and we want to be able to track how much data needs to be downloaded
since our intended market is very network limited.

Thanks for getting in touch!

Dan