Mehmed Mustafa

> So we seem to agree that all workers ( / processor queues) should be registered ( / created) centrally on the Processing Server (via endpoint or from configuration at...

Ideas for a bit later in time (not even sure for when): - to increase the robustness of the entire network, an `Observer agent` can be introduced to observe the...

> BTW I believe for the full Web API including /discovery, we would need central worker registration anyway. True. We still need to think about how exactly this should happen...

> Yes, it makes most sense there, because the Processing Server is the one that needs to know who to talk to anyway. For processing, yes. What if the `/discovery`...

> the `DeployerConfig` will potentially be extended to be able to deploy `Workflow Server` and `Workspace Servers` (in the reference WebAPI impl) as well > the `Deployer` agent will deploy...

Today I tried to pull `ocrd_all` on my local machine a few times and always ended up with `failed to register layer: max depth exceeded`. May it also be related...

@bertsky we have briefly discussed with @kba about that after the tech call. Some of the commands could be abstracted away in separate script/s and called with a single RUN...

> How about trying to reactivate our parallel build again? Please also consider the cases in which the build is broken with an interruption. Rerunning the build should remove the...

> I don't remember, sry. Can you please elaborate? AFAIR, there were some files created under the `~/.parallel` folder when installing `ocrd_all` natively. If a CTRL+C interrupted the build, rerunning...

> Oh that! Yes, that can happen. Not sure how to fix this (I guess it's really a GNU parallel issue). Just deleting the `~/.parallel` folder if existing at the...