When we finish building an image, we try to look up its ID by looking up
the image using the name that we were asked to assign to the image. If
we weren't asked to assign a name to the image, that would produce an
error. The BuildImage() API we're using returns the image's ID anyway,
so we can skip the lookup and just return the ID directly.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
the paths and instructions for running the new api via systemd needed updates due to a change in the command.
Signed-off-by: Brent Baude <bbaude@redhat.com>
This is needed because the prune container image will be built from
other branches as they are made. If the behavior of this or the imgts
image diverges from that of master, random VM images could be "cleaned"
unexpectedly. By hard-coding this task to the master branch only,
it should never run anywhere else.
Signed-off-by: Chris Evich <cevich@redhat.com>
This is needed to provide this image under quay.io/libpod/ namespace
to provide some resiliency to automated testing (should other
repositories be unavailable)
Signed-off-by: Chris Evich <cevich@redhat.com>
If there are no running containers - for example, if the pod was
just created - the cgroup in question may not exist (under
certain circumstances that we're not 100% sure about). However,
regardless, we don't need to set a PID limit, as nothing will be
making cleanup processes (no running conmon processes), so not
changing the cgroup is safe regardless.
Fixes#5072
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
We document that memory-swap==-1 means unlimited, but currently we
won't allow the user to specify the -1 value.
Signed-off-by: Daniel J Walsh <dwalsh@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 linting task identifies gofmt issues; therefore it makes more sense to run our make gofmt first, which actually fixes the gofmt issues.
Signed-off-by: Brent Baude <bbaude@redhat.com>
This adds network-related options to the pod in the database. We
are going to add the CLI frontend in further patches.
In short, this should greatly improve the ability of pods to
configure networking, once the CLI parsing is added.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
When we filter, it should be out of all containers, not just
running ones, by default - this is necessary to ensure Docker
compatability.
Fixes#5050
Signed-off-by: Matthew Heon <mheon@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>
Podman does select the wrong Containerfile if the current working
directory contains a Containerfile but we specify one from a different
location.
Reproducer:
```
> mkdir 1
> echo FROM scratch > Containerfile
> echo FROM golang > 1/Containerfile
> podman build -f 1/Containerfile -t test
STEP 1: FROM scratch
```
Signed-off-by: Sascha Grunert <sgrunert@suse.com>
