Repository navigation
install/uninstall commands use cases? #9
Description
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.
Activity
rhatdan commentedon May 13, 2015
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 commentedon May 13, 2015
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 commentedon May 13, 2015
I think things like
--cap-addcould be expressed declaratively.And I really want to drop the necessity for an app to implement
UNINSTALL. There should be the equivalent ofmake 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 commentedon May 14, 2015
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.