Error init compose client protocol not available

Astro CLI
1

Hi,

I have installed the Astro CLI on a Windows 10 machine with WSL2 and Podman Desktop 4.6.2. Podman works fine as it is run other containers. It also runs the Postgres container. After having followed the Astro CLI (9.1.0) installation instructions, ‘astro dev init’ works fine (packages.txt is empty though), however commands like ‘astro dev start’ and ‘astro dev ps’ return the following message: time=“2023-09-26T11:56:14+02:00” level=fatal msg=“error init compose client protocol not available”

No new images or containers show up in Podman for the webserver, etc.

Any suggestions please? As a workaround, can I start the services individually in Podman?

Regards,
Pat

2

Hey @patricm! Thanks for reaching out here, and welcome to Astro. Love that you’re using the Astro CLI, though sorry to hear you’re having trouble.

If Podman is running fine on other containers, you may just need to configure the Astro CLI to actually “know” to use Podman instead of our Docker default.

Could you try running this?

astro config set -g container.binary podman

If you’re using Podman 3, additionally run:

astro config set -g duplicate_volumes false

Docs for this are here: Configure the Astro CLI | Astronomer Documentation

3

Hi Paola,
I (re)ran those commands just to be sure, but the result is the same:

PS C:\Users\pat\astrotest> astro config set -g container.binary podman
Setting container.binary to podman successfully

PS C:\Users\pat> astro config set -g duplicate_volumes false
Setting duplicate_volumes to false successfully

PS C:\Users\pat\astrotest> astro dev start
time=“2023-09-26T16:23:23+02:00” level=fatal msg=“error init compose client protocol not available”

4

Any other suggestions please?

5

One month after reporting this issue I have not received any valuable support to get this resolved. :frowning:

6

Hey @patricm

Apologies for the delay on this.

Windows and Docker can at times be tricky and varies from system to system. Could you please provide the following info to verify:

  1. Astro CLI version by running the command astro version
  2. Output of the Astro processes by running astro dev ps
  3. Assuming you are still on Podman 4.6.2 and Windows 10 OS?

I would also advise to set the verbosity to debug by running astro --verbosity debug before you run the above Astro CLI commands.

Thanks
Manmeet

7

Running ‘astro --verbosity debug’ just brings up the available commands. I have appended the flags to the commands instead. No additional info is displayed though…

PS C:\Users\pat\astrotest> astro config set -g container.binary podman
Setting container.binary to podman successfully

PS C:\Users\pat\astrotest> astro config set -g duplicate_volumes false
Setting duplicate_volumes to false successfully

PS C:\Users\pat\astrotest> astro version --verbosity debug
Astro CLI Version: 1.19.2

PS C:\Users\pat\astrotest> astro dev ps --verbosity debug
time=“2023-11-03T11:19:15+01:00” level=fatal msg=“error init compose client protocol not available”

Also retried the initialization…

PS C:\Users\pat\astrotest> astro dev init --verbosity debug
Initializing Astro project
Pulling Airflow development files from Astro Runtime 9.4.0
C:\Users\pat\astrotest
You are not in an empty directory. Are you sure you want to initialize a project? (y/n) y
Reinitialized existing Astro project in C:\Users\pat\astrotest

PS C:\Users\pat\astrotest> astro dev start --verbosity debug
time=“2023-11-03T11:26:25+01:00” level=fatal msg=“error init compose client protocol not available”

And yes, still on Windows 10 OS and Podman 4.6.2

8

I have just performed an upgrade to Podman 4.7.2. The same error message is displayed for the astro commands.

9

Any update please???

10

Hey @patricm

I have passed on the message to the Astro CLI team. Will keep you posted on this.

Thanks
Manmeet

11

4 months and counting…

12

I am not sure that this will help but since you are on Podman 4 your duplicate_volumes should not be false. Maybe try setting it to true:

astro config set -g duplicate_volumes true

Also is your DOCKER_HOST environment variable set to the location of your Podman service socket? If not you can get more information on how to do this here.

We are in the process of trying to reproduce the error you are receiving any information about your environment would be helpful.

13

Yes, my DOCKER_HOST env variable is set properly. Set the ‘duplicate_volumes’ to true does not resolve the problem.