-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replaces flask with fastapi monitor #45
Replaces flask with fastapi monitor #45
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very good implementation! Especially the separation of monitor server and lib I like quite well.
Could only contribute this review for now with my modest Python knowledge.
But I will have a look at the modules you used and then go deeper into the source code.
From my point of view it would make sense to document some functions later on. (As you have already mentioned in the PR description) Maybe we could also use "doctest" for the functionality tests of the modules.
I will check out the source code next week and try to get further into it. Currently I can't give more feedback.
Here is the summary of the test on Monday. The initial condition was the test with the current version of the base repository and the Manager module on this branch.
|
ddec95d
to
dcc340f
Compare
See SvenMarcus#1
should be fixed now
The problem here is that the workflow files are only in ocrd_manager (e.g. Since we want to make all of these editable and perhaps even version-control them, IMO we have to introduce an additional volume, shared by both the Manager and the Monitor.
should be fixed now
should be fixed now
I agree. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Test results for me (running under SvenMarcus#1): 3 failed, 27 passed, 6 errors
(But I don't understand how I am supposed to set this up within the Compose framework properly. Also, it seems I'd have to include some .env Setting for ocrd_logview
now...)
Integration test within ocrd_kitodo works, but I am having serious issues with the OCRD Browser:
- if I open the same workspace on different tabs, each one steals the session of the other
- if I open a workspace which fails the browser, e.g.
testdata-presentation/mets.xml
aftermake test-presentation
due to Support remote images hnesk/browse-ocrd#52, then subsequently no browser will work anymore, anywhere
relative paths and redirects
…dundant comment in init.sh
With the latest commits, I believe this PR should be ready to be merged now. While the code is not perfect yet, we should be able to further improve it from the main branch. |
Thx! 👍🏻 Unfortunately I get a 404 when I try to open the default workflow because the path is assembled incorrectly
Can you open a issue to see what specifically needs to be changed? This would also have to be taken into account in further implementation. |
Like I said above, the reason for this is not in the Monitor (code), but in the way we currently set up the division of labour between containers. The workflows are only in the Manager. We'd first have to define a shared volume. |
Here's one: #46 |
One thing that must be updated before merging though: the |
Ok I overlooked this. I think the adjustment is divided into OCR-D Manager and Monitor Repo and it is one repo atm. How had we made the workflows visible in the monitor before? |
That's independent, though. Containers/volumes are one thing, repos another.
We had a copy of the workflow in the process directory. |
Ah ok then it worked before because our demo data brought the workflow. By default, there is no workflow in the process dir, but only if it is configured in Kitodo.Production. Then we fix that separately. |
How were we left with the Python test? Should a image or container be created with e.g. DockerfileTest here which contains the dependencies or should the depended code to Python 10 be adjusted? In my case test do not run through yet.
A small docu would be helpful here to perform the tests (#45 (comment)) so that not everything is assumed or you have to orientate yourself on the source. From my point of view, we can solve the runnability of the tests later, because initially the Flask application came even without tests. |
I think this may be a problem with an outdated pip installation on your system: The |
Unfortunately this did not helped. Have the latest version and before that the previous bugfix version.
My question was also whether we should install all the requirements on the host (then a venv would be great) or whether we should just build an image temporarily and start it as a container. |
my locale Which python version an pip version do you use? |
As workaround i can run the test with following command |
@SvenMarcus if you still make the discussed documentation adjustment we can merge the branch. 🚀 |
Adds first draft for FastAPI ocrd monitor implementation.
There are still several things that are still very WIP.
Settings
Until settings are finalized, I have hardcoded them in the monitor's
init.sh
. Eventually they should be parsed from existing variables or new variables that can be added to the main.env
file.When reviewing, please check if I got all the paths to workspaces and so on correctly.
I intended to use
pydantic
's automatic settings management that is able to automatically parse environment variables or an env file into a settings object (see pydantic docs). Unfortunately it doesn't handle environment variables that are named exactly like sub settings classes very well. Therefore I had to prefix my new setting environment variables withOCRD_
, since we already had variables starting withCONTROLLER
.Jobs page
I'm not sure I got all the links on the jobs page correctly. Especially, the links to the log files were a bit wonky in my testing, but could be because of all the changes I made during the implementation.
Testing
While I've written some tests for core logic, I'd like to expand tests for the web application a bit more in the future. This will probably involve setting up some dummy workspaces and mocking out the controller.
Documentation
Since the end user will probably only have to deal with setting up some new variables, I haven't added any documentation for that until we finalize all the settings we need.