Why exec sh -c instead of directly running the loop?

In D816, i improved the initialization part to be idempotent (not perfect but it works ;)
In D817, i used it so the init takes place prior to the server's startup.

This is usable as long as we use the docker-compose.override.yml for now.
the real fix would be to cascade a tag version from swh.core to swh.storage and now to swh.scheduler (tagging them also).

Should i go do the cascading?

lol

isn't there a flag to the runner so that it does it itself?

Checked and no!

can't we move that in dockerfiles/swh-scheduler/scheduler.env?

keeping the configuration file in one location.

What do you mean?

I thought the runner and listener were unrelated, checking.

They are independent, but if we run stuff.
We would also want that the workers consuming stuff have their tasks updated when they are done (that's the listener's job).

Is that why you drew the deps here?

Should i go do the cascading?

yes!

Why exec sh -c instead of directly running the loop?

I just used what's in the systemd service file.

@douardda That's because systemd doesn't run commands in an actual shell. It's not needed here.

yes!

It's in progress btw (core is deployed and pushed to pypi, storage and scheduler should be soon too).

Done, we can now merge the db initialization step and the starting one (cf. D817).

And remove the --no-create!

can't we move that in dockerfiles/swh-scheduler/scheduler.env?

we could be this env file is not part of the docker image building process, it's really part of the compose orchestration one. So it's not about 'put all config files in one location' actually.

At some point we may need/want to split the docker image generation away from the compose (orchestration) part.

What do you mean?
I thought the runner and listener were unrelated, checking.

yes they are. The dependency is there just so the swh/scheduler-worker image is built when starting the runner. Which is a reason why I said in my previous comment:

At some point we may need/want to split the docker image generation away from the compose (orchestration) part.

Is that why you drew the deps here?

it's really is just a simple technical deps due to the fact both services share the same image and the fact we do use docker-compose to build them.

It's not needed here.

if we want to keep the exec command, we need it. And I'm inclined to think it's best to keep the exec statement instead of running the for loop from within the case block.

What if we just repeat build: ./dockerfiles/swh-scheduler-worker in this service declaration?

log says swh-storage, should say swh-scheduler.

i missed that, should have been scheduling_db: swh-scheduler, D838 fixes that.

i missed that, should have been scheduling_db: service=swh-scheduler, D838 fixes that.