Add key to control if a container can get started by its pod #24437
Conversation
|
Still need to add tests tomorrow (and fix typos in the docs..), but I wouldn't mind if someone can get a peek and check if that's the best solution or not. I'm also a bit unsure if I've been clear enough in the man page. I tested locally and removing the Wants=/Before= in the pod service is enough. Ordering is preserved by the container service already getting |
| @@ -813,6 +814,16 @@ Size of /dev/shm. | |||
|
|
|||
| This is equivalent to the Podman `--shm-size` option and generally has the form `number[unit]` | |||
|
|
|||
| ### `StartWithPod=` | |||
|
|
|||
| Start the container aftert the associated pod is created. Default to **true**. | |||
|
|
||
| If `true`, container will be started/stopped/restarted alongside the pod. | ||
|
|
||
| If `false`, the container will not be started when the pod starts. The container will be stopped when the pod. Restarting the pod will also restart the container. |
There was a problem hiding this comment.
| If `false`, the container will not be started when the pod starts. The container will be stopped when the pod. Restarting the pod will also restart the container. | |
| If `false`, the container will not be started when the pod starts. The container will be stopped with the pod. Restarting the pod will also restart the container as long as the container was also running before. |
I think? Because if it was not active before the unit will not be started I would assume?
There was a problem hiding this comment.
Yeah, that's what I meant. Better be explicit here
|
Code LGTM, a test would be a wonderful addition. |
|
This PR has been marked for 5.3 inclusion but it must be merged prior to Nov 5 for inclusion in 5.3 RC3. PRs not merged by that date are considered on a case by case basis for backporting. |
lambinoo
force-pushed
the
feat-split-pod-container-start-24401
branch
from
8254113 to
341bee2
Compare
|
Ah, that's an unfortunate timing. I got sick a few days ago. |
By default today, the container is always started if its pod is also started. This prevents to create custom with systemd where containers in a pod could be started through their `[Install]` section. We add a key `StartWithPod=`, enabled by default, that enables one to disable that behavior. This prevents the pod service from changing the state of the container service. Fixes containers#24401 Signed-off-by: Farya L. Maerten <me@ltow.me>
lambinoo
force-pushed
the
feat-split-pod-container-start-24401
branch
from
341bee2 to
2597eea
Compare
openshift-ci
bot
added
the
approved
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: lambinoo, Luap99, ygalblum The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
stale-locking-app
bot
added
the
locked - please file new issue/PR
By default today, the container is always started if its pod is also started. This prevents to create custom with systemd where containers in a pod could be started through their
[Install]section.We add a key
StartWithPod=, enabled by default, that enables one to disable that behavior.This prevents the pod service from changing the state of the container service.
Fixes #24401
Does this PR introduce a user-facing change?