| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
| |
... rather than create a new slice and then make the caller
replace the original with the new one.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
|
| |
|
|
|
|
|
| |
vendor in c/common config pkg for containers.conf
Signed-off-by: Qi Wang qiwan@redhat.com
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
|
| |
|
|
|
|
|
|
| |
using the factory approach similar to container, we now create pods based on a pod spec generator. wired up the podmanv2 pod create command, podcreatewithspec binding, simple binding test, and apiv2 endpoint.
also included some code refactoring as it introduced as easy circular import.
Signed-off-by: Brent Baude <bbaude@redhat.com>
|
| |
|
|
|
|
|
|
| |
when a network is not provided, we should set a default mode based on rootless or rootfull.
Fixes: #5366
Signed-off-by: Brent Baude <bbaude@redhat.com>
|
| |\
| |
| | |
Make macOS unit tests runnable
|
| | |
| |
| |
| | |
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
|
| |/
|
|
|
|
| |
This will be used for remote creation of pods initially.
Signed-off-by: Matthew Heon <mheon@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add support to auto-update containers running in systemd units as
generated with `podman generate systemd --new`.
`podman auto-update` looks up containers with a specified
"io.containers.autoupdate" label (i.e., the auto-update policy).
If the label is present and set to "image", Podman reaches out to the
corresponding registry to check if the image has been updated. We
consider an image to be updated if the digest in the local storage is
different than the one of the remote image. If an image must be
updated, Podman pulls it down and restarts the container. Note that the
restarting sequence relies on systemd.
At container-creation time, Podman looks up the "PODMAN_SYSTEMD_UNIT"
environment variables and stores it verbatim in the container's label.
This variable is now set by all systemd units generated by
`podman-generate-systemd` and is set to `%n` (i.e., the name of systemd
unit starting the container). This data is then being used in the
auto-update sequence to instruct systemd (via DBUS) to restart the unit
and hence to restart the container.
Note that this implementation of auto-updates relies on systemd and
requires a fully-qualified image reference to be used to create the
container. This enforcement is necessary to know which image to
actually check and pull. If we used an image ID, we would not know
which image to check/pull anymore.
Fixes: #3575
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
during container creation, if no network is provided, we need to add a default value so the container can be later started.
use apiv2 container creation for RunTopContainer instead of an exec to the system podman. RunTopContainer now also returns the container id and an error.
added a libpod commit endpoint.
also, changed the use of the connections and bindings slightly to make it more convenient to write tests.
Fixes: 5366
Signed-off-by: Brent Baude <bbaude@redhat.com>
|
| |
|
|
|
|
| |
Enable the goimports linter and fix reports.
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch allows users to specify the list of capabilities required
to run their container image.
Setting a image/container label "io.containers.capabilities=setuid,setgid"
tells podman that the contained image should work fine with just these two
capabilties, instead of running with the default capabilities, podman will
launch the container with just these capabilties.
If the user or image specified capabilities that are not in the default set,
the container will print an error message and will continue to run with the
default capabilities.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
|
| |
|
|
|
|
|
|
| |
Previously --uts=container: expected the full container ID.
Closes: https://github.com/containers/libpod/issues/5289
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before Libpod supported named volumes, we approximated image
volumes by bind-mounting in per-container temporary directories.
This was handled by Libpod, and had a corresponding database
entry to enable/disable it.
However, when we enabled named volumes, we completely rewrote the
old implementation; none of the old bind mount implementation
still exists, save one flag in the database. With nothing
remaining to use it, it has no further purpose.
Signed-off-by: Matthew Heon <mheon@redhat.com>
|
| |
|
|
|
|
| |
this uses the specgen structure to create containers rather than the outdated createconfig. right now, only the apiv2 create is wired up. eventually the cli will also have to be done.
Signed-off-by: Brent Baude <bbaude@redhat.com>
|
| |
|
|
|
|
|
|
|
|
| |
warning: the naming of this might change as well as the location.
this is a build on a PR from mheon from last year that proposes a shift from our current approach of creating containers based on the arbitrarily made createconfig. the new approach would be to have a specification that is detached from the podman cli. the spec could then be generated and used to make a container. this theoretically is the beginning of a long-needed refactor involving how we get from the cli -> libpod | apiv2 -> libpod with code re-use and less duplication.
the intent is to build the apiv2 container creation based on this approach only. wiring to the podman cli will happen after the fact.
Signed-off-by: Brent Baude <bbaude@redhat.com>
|
|
|
The current Libpod pkg/spec has become a victim of the better
part of three years of development that tied it extremely closely
to the current Podman CLI. Defaults are spread across multiple
places, there is no easy way to produce a CreateConfig that will
actually produce a valid container, and the logic for generating
configs has sprawled across at least three packages.
This is an initial pass at a package that generates OCI specs
that will supersede large parts of the current pkg/spec. The
CreateConfig will still exist, but will effectively turn into a
parsed CLI. This will be compiled down into the new SpecGenerator
struct, which will generate the OCI spec and Libpod create
options.
The preferred integration point for plugging into Podman's Go API
to create containers will be the new CreateConfig, as it's less
tied to Podman's command line. CRI-O, for example, will likely
tie in here.
Signed-off-by: Matthew Heon <mheon@redhat.com>
|
