[systemd-devel] os-release: extension to expose host's version variables to containers

[Luca Boccassi]

On Wed, 2020-05-06 at 18:11 +0100, Simon McVittie wrote:
> On Wed, 06 May 2020 at 16:39:39 +0200, Lennart Poettering wrote:
> > On Do, 16.04.20 16:56, Simon McVittie (smcv at collabora.com) wrote:
> > > /run/host seems like a reasonable convention to encourage for
> > > container/host systems that want this, since it doesn't require
> > > inventing a new top-level directory.
> > 
> > I am not opposed adding something similar to nspawn, using the same
> > paths. Only issue I see: docker doesn't acknowledge the existance of
> > /run inside the container iirc, i.e. doesn't pre-mount it, hence
> > passing data in via some subdir in /run is weird...
> 
> I suspect Docker itself probably isn't going to implement this interface,
> because it doesn't generally acknowledge the existence of non-Docker
> container frameworks, and sharing information from the host with the
> container is pretty much the opposite of its philosophy in any case.
> 
> If *users of Docker* want to implement this interface, they can do so
> with something like
> 
>     docker run \
>     --mount type=tmpfs,tmpfs-mode=0755 \
>     --mount type=bind,src=/etc/os-release,dst=/run/host/etc/os-release,ro \
>     ...
> 
> in much the same way they can implement the "/run is a tmpfs"
> interface, or the various desirable properties listed in
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsystemd.io%2FCONTAINER_INTERFACE%2F&data=02%7C01%7Cluca.boccassi%40microsoft.com%7C3ee95a75b2de49a07fdd08d7f1e96cec%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637243857614931646&sdata=x2muu%2BUz%2F1hl%2B2Gs7Q3OjIIMhM8acdqbWqYHmO9L3m0%3D&reserved=0>;, by giving Docker suitable
> options.
> 
> They'd have to pass similar options to Docker to get /host (which was the
> original suggestion in this thread), so the conventional directory might
> as well be one that doesn't need to invent new top-level directories?
> 
>     smcv

Hi,

Thank you both for chipping in - as suggested, I've opened an RFE:

https://github.com/systemd/systemd/issues/15878

The /run/host solution sounds very simple and as Simon rightly pointed
out it doesn't strictly require the collaboration of every container
runtimes, which is a huge advantage.
But I have to say I find the idea of using $container_foo env vars very
attractive because an application can then have both sets available at
the same time, clearly namespaced. One of the applications in my use
case actually does need to look at both.

I'll start playing with this idea and see where I get.

-- 
Kind regards,
Luca Boccassi