Comments (24)
We see the same in DDEV (all our tests are failing)
extra_hosts:
- host.docker.internal=host-gateway
became
extra_hosts:
- host.docker.internal:host-gateway
I tracked it down to:
from compose.
Here you go:
test.zip
What I found:
- a new default network is created, even tho nothing asked for it
- if you add an "override", the config becomes a list, instead of a dictionary
- labels are using equal sign instead of colon
- extra_hosts are using colon instead of equal sign
from compose.
There's this:
a new default network is created, even tho nothing asked for it
from compose.
There's this:
a new default network is created, even tho nothing asked for it
@ndeloof did you notice that?
$ docker compose -f - config <<-'EOF'
name: oh-no
services:
service:
image: image
networks:
net:
networks:
net:
EOF
name: oh-no
networks:
default:
name: oh-no_default
net:
name: oh-no_net
services:
service:
image: image
networks:
net: null
(up
doesn't create it)
from compose.
I'll try to gather and share some simple outputs from both versions illustrating the issues (our stack yaml is about 6000 lines now).
from compose.
@Re4zOon could you please retitle this to something like "[BUG] v2.24.7 extra_hosts is output with colon instead of equals sign"
from compose.
Well, today is a weekend day after all: https://github.com/dwmkerr/hacker-laws?tab=readme-ov-file#hyrums-law-the-law-of-implicit-interfaces
from compose.
Well, today is a weekend day after all: https://github.com/dwmkerr/hacker-laws?tab=readme-ov-file#hyrums-law-the-law-of-implicit-interfaces
Yes, thats true. Just like: https://xkcd.com/1172/
However breaking compatibility still shouldn't result in a "patch" version according to semver.
from compose.
Ok, but what compatibility is broken? If I pipe its output through itself (with varius 2.2*.* versions that I keep around) again everything seems alright: docker compose config | docker compose -f - config -q
(using the docker-compose.yml from test.zip I get a deprecation warning, but that's all) ...
from compose.
This change indeed took place to follow docker engine preferred format after compose-spec/compose-go#499
services environment variables were switched to a list
this was required to allows resurrection of the--no-interpolate
support.
in both case, this is not "breaking compatibility": config
render a compose-spec compliant output, the fact you wrote your own parser without considering the many aspects of the spec is unfortunately an issue you have to manage on your own.
I'm closing this issue as "won't fix"
from compose.
I can understand the other point, but:
environment variables were switched to a list
Its either a list, or a dictionary and its dependent on other things.
Why do we have a spec, where it can be either with no clear setting as to which to use?
config
just decides it wants to use a list for only ONE service out of 70+, even tho the compose version did not change in our config (still on 3.5).
This means I get random behaviour and my parser will have to check if its a list, or a dictionary, as I can't anticipate which one it will be. Fun.
from compose.
There's this:
a new default network is created, even tho nothing asked for it
As I said, I can understand all other points. My main two problems:
- schema changed without any notification from one patch version to the next (even tho we still use version 3.5 )
- env variable is either a list or a dictionary, based on... something.
My parser gets a 70+ service yaml with 6000+ lines. ONE of those services has a list, all other is dictionary due to a patch.
Its the inconsistency, that bothers me.
from compose.
even tho we still use version 3.5
maybe I'm wrong and this is not about swarm/stack, but if that's the case, why don't you just use docker stack config
..
(I keep seeing this and I don't get it - why pipe compose's config output, which is like an "ng" variant, to tools that expect the "classic" variant ... and expect it to keep working)
from compose.
oh. docker stack config
didn't cross my mind...
from compose.
(there's also docker buildx bake
to build images without compose)
((neither load .env nor set COMPOSE_* variables, but ...))
from compose.
Why do we have a spec, where it can be either with no clear setting as to which to use?
compose file format initially evolved organically, and offered flexibility to users. The spec defines the many ways things can be set, but there's no "single way", compared to kube.yaml which just reflect the internal API structs.
config just decides it wants to use a list for only ONE service out of 70+, even tho the compose version did not change in our config (still on 3.5).
version
attribute is obsolete and should be removed, it doesn't guarantee anything and is just a legacy from the time compose was implemented in python.
This means I get random behaviour and my parser will have to check if its a list, or a dictionary, as I can't anticipate which one it will be. Fun.
Indeed, this is the price to pay with the flexibility we offer in the compose file format. You should not try to parse such a file with a shell script or naive parser expecting a fixed format. If you need to transform the config output, you should better rely on compose-go library and write your own transformation as actual code
from compose.
indeed, we miss removal for unused resources - but that's a distinct issue then
from compose.
I've switched to docker stack config
, so from my side this issue can be closed.
We hope we can dismantle swarm in the "not-so-near" future anyways.
from compose.
indeed, we miss removal for unused resources - but that's a distinct issue then
and to take into account profiles: #11587
$ docker compose -f - config <<-'EOF'
name: hidden
services:
service:
image: image
profiles:
- hidden
EOF
name: hidden
networks:
default:
name: hidden_default
services:
service:
image: image
networks:
default: null
profiles:
- hidden
# although --services works
$ docker compose -f - config --services <<-'EOF'
name: hidden
services:
service:
image: image
profiles:
- hidden
EOF
from compose.
I've switched to
docker stack config
, so from my side this issue can be closed. We hope we can dismantle swarm in the "not-so-near" future anyways.
https://github.com/search?q=repo%3Adocker%2Fcompose+mirantis&type=issues
https://lwn.net/Articles/905164/
from compose.
Should have been noted here that the problem behavior here was reverted in v2.25.0.
DDEV's tests can now pass with v2.25.0
from compose.
Well, but why rely on that?
The relevant part of the change was to restore a case where config did "more" - to inline the content of env files (when found) ... and this change is already subject to ... change: #11627
Who knows ... maybe config will convert all lists to maps where possible ... that's kinda' more aligned with doing "more" (plain lists are mostly for "short" forms and "long" forms, where they exist, are ... kinda' preferred and that's what I meant by doing "more" - to have config "show" you what you meant writing those files).
from compose.
actually, the docker engine API uses key=value
to set environment variables, so the mapping syntax for those only exists in compose for legacy reasons
from compose.
maps also "just work":
services:
s1:
image: image
environment:
- VAR=foo
s2:
extends: s1
environment:
- VAR=bar
But, being a weekend day after all, when it comes to extra hosts I find it funny that the long syntax is actually shorter that the short one :D
from compose.
Related Issues (20)
- [BUG] container_name validation ignores profile (regression) HOT 1
- [FEATURE] jinja templating support HOT 2
- [BUG] Docker compose yaml containers using different profiles but same container_name fails HOT 2
- [BUG] dotnet webapp is denied from accessing '/https/aspnetapp.pfx' in docker compose (running fine with docker cli) HOT 4
- [BUG] socker-compose restart vs log HOT 1
- [BUG] including files with a custom project directory is ... just broken in 2.25.0 HOT 1
- [BUG] config command format JSON broken HOT 5
- [BUG] `'version' is obsolete` HOT 25
- [BUG] start_interval not working HOT 2
- Allow multiline strings in `COMPOSE_PROFILES`
- Using a non-valid `cpus` value, silently ignores it
- [BUG] `--format` option ignored in `config` command
- [BUG] compose config format is always yaml HOT 2
- [BUG] docker compose up -d --wait option with restart polilcy 'no' HOT 3
- [BUG] Progress keeps spinning in detached mode HOT 2
- Search for .config/docker-compose.yml HOT 2
- [BUG] Container named volume mount source not getting updated HOT 2
- [BUG] Compose doesn't pass annotations to the docker
- [BUG] docker compose 2.25.0 format json outputs yaml HOT 1
- [FEATURE REQUEST/BUG?] When passing through "--device /dev/snd" respect hosts audio routing HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from compose.