Open kba opened 1 year ago
Discussion continued as follows:
A central static tool JSON list is of course a solution for now, but generally IMO we must overcome this. The tools actually deployed might change – even dynamically – and new tools may arrive (cf. discussion on fallback queues). We could have the workers respond with their tool JSON immediately after startup, couldn't we?
The Processing Server then will know only the tool JSON of the started Processing Workers. In case another worker is started manually and the queue for it is created manually, the Processing Server will not be able to validate it's parameters or return it's ocrd tool when requested.
Oh, right. So for unmanaged queues, we would still need a mechanism to advertise/register the tool.
This is not a problem when the Processor Servers are available. The Processing Server can then just request each specific Processor Server for the ocrd_tool and cache.
You mean Processor Servers besides Processor Workers? ... and in the Processing Server model we don't use Processor Servers, do we?
No, we don't. That's why this tool thing is complicated. There is no way of the Processing Server knowing or receiving the tool directly from the Processing Worker ... Another route, a better one, would be to provide "register worker" end point to the Processing Server and pass the ocrd tool there. Once the deployer is separated, the deployer will deploy the Processing Workers and register them to the Processing Server together with their ocrd tool json
Yes, explicit worker registration might be the better cooperation model anyway. So I'd say the Processing Worker should respond with its tool JSON when created. If the creator is the Processing Server, then it can update its internal tool JSON cache. If it is some external actor, they must send that tool JSON along with the tool name within some (to be defined) worker registration endpoint. So ultimately, the Processing Server can be extended dynamically, but only via explicit registration. (And if we do that, we can as well have that endpoint create the queue itself.)
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 startup), and that new Processing Workers should output their ocrd-tool.json
immediately, so that can be used by the registration to store all JSONs in a tool cache dynamically.
BTW I believe for the full Web API including /discovery
, we would need central worker registration anyway.
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 startup)
This will come after #1030. #1030 will already be big to handle that change inside as well. What I currently have in mind for the near future is:
ProcessingServerConfig
will rather be called DeployerConfig
Processing Server
will know nothing about configurations anymoreDeployerConfig
will potentially be extended to be able to deploy Workflow Server
and Workspace Servers
(in the reference WebAPI impl) as wellDeployer agent
will deploy RabbitMQ Server
, MongoDB
, and Processing Server
as a 1st stepDeployer
will deploy Processing Workers
and Processor Servers
as a 2nd stepDeployer
will register the deployed agents in step 2 to the Processing Server
through an endpoint (separate endpoint for each).Processing Server
will then create the Process Queues
(i.e., RabbitMQ Queues) based on the registered Processing Workers
Process Queue
with the same name as the registered worker processor name already exists, no queue will be createdAny other suggestions/modifications?
Ideas for a bit later in time (not even sure for when):
Observer agent
can be introduced to observe the live status of the deployed agents by pinging them every then and now. Processing Workers
are not servers. However, maybe there is an easy way to find their live status through the RabbitMQ Server since they are registered there as Consumers
.Processing Workers
and Processor Servers
registered through the Processing Server
after the deployment stage may be more complicated to register to the Observer
.Disclaimer: Potentially, this will be too time-consuming to implement and cause errors without having good automatic testing mechanisms for the entire network and agents working together.
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 - i.e., which network agent takes responsibility to handle the central registration. This is currently the Processing Server
.
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 - i.e., which network agent takes responsibility to handle the central registration. This is currently the
Processing Server
.
Yes, it makes most sense there, because the Processing Server is the one that needs to know who to talk to anyway. So via registration it has the ultimate truth on processor_list
etc. and could provide its own /discovery
, which can be delegated to by the Workflow Server's /discovery
.
Deployments should also be backed by the database BTW, in case the PS crashes...
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
needs to be extended? Say the client wants to discover available Workspace/Workflow servers. Then the Deployer has the central knowledge of where things were deployed.
Deployments should also be backed by the database BTW, in case the PS crashes...
Agree.
the
DeployerConfig
will potentially be extended to be able to deployWorkflow Server
andWorkspace Servers
(in the reference WebAPI impl) as wellthe
Deployer
agent will deployRabbitMQ Server
,MongoDB
...
These are no longer valid... The RabbitMQ Server, MongoDB, Workflow Server, and Workspace Server will be deployed with docker-compose.
@tdoan2010
I don't know how the discussion went to this topic, which is completely not relevant to the title of this issue. But yes, the Processing Server will only be responsible for Processor Servers. The rest must be managed by another way outside the Processing Server.
The final goal is to have a docker-compose
file, which can be used to start up all necessary components.
@tdoan2010:
@bertsky:
@MehmedGIT: