summaryrefslogtreecommitdiff
path: root/pkg/specgen
Commit message (Collapse)AuthorAge
* auto updatesValentin Rothberg2020-03-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* add default network for apiv2 createBrent Baude2020-03-06
| | | | | | | | | | | | | 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>
* golangci: enable goimportsValentin Rothberg2020-03-05
| | | | | | Enable the goimports linter and fix reports. Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
* Allow devs to set labels in container images for default capabilities.Daniel J Walsh2020-03-02
| | | | | | | | | | | | | | | | 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>
* spec: allow container alias name in lookupGiuseppe Scrivano2020-02-26
| | | | | | | | Previously --uts=container: expected the full container ID. Closes: https://github.com/containers/libpod/issues/5289 Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
* Remove ImageVolumes from databaseMatthew Heon2020-02-21
| | | | | | | | | | | | | | 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>
* apiv2 container create using specgenBrent Baude2020-02-19
| | | | | | 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>
* [CI:DOCS]addition of specgen packageBrent Baude2020-02-04
| | | | | | | | | | 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>
* Initial implementation of a spec generator packageMatthew Heon2020-02-04
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>