undocumented docker compose V2 requirement

[Moopli]

This recent commit introduces a dependency on the docker compose V2 plugin, which is as-yet in beta and not distributed to all clients, eg, linux docker command lines, as are common on dev machines (like mine) and in CI environments.

[Moopli]

@WadeBarnes is this an intentional breaking change?

[WadeBarnes]

For me the changes work with docker-compose 1.29.2 and the experimental docker-compose V2. What version are you running and what errors are you seeing?

[ianco]

I tested with docker-compose 1.29.2, but FYI I had to delete my old docker images before running ./manage build (there was some docker caching issue)

[WadeBarnes]

We also have tagged releases now, so you could checkout v1.7.0 which is the release right before the updates for docker-compose; https://github.com/bcgov/von-network/releases

[WadeBarnes]

@Moopli, Regardless, let me know the behaviour you are seeing and I might be able to add support for the old and new command syntax.

[Moopli]

Thanks guys, I can work with v1.7.0 for now, but here's the error I'm seeing on master:

./manage up
unknown shorthand flag: 'd' in -d

And this seems to manifest as a result of docker compose not being recognized by my docker installation, which is Docker Engine - Community, version 20.10.6.

I suppose if you want to gracefully fallback to using docker-compose, when docker compose isn't supported, that would be convenient; but as far as I understand, the docker team is planning on rolling out the V2 plugin by default across all clients soon enough, so this issue wouldn't bite many people, hopefully 😉.

[xoryouyou]

I'm running into the same issue as @Moopli

./manage start
unknown shorthand flag: 'd' in -d

Setup:

• Docker Compose version 2.1.1
• Docker version 20.10.10, build b485636f4b

Problem:
The script correctly detects a docker compose >= 2.0
and sets the dockerCompose variable to "docker --log-level error compose"

von-network/manage

Lines 28 to 30 in 25a64cc

	if [[ $(awk "BEGIN {print (${dockerComposeVersion} >= 2.0) ? \"true\" : \"false\" }") == "true" ]]; then
	# Use the new syntax when version 2.0.0 or greater is detected.
	dockerCompose="docker --log-level error compose"

The command docker --help yields

Management Commands:
  ...
  compose*    Docker Compose (Docker Inc., 2.1.1)
  ...

And it seems to simply invoke the docker-compose binary which in turn does not support --log-level

To reproduce :

docker compose up -d webserver works fine.

But

docker --log-level error compose down -d webserver

fails with the unknown shorthand flag: 'd' in -d error

Solution: Simply remove the --log-level part in

von-network/manage

Line 30 in 25a64cc

dockerCompose="docker --log-level error compose"

for now.

[WadeBarnes]

I am able to reproduce the issue reported by @xoryouyou, by upgrading Docker so Docker Compose is v2.1.1. Proper parsing of the docker --log-level <level> flag before invoking docker compose seems to have been broken between Docker Compose v2.0.0 and v2.1.1. You can use docker --log-level <level> syntax with other management commands without issue, just not compose anymore.

The other workaround, that I use, is to turn off Use Docker Compose V2 in General Settings.

I'll have a look into this a bit more to see if there is anything we can do other than work around the issue, but this is looking like a bug in docker. Based on the help text that comes back when the commands fail the docker --log-level <level> compose syntax should work; it's listed as a valid option.

[satishsurath]

I have a workaround - that worked for me.
I just unchecked "Docker Compose V2" from my Docker Desktop Preferences to be able to successfully run ./manage build and ./manage start successfully.
I've added this a Note in README.md section to help others "https://github.com/bcgov/von-network#running-the-web-server-in-docker-against-another-ledger"

[jruizaranguren]

Problem reproduced with docker version 20.10.17 and docker compose version v2.6.1.

Having problems to run docker-desktop. Do you know of any other workaround, perhaps manual execution of the command in order to start the network?