Conversation
| nginx: | ||
| condition: service_started # used for routing to MinIO and PHP REST API |
There was a problem hiding this comment.
I wasn't sure whether to keep the nginx around for the 'light' version. For now, I figured to keep it truly minimal. It's easy enough to specify docker compose up python-api-light nginx if you do want the routing to be available.
| The Python REST API is also available in a 'light' mode that allows for database interactions | ||
| but does not allow for file uploads/downloads. It has to be started directly (as opposed to | ||
| through a profile): | ||
| ```bash | ||
| docker compose up python-rest-api-light -d | ||
| docker compose down | ||
| ``` | ||
| While it is up, the API is available under `http://localhost:8082`, e.g., `http://localhost:8082/datasets/1`. | ||
|
|
There was a problem hiding this comment.
I cannot simply add a profile to the service as it is defined right now, since the python-rest-api service will also get that profile (due to extends) but the other dependencies of the python-rest-api (e.g., php-api) will not have that profile (and should not have the profile, since we don't want to start them).
I think this is perfectly fine, we are probably defining too many profiles in the first place. But if we do want to keep using profiles even for single services, then we could work around that with yaml anchoring, e.g.
python-api-light:
profiles: ["rest-api-light"]
- image: openml/rest-api:0.0.1-alpha
+ image: &python-api-image openml/rest-api:0.0.1-alpha # define anchor
and then
python-api:
profiles: ["all", "rest-api"] # only its own profiles, not merged
- extends: python-api-light
+ image: *python-api-image # copied from python-api-light
omosola
left a comment
omosola
left a comment
There was a problem hiding this comment.
Moving the review to @josvandervelde.
Thanks for putting in this fix @PGijsbers!
2 participants
This patch introduces a way to spin up a 'light weight' Python REST API that supports database interactions and nothing else (e.g., no downloading of files). This should cover most use cases for testing the API and is faster to start (and less resource intensive).
Also fixes #17.