install/uninstall commands use cases?

[philips]

I am rather concerned about the current format of the install/uninstall commands as described in the atomic command. As implemented currently it relies on the host OS having a particular runtime available and then gives a script in the container access to the full host root and says "good luck".

Make script runtime/host agnostic

To fix this first concern perhaps have this label spec that there be a defined API on what sort of environment the "install executable" can expect to be operating in, for example having a /media/host-root mount point, etc. Then the container doesn't need to expect any details about the host and instead the relies on the host to create the correct environment.

Re-evaluate using a script

That said, I think that this whole install/uninstall thing is going to get us into a rather crazy place where containers are going to have to know what type of Linux it is installing to. Instead we could say what are the sorts of things we will need to configure and make them explicit.

For example in the install script in the blog post the command only does a handful of things:

• Puts down some configuration files via templates
• Enables the systemd unit file

Perhaps instead the container should describe those configuration files as metadata and the installer command should pick/choose the files that are appropriate for the host? So there would be a freedesktop.org/systemd/unit-template="[Service]... label or perhaps a label that is template-linux-host-configuration-dir=/usr/share/app-host-template.

I propose this because I am a bit skeptical that the API should be defined as a executable running over the root. That seems likely to take us back to a place where every upstream needs to worry about the finicky details of the host OS.

[rhatdan]

Have you looked at Nulecule at all? Not sure if that fixes some of you concerns or raises more concerns.

Originally our ideas around using INSTALL/UNINSTALL was to give the developer the equivalent of rpm Post/Postun. Capabilities. To allow a developer easy way to install his software container.

I wanted to get something out quick so we went with embedding the command to launch the container into the container metadata. But I think we should allow for more flexibility so that you could launch the container image with multiple container frame works, docker/rkt/systemd-nspawn/lxc ...

I do feel that going to far away from bash could be problematic from a ease of use.

BTW @cgwalters probably agrees with you.

[rhatdan]

Right now translating complex docker run/create commands into MetaData is going to be difficult.

docker run -d --cap-add=sys_time ntpd

Perhaps an easy mechanism for developers to write multiple launch commands and allow the tooling to pick the appropriate one for it.

install_docker docker run -d --cap-add=sys_time ntpd install_rkt rkt ... ...

[cgwalters]

I think things like --cap-add could be expressed declaratively.

And I really want to drop the necessity for an app to implement UNINSTALL. There should be the equivalent of make install DESTDIR= which would allow a host side system to enumerate and track the files installed. This would make things a lot more reliable rather than needing image authors to precisely undo what they did.

[philips]

My concern is less about the runtime but that every distro has these crazy quirks and that instead of making a full turing complete script perhaps there are a subset of operations that an "install" needs to do and we identify those instead.

For example, over the last 18 months I have probably helped close out 5 or more PRs to the docker systemd service files upstream that rely on debian or fedora specific environment files. People have a very poor sense of what is distro specific and what isn't.