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.

Sign up for GitHub

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

Jump to bottom

[BUG] --profile breaking changes #10993

Open
maciejpankanin opened this issue Sep 12, 2023 · 5 comments · May be fixed by #11050
Open

[BUG] --profile breaking changes #10993

maciejpankanin opened this issue Sep 12, 2023 · 5 comments · May be fixed by #11050
Labels
kind/bug

Comments

@maciejpankanin
Copy link

Description

Imagine a stack like this:

services:
  db:
    image: postgres:13.3
    environment:
      POSTGRES_PASSWORD: example
      POSTGRES_USER: example
      POSTGRES_DB: example
    depends_on:
      hello-world:
        condition: service_completed_successfully

  hello-world:
    image: hello-world
    profiles:
      - hello

In previous versions of docker compose I could run docker compose up and it would start the db container without any problems. Recently I upgraded docker and was really surprised that it didn't work anymore. Here is the output of `docker compose up':

service hello-world is required by db, but is disabled. Can be enabled using profiles [hello]

This is a devastating change for many compose stacks, and wasn't even mentioned in the changelog :(

There is also another surprising behaviour when running docker compose logs db reports:

no such service: hello-world

Steps To Reproduce

  1. Run docker compose up with the config above.

Compose Version

Any > 2.17.3(?)

Docker Environment

Client: Docker Engine - Community
 Version:    24.0.5
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.11.2
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.20.2
    Path:     /usr/libexec/docker/cli-plugins/docker-compose

Server:
 Containers: 16
  Running: 0
  Paused: 0
  Stopped: 16
 Images: 266
 Server Version: 24.0.5
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 8165feabfdfe38c65b599c4993d227328c231fca
 runc version: v1.1.8-0-g82f18fe
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.2.0-32-generic
 Operating System: Ubuntu 22.04.3 LTS
 OSType: linux
 Architecture: x86_64
 CPUs: 8
 Total Memory: 15.22GiB
 Name: maciej-Latitude-5410
 ID: f4474bd0-abf8-4754-b75e-03c216f7b106
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

Anything else?

No response
@ndeloof
Copy link
Contributor

ndeloof commented Sep 12, 2023

ignoring the dependency was a bug, that we fixed. But as many did like you relied on this, we introduced required as a flag to mark a dependency as "nice to have", see #10792

@ndeloof ndeloof closed this as completed Sep 12, 2023
@ndeloof
Copy link
Contributor

ndeloof commented Sep 12, 2023

Closing as a duplicate for compose-spec/compose-spec#274

@maciejpankanin
Copy link
Author

OK, thanks :)

But talking about this logs output, do you think it is OK?

@ndeloof ndeloof reopened this Sep 12, 2023
@ndeloof
Copy link
Contributor

ndeloof commented Sep 12, 2023

indeed, I missed the "logs" issue as a sub-issue here :)

@ndeloof ndeloof linked a pull request Sep 29, 2023 that will close this issue
Open
@GethDeeo
Copy link

While skimming through this issue and related PR, I came up with these two questions:

  • When using up (without profiles), should the dependency check pass in case required dependencies are in profiles, but they're already up?
  • When using down (without profiles), should the services without profiles be stopped and removed, regardless of any dependencies in profiles?

I'm trying to use a single instance of database as required dependency of multiple Compose projects. My idea was to merge the database's Compose file (via COMPOSE_FILES), and put the database service in a profile, so I don't accidentally destroy the database when playing with database-dependent Compose projects.
Obviously it's not working this way, at least not in Compose 2.21.0.

This was referenced Apr 13, 2024
Closed
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
kind/bug
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

some commands don't need Dependencies being checked ndeloof/compose
3 participants
@ndeloof @GethDeeo @maciejpankanin