summaryrefslogtreecommitdiff
path: root/pkg/specgen
Commit message (Collapse)AuthorAge
* 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>