This was originally added in commit a824186ac9803ef to be used from
Travis CI. Travis was removed in commit 8771a03af1f17f and there is
no need to have this target ever since (October 2018).
Also, remove the comment about BUILD_TAGS, which originally belonged to
varlink target (removed by commit f62a356515e387b0) but got misplaced
later.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Followup to https://github.com/openshift/release/pull/28686
in which we ask openshift-ci-bot to enforce a release-note
label on new PRs.
Dependabot PRs do not need release notes. Add a config setting
(copied from cri-o) that tells dependabot to set release-note-none
on new PRs.
Signed-off-by: Ed Santiago <santiago@redhat.com>
Support running `podman play kube` in systemd by exploiting the
previously added "service containers". During `play kube`, a service
container is started before all the pods and containers, and is stopped
last. The service container communicates its conmon PID via sdnotify.
Add a new systemd template to dispatch such k8s workloads. The argument
of the template is the path to the k8s file. Note that the path must be
escaped for systemd not to bark:
Let's assume we have a `top.yaml` file in the home directory:
```
$ escaped=$(systemd-escape ~/top.yaml)
$ systemctl --user start podman-play-kube@$escaped.service
```
Closes: https://issues.redhat.com/browse/RUN-1287
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
Code is not directly reading XDG_RUNTIME_DIR, it is reading a value in
the state that may initially be from XDG_RUNTIME_DIR, but then is
overriden by a value from the boltdb that podman stores some state in.
XDG_RUNTIME_DIR and the RunRoot path may not have the same value, so
complaining about XDG_RUNTIME_DIR here may cause confusion when trying
to debug things.
[NO TESTS NEEDED]
Signed-off-by: Kevin Downey <hiredman@thelastcitadel.com>
Removing exec sessions is guaranteed to evict them from the DB,
but in the case of a zombie process (or similar) it may error and
block removal of the container. A subsequent run of `podman rm`
would succeed (because the exec sessions have been purged from
the DB), which is potentially confusing to users. So let's just
continue, instead of erroring out, if removing exec sessions
fails.
[NO NEW TESTS NEEDED] I wouldn't want to spawn a zombie in our
test VMs even if I could.
Fixes#14252
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
Use the host UID and host GID mapping when building the local pause
image for a Pod with a custom mapping. Otherwise, the mappings are off
and the build fails. Propagating the mapping to the build container is
not needed since the pause image ships merely a copied `catatonit` from
the host.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2083997
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
Buildah got vendored into podman last week, and the script
went kablooie because of ever-so-slight conflicts between
what was in the treadmill PR (#13808) and what ultimately
got merged (#14127) which was obviously better (hey, I tried).
After a buildah vendor, there really isn't any point to keeping
the treadmill commits - we're much better off just restarting
with two fresh empty placeholder commits. Do so.
Also, mild cleanup.
Signed-off-by: Ed Santiago <santiago@redhat.com>
The completion logic currently suggest also the functions that are
defined for this type. However this did not work correctly when it was
defined as pointer to that type on not the actual type.
This commit fixes that problem. To test you can compare the difference
between `podman stats --format {{.[TAB]` with and without this commit.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Send the main PID only once. Previously, `(*Container).start()` and
the conmon handler sent them ~simultaneously and went into a race.
I noticed the issue while debugging a WIP PR.
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
Add the notion of a "service container" to play kube. A service
container is started before the pods in play kube and is (reverse)
linked to them. The service container is stopped/removed *after*
all pods it is associated with are stopped/removed.
In other words, a service container tracks the entire life cycle
of a service started via `podman play kube`. This is required to
enable `play kube` in a systemd unit file.
The service container is only used when the `--service-container`
flag is set on the CLI. This flag has been marked as hidden as it
is not meant to be used outside the context of `play kube`. It is
further not supported on the remote client.
The wiring with systemd will be done in a later commit.
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
Followup to #14178: I broke CI. "--fork-point" does not do
what I thought it did, so remove it.
Also, add 'set -x' to help us debug the next time something
like this happens.
Signed-off-by: Ed Santiago <santiago@redhat.com>
