we use hard links now by default when copying files to /usr, allow a
way to override this behavior through the manifest file.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Closes: #1163
Approved by: peterbaouoft
atomic run has some more features compared to a raw "$RUNTIME exec",
like the possibility to run a command for a service which is not started
yet. Expose $ATOMIC as well during the installation so that a container
can more easily build a wrapper script for files inside the container.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Closes: #1141
Approved by: baude
This might not be the best place to add this information, but it is a
starting point to get it documented.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Closes: #1121
Approved by: baude
Drop the hidden option ---generate-rpm in favor of --system-package.
The new option controls how a system container is installed to the host:
--generate-rpm=build build the rpm file without installing it.
--generate-rpm=yes build the rpm and install it, the rpm is deleted.
--generate-rpm=no do not attempt to build and install an rpm file.
--generate-rpm=auto install the rpm only if a .spec file is defined in
the image. This is the default.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Closes: #767
Approved by: rhatdan
To have parity function with pull, we need to add --storage
to install and run. This allows for overriding when atomic.type
is defined. For example, if you pull an image that has
atomic.type=system but you really want to store it
on the docker backend.
Closes: #861
Approved by: baude
Check respectively that runc and bwrap-oci are available before showing
'install --system' and 'install --user'.
bwrap-oci is still not packaged and may not be available immediately on
RHEL. The check for runc is added for completeness.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Closes: #567
Approved by: rhatdan
Add --rootfs=ROOTFS to atomic install, which allows users to specify
an existing exploded container or existing rootfs location as ROOTFS.
The existing rootfs will be used as a read-only rootfs for the new
container to be installed, and therefore the new container would
only contain configuration files. (Note: currently all system
containers must have a read-only rootfs by default).
A use case for this would be using existing container's rootfs
through NFS, etc to serve as the rootfs for many containers running
the same image. This avoids duplicate storage of having a container
on each machine in a cluster.
A user can update only the remote container's config file parameters
with 'atomic update', and uninstalling a remote container does not
affect the rootfs specified in ROOTFS.
Closes: #527
Approved by: giuseppe
Users can do this themselves by using the ${NAME} field.
Hard coding behaviour of these three variables was a mistake, and this
is a lot more flexible. I could add back the variables and don't document them
if people think someone has used them
because it is error prone to use it this way. Using the same NAME in the
environment variable -e NAME=\${NAME} and in container name (--name) for
install and uninstall seems incorrect because both of them serve
different purposes. Also if NAME is being used to create a container in
the install script, which happens most of the time, it leads to failure
because the same NAME is used for the ephemeral container to process
LABEL INSTALL and due to that, the actual container can not be created
and it gives following error:
"Error response from daemon: Conflict. The name "etcd1" is
already in use by container b50ea8bf1d40."
Anyway assigning names (using -name NAME) to ephemeral containers during
install and uninstall does not make much sense in my point of view.
Use --display to view run or install commands without
executing the commands. This is useful when working with custom images
with LABEL methods defined.
Signed-off-by: Sally O'Malley <somalley@redhat.com>
This commit adds `IMAGE` and `NAME` as environment variables
passed to install, uninstall, stop, and run (similarly to
`CONFDIR`, `DATADIR`, and `LOGDIR`). This allows users to write
`NAME=${NAME}` instead of `NAME=NAME`, and also enables `${NAME}`
and `${IMAGE}` to be used in arbitrary parts of the commands.
