search

OCR-D / ocrd-webapi-implementation

4 stars 0 forks source link

Adaption to core PR processing server #23

Closed joschrew closed 1 year ago

joschrew commented 1 year ago

this comment is for the first 2 commits

Reason for he changes: The Webapi is used together with the processing-server. The processing server starts the workers on localhost as the user provided in the configuration file. This is usually not root but the "normal" user (typically user-id 1000). I think it would not be a good idea to use root for that, as the processing-workers are not run in docker or another way of isolation. Because of that files created by the webapi must be writable by the processing-workers and thus by the "normal" user (The webapi "creates" the files when users upload their workspaces and the webapi "spills" them). To do that at first I just run the webapi with docker-compose and use user: 1000:1000 inside so that the workspaces created had the needed owner. That worked fine until I tried to run workflows with the webapi as well. When the user is changed this way nextflow does not run due to several reasons. The changes I made to the Dockerfile bypass these problems.

Maybe it is a good idea to give the opportunity to get some feedback so I created this pull request. I am not sure if there are better ways to achieve the same. Usually inside containers everything is just run as root, I am not sure why, maybe I am missing something.

joschrew commented 1 year ago

this comment is for commit 3

In the core-PR-974 the workspace-model was changed. The workspace-id is now no longer stored in _id field of the workspace but in workspace_id. Both models have to be interoperable to be able to use the webapi with the processing-server. This commit changes the model and adapts tests and some functionalities to that.

MehmedGIT commented 1 year ago

Since breaking changes were introduced, I am merging and releasing v0.10.0 out of this.