Scenario builder: Executable GloWPa command/service

[Katsivelisp]

We discussed the possibility of turning the R package of GloWPa into a service, ideally without having users to install all necessary libraries themselves.

The above could be done by creating a Docker image, but it might also be challenging for people to install and configure Docker. Also, they would need to mount data into a volume, which might be difficult.

Another alternative could be that users actually install the model via the standard procedure. Then, as part of the Scenario builder, we can create a Python wrapper of the R model (eg. with rpy2) that orchestrates the way that the model is invoked. This of course is for more advanced users.

@nauta008 any thoughts/ideas are welcome.

[nauta008]

I've created a more lightweight docker image for only executing the model. You can pull it from docker-registry.wur.nl/glowpa/glowpa-r/glowpa-main:0.2.1

Currently it launches a R terminal when you create a container. In the R terminal you could try:

example("glowpa_start", echo = FALSE)

We can modify the startup command to invoke R command executing the model with a specific configuration file. Or we could use plumber again to launch model executions using API calls. Similar to K2P. What would work best in the current architecture?

[nauta008]

I heard you cannot pull the image due to permission issues. Is that right? It seems public though. I can access the container from an incognito browser.

[Katsivelisp]

Hi @nauta008, I can't, I am directed to a login page. Is it possible that you are signed-in by default with SSO?

[nauta008]

docker pull docker-registry.wur.nl/glowpa/glowpa-r/glowpa-main:0.2.1 does not work for you and you are redirected to login page?

[Katsivelisp]

Duh... I'm sorry, you're right. I was just clicking on the URL, thinking it was some landing page. I built the container, it works.

[Katsivelisp]

@nauta008 I think we need to make sure that users can run the containerised model with data and configuration files from their local filesystem. At the same time, the model should write outputs in the local file system or "return" them through REST. For example, I made this docker-compose.yml:

services:
  glowpa:
    image: docker-registry.wur.nl/glowpa/glowpa-r/glowpa-main:0.2.1
    container_name: glowpa-container
    ports:
      - "8080:8080"
    volumes:
      - ./data/input:/app/input       # Mount local input directory
      - ./data/output:/app/output     # Mount local output directory
      - ./data/config:/app/config     # Mount local config directory (optional)
    networks:
      - app-network
    tty: true
    stdin_open: true

This maps some custom folders to the directories that could be read by GloWPa. So we configure GloWPa to only use those folders.

On another note, how would someone invoke the model from outside the container, without opening a terminal? I think maybe the API is the only way.

[nauta008]

Maybe, we can run another container with a simple user interface and launch the containerized model from there?

[nauta008]

You can for example invoke the model startup command. Below I'm running the example inside the container:

docker run glowpa-main:0.2.1 Rscript -e 'library(glowpa);example("glowpa_start")'

Running an actual model config should be something like:

docker run -v ./data/input:/app/input:ro -v ./data/output:/app/output:rw -v ./data/config:/app/config:ro glowpa-main:0.2.1 Rscript -e 'library(glowpa);glowpa_init(app/config/settings.yaml);glowpa_start()'

or to keep the container alive:

docker run -dit --name glowpa-container -v ./data/input:/app/input:ro -v ./data/output:/app/output:rw -v ./data/config:/app/config:ro glowpa-main:0.2.1 tail -f /dev/null

and

docker exec -it glowpa-container Rscript -e 'library(glowpa);glowpa_init(app/config/settings.yaml);glowpa_start()'

[Katsivelisp]

Yes, I was thinking that the Scenario Builder could have something like a status screen that allows you to see if the model container is running and stop/start/restart it.

The commands seem fine to me. We just need to make sure that the model always uses the same folders for input/output. Is it like that right now?

[nauta008]

The model is flexible and allows input files from different folders. All input files need to be specified in the yaml file. So I think this is something we should embed in the ecosystem of services. The yaml file also has a mandatory placeholder to specify the output directory.