Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for depends_on condition type of "service_completed_successfully" #11335

Closed
bjconlan opened this issue Aug 26, 2021 · 1 comment
Closed
Labels
locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.

Comments

@bjconlan
Copy link

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind feature

Description

Currently podman doesn't support the docker-compose configuration value of services.${service_a}.depends_on.${service_b}.condition: service_completed_successfully for initializing depended services after service_b has completed successfully (available in docker-compose 1.29)

This may be jumping the gun over the current spec (but the spec looks to be moving this through as any bureaucratic process does)
compose-spec/compose-spec#144
compose-spec/compose-spec@dc40e3e

Steps to reproduce the issue:

  1. Run a a docker-compose file which uses the condition value of 'service_completed_successfully'

Describe the results you received:

Verify that the execution results in:

ERROR: The Compose file './docker-compose.yml' is invalid because:
services.${service_a}.depends_on.${service_b}.condition contains "service_completed_successfully", which is an invalid type, it should be a service_started, or a service_healthy

Describe the results you expected:

Execution inline with current docker-compose versions (1.29 or later) where ${service_a} begins executing only after ${service_b} has completed successfully.

Additional information you deem important (e.g. issue happens only occasionally):

Output of podman version:

(paste your output here)
podman version 3.2.3

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.21.3
  cgroupControllers: []
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.0.29-2.fc34.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.29, commit: '
  cpus: 8
  distribution:
    distribution: fedora
    version: "34"
  eventLogger: journald
  hostname: fedora
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  kernel: 5.13.12-200.fc34.x86_64
  linkmode: dynamic
  memFree: 17933127680
  memTotal: 33261002752
  ociRuntime:
    name: crun
    package: crun-0.21-1.fc34.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 0.21
      commit: c4c3cdf2ce408ed44a9e027c618473e6485c635b
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
  os: linux
  remoteSocket:
    exists: true
    path: /run/user/1000/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: true
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: true
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.1.9-1.fc34.x86_64
    version: |-
      slirp4netns version 1.1.8+dev
      commit: 6dc0186e020232ae1a6fcc1f7afbc3ea02fd3876
      libslirp: 4.4.0
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.5.0
  swapFree: 8589930496
  swapTotal: 8589930496
  uptime: 1h 2m 16.22s (Approximately 0.04 days)
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - docker.io
  - quay.io
store:
  configFile: /home/bjc/.config/containers/storage.conf
  containerStore:
    number: 21
    paused: 0
    running: 2
    stopped: 19
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /home/bjc/.local/share/containers/storage
  graphStatus:
    Backing Filesystem: btrfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 46
  runRoot: /run/user/1000/containers
  volumePath: /home/bjc/.local/share/containers/storage/volumes
version:
  APIVersion: 3.2.3
  Built: 1627933161
  BuiltTime: Tue Aug  3 05:39:21 2021
  GitCommit: ""
  GoVersion: go1.16.6
  OsArch: linux/amd64
  Version: 3.2.3

Package info (e.g. output of rpm -q podman or apt list podman):

podman-3.2.3-2.fc34.x86_64

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/master/troubleshooting.md)

No

Additional environment details (AWS, VirtualBox, physical, etc.):

@Luap99
Copy link
Member

Luap99 commented Aug 27, 2021

I don't think podman needs to do anything to support this. Docker-compose handles this client side so the podman server does not need to know about this. The error message is created by docker-compose, you need at least v1.29 according to this docker/compose#8154.

@Luap99 Luap99 closed this as completed Aug 27, 2021
@github-actions github-actions bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Sep 21, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 21, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.
Projects
None yet
Development

No branches or pull requests

2 participants