full-stack-fastapi-template

full-stack-fastapi-template copied to clipboard

Good day.

Couple days ago Flower stopped working and giving me next error, when trying to start the container.

ERROR: for flower Cannot start service flower: OCI runtime create failed: container_linux.go:380: starting container process caused: exec: "--broker=amqp://guest@queue:5672//": stat --broker=amqp://guest@queue:5672//: no such file or directory: unknown

I cross-checked all configs and they seem to be identical to ones in template itself.

All the other containers start and work just fine

EDIT: not working on macOS 11.4 with Docker Engine v20.10.7 as well as Ubuntu 20.04.2 LTS

I can confirm the same problem on Ubuntu 20.04 in both WSL2 and a normal VM. WSL2 doesn't appear to work at all, whereas in the normal VM just the flower service appears to not be working

@kgorshkoff The problem is that mher/flower in the docker compose file points to latest, and latest is no longer compatible with the docker compose file. If you override the image and point to mher/flower:0.9.7 then everything works fine.

I'll submit a PR to at least get things installing again

It did help, thank you a lot!

С уважением, Кирилл Горшков 16 июля 2021 г., 12:10 +0300, Anton Melser @.***>, писал:

@kgorshkoff The problem is that mher/flower in the docker compose file points to latest, and latest is no longer compatible with the docker compose file. If you override the image and point to mher/flower:0.9.7 then everything works fine. I'll submit a PR to at least get things installing again — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

mher/flower:0.9.7

thank you!

@tiangolo I think this bug needs to be addressed in the code. I used this stack template a few times in the last few weeks and every time I get this error in the beginning and then search for this issue in the browser history to get the backend working

@dmitrybabanovforreal , I'm pretty sure this repo has reached the end of updates from @tiangolo . There are now lots and lots of PRs for the many bugs, and the maintainer has shown no signs of life on the repo for months. Looks fairly abandoned to me...

@kgorshkoff The problem is that mher/flower in the docker compose file points to latest, and latest is no longer compatible with the docker compose file. If you override the image and point to mher/flower:0.9.7 then everything works fine.

I'll submit a PR to at least get things installing again

I wish I saw this 12 hours ago. This fixed it for me.

@kielerrr , this is unfortunately one of the disadvantages of open source software that you don't pay for. Popular repositories get abandoned by well-known FOSS developers with absolutely zero indication the repo/project has been abandoned/no longer works, etc. People have the expectation that such community figures won't just casually abandon very widely used software. Many simply don't care that hundreds or even thousands of people waste many hours, which a simple update at the top of the readme would avoid. @tiangolo has abandoned this repo, and obviously won't let anyone else maintain it, meaning some issues (like the flower issue) already have several PRs fixing it.

It seems ridiculous that people who donate hundreds/thousands of hours of amazing work to the community would cause such easily avoidable frustration but this happens to LOTS of popular repos. The other option is that we write everything ourselves from scratch...

It seems ridiculous that people who donate hundreds/thousands of hours of amazing work to the community would cause such easily avoidable frustration but this happens to LOTS of popular repos. The other option is that we write everything ourselves from scratch...

This stack has saved me so much time in other ways I can forgive a little time wasted on a fixable issue in the repo. Maybe its time to fork or see if tiangolo wants to turn over PR control to someone with more time. It does feel tragic knowing an unpatched repo is being cloned hundreds of times with a bug that is going to cost thousands of hours of time, all while the fix is sitting in a PR queue. I guess it's a lesson to check the issues tab before diving into a day long debug adventure. I should have done it the other way around.