An artifact without the title annoation just gets the digest as name
which is less than ideal. While it is a decent default to avoid
conflicts users would like to configure the name.
With the name=abc option we will call the file abc in case of a signle
artifact and otherwise we use abc-x where x is the layer index starting
at 0 to avoid conflicts.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
If the artifact has a single blob then use the dst path directly as
mount in case it does not exist.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Given I wrote this and I still mess it up on a regular basis, I
cannot be alone in forgetting whether "dst" or "dest" is the
correct short option for "destination". Let's just make both
valid, I don't see a reason not to.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
Add a new option to allow for mounting artifacts in the container, the
syntax is added to the existing --mount option:
type=artifact,src=$artifactName,dest=/path[,digest=x][,title=x]
This works very similar to image mounts. The name is passed down into
the container config and then on each start we lookup the artifact and
the figure out which blobs to mount. There is no protaction against a
user removing the artifact while still being used in a container. When
the container is running the bind mounted files will stay there (as the
kernel keeps the mounts active even if the bind source was deleted).
On the next start it will fail to start as if it does not find the
artifact. The good thing is that this technically allows someone to
update the artifact with the new file by creating a new artifact with
the same name.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Image volumes (the `--mount type=image,...` kind, not the
`podman volume create --driver image ...` kind - it's strange
that we have two) are needed for our automount scheme, but the
request is that we mount only specific subpaths from the image
into the container. To do that, we need image volume subpath
support. Not that difficult code-wise, mostly just plumbing.
Also, add support to the CLI; not strictly necessary, but it
doesn't hurt anything and will make testing easier.
Signed-off-by: Matt Heon <mheon@redhat.com>
Began as a review of #20983, a community PR from @krumelmonster
for moving divisive-language footnotes closer to the point
where they're used. In the process, I noticed a lot of poor
markdown, mostly bad use of whitespace. Cleaned it up, added
some italic/bold/tty markdown to options, and cleaned up
some language I found confusing.
Thanks to @krumelmonster for initial PR.
Signed-off-by: Ed Santiago <santiago@redhat.com>
The default is OCI runtime specific, there is no way for Podman to
know it.
[CI:DOCS]
Closes: https://github.com/containers/podman/issues/20754
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Add a new `no-dereference` mount option supported by crun 1.11+ to
re-create/copy a symlink if it's the source of a mount. By default the
kernel will resolve the symlink on the host and mount the target.
As reported in #20098, there are use cases where the symlink structure
must be preserved by all means.
Fixes: #20098
Fixes: issues.redhat.com/browse/RUN-1935
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
Users want to mount a tmpfs file system with secrets, and make
sure the secret is never saved into swap. They can do this either
by using a ramfs tmpfs mount or by passing `noswap` option to
a tmpfs mount.
Fixes: https://github.com/containers/podman/issues/19659
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
HPC Community asked for this support specifically for using GPUs
within containers. Nvidia requires the correct shared library to
to be present in the directory that matches the device mounted
into the container. These libraries have random suffixes based
on versions of the installed libraries on the host.
podman run --mount type=glob:src=/usr/lib64/nvidia\*:ro=true. This helps
quadlets be more portable for this use case.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
we were previously using an experimental feature in crun, but we lost
this capability once we moved to using the OCI runtime spec to specify
the volume mappings in fdcc2257df.
Add the same feature to libpod, so that we can support relative
positions for the idmaps.
Closes: https://github.com/containers/podman/issues/17517
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Now that the OCI runtime specs have support for idmapped mounts, let's
use them instead of relying on the custom annotation in crun.
Also add the mechanism to specify the mapping to use. Pick the same
format used by crun so it won't be a breaking change for users that
are already using it.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
In each options/foo.md, keep a list of where the option is used.
This will be valuable to anyone making future edits, and to
those reviewing those edits.
This may be a controversial commit, because those crossref lists
are autogenerated as a side effect of the script that reads them.
It definitely violates POLA. And one day, some kind person will
reconcile (e.g.) --label, using it in more man pages, and maybe
forget to git-commit the rewritten file, and CI will fail.
I think this is a tough tradeoff, but worth doing. Without this,
it's much too easy for someone to change an option file in a way
that renders it inapplicable/misleading for some podman commands.
Signed-off-by: Ed Santiago <santiago@redhat.com>
podman-create and -run have many options in common. To date,
these are copy-pasted and haphazardly maintained.
Solution: add an include mechanism, '@@option foo', such
that multiple md source files can fetch from one common file.
This is a Phase One commit, a very small subset of what's
possible. Purpose of this commit is ease of review. If this
passes review, much more (trickier stuff) will be forthcoming.
Signed-off-by: Ed Santiago <santiago@redhat.com>
Paul Holzinger
Matthew Heon
Alexander Gramiak
Evstifeev Roman
Matt Heon
Ed Santiago
Giuseppe Scrivano
Valentin Rothberg
Daniel J Walsh