feature/enhanced deploy

.streamlit/secrets.toml

@@ -1,4 +1,4 @@
-auth_type='oidc'
+auth_type='simple'
 
 user='admin'
 password='password'

Makefile

@@ -0,0 +1,18 @@
+#!make
+include .env
+
+build:
+	docker build -f oasisui_st_app.Dockerfile . -t ${PYTHONUI_IMG}:${VERS_UI}
+
+push:
+	docker push ${PYTHONUI_IMG}:${VERS_UI}
+
+scenarios_portfolios:
+	python ./scripts/add_test_portfolios.py -c ./scenarios/portfolios.json
+
+scenarios_settings:
+	python ./scripts/add_settings_template.py -c ./scenarios/a_settings.json
+
+scenarios: scenarios_portfolios scenarios_settings
+
+build_and_push: build push

README.md

@@ -65,9 +65,16 @@ echo "127.0.0.1 ui.oasis.local" | sudo tee -a /etc/hosts
 ./install.sh
 ```
 
-The installer clones the PiWind demo model, processes OIDC templates (if
-applicable), builds the UI image, and starts all services. It will prompt
-before redeploying if a previous installation is detected.
+The installer stages the model data for the selected model set, processes OIDC
+templates (if applicable), pulls the images, and starts all services. It will
+prompt before redeploying if a previous installation is detected.
+
+| Option | Description |
+|--------|-------------|
+| `-m`, `--model-set <name>` | Model set to deploy. Defaults to `MODEL_SET` from `.env`, or `piwind`. |
+| `--build-ui` | Build the UI image locally instead of pulling `PYTHONUI_IMG:VERS_UI`. |
+| `-u`, `--uninstall` | Bring the stack down and delete its volumes. |
+| `-h`, `--help` | Show usage. |
 
 To tear everything down (removes containers and volumes):
 
@@ -104,19 +111,82 @@ All services are reachable on port 80 via Traefik after a successful install:
 
 ## Docker Compose Architecture
 
-The stack is assembled from multiple Compose files depending on auth type:
+`install.sh` layers several Compose files into a single `docker compose`
+command. The model workers live in a file of their own, so the core platform,
+the UI and the auth stack stay model-agnostic:
 
 ```
 Always loaded:
- docker-compose.yml # Core platform: server, worker, databases, broker
- docker-compose.ui.yml # Streamlit UI + Traefik reverse proxy
+ docker-compose.yml # Core platform: Traefik, server, websocket, databases, broker, filestore
+ docker-compose.models.<model-set>.yml # Model workers and model registration for one model set
+ docker-compose.ui.yml # Streamlit UI
 
 Conditionally loaded:
- docker-compose.keycloak.yml # Keycloak + its PostgreSQL DB (API_AUTH_TYPE=keycloak)
+ docker-compose.keycloak.yml # Keycloak + its PostgreSQL DB (API_AUTH_TYPE=keycloak)
  docker-compose.authentik.yml # Authentik + its PostgreSQL DB (API_AUTH_TYPE=authentik)
 ```
 
-`install.sh` builds the correct `docker compose -f ... up` command automatically.
+### Model sets — `docker-compose.models.<model-set>.yml`
+
+`docker-compose.yml` defines no model workers at all. Everything
+model-specific is confined to a `docker-compose.models.<model-set>.yml` file:
+
+- one worker service per model, carrying its `OASIS_MODEL_SUPPLIER_ID`,
+ `OASIS_MODEL_ID`, `OASIS_MODEL_VERSION_ID` and `OASIS_RUN_MODE`
+- the volume mount that supplies that model's data
+- any `model-registration` job needed to register the models with the API
+
+Exactly one model set is loaded per deployment. Pick it with `-m/--model-set`,
+or set `MODEL_SET` in `.env` so a bare `./install.sh` deploys it:
+
+```bash
+./install.sh -m piwind # default: the PiWind demo model
+./install.sh -m scenarios # PiWind plus the public scenario models
+```
+
+Model sets shipped in this repository:
+
+| File | Contents |
+|------|----------|
+| `docker-compose.models.piwind.yml` | A `model-registration` one-shot and `piwind-worker`, with model data from `./OasisPiWind/`. |
+| `docker-compose.models.scenarios.yml` | `piwind-worker` plus the scenario workers (Impact Forecasting, JBA, ARA, IPE), with model data from `${SCENARIOS_PATH}`. |
+
+Because the split is by filename, adding a model set means dropping two new
+files into the root directory — no edits to `docker-compose.yml`, `install.sh`
+or the auth files:
+
+1. Write `docker-compose.models.<name>.yml` with the worker services. The
+ workers join the core stack, so they can depend on `server`, `celery-db` and
+ `broker` and mount the shared `filestore-data` volume directly.
+2. Optionally add `get-<name>.sh` to fetch the model data (see below).
+3. Deploy with `./install.sh -m <name>`.
+
+`install.sh --uninstall` passes *every* `docker-compose.models.*.yml` to
+`docker compose down`, so the model workers are torn down whichever set was
+deployed.
+
+#### Model data — `get-<model-set>.sh`
+
+The Compose file describes how a model runs; the matching `get-<model-set>.sh`
+puts its data on disk. Before bringing the stack up, `install.sh` runs
+`get-$MODEL_SET.sh` if it exists, and otherwise assumes the data is already in
+place.
+
+| Script | What it does |
+|--------|--------------|
+| `get-piwind.sh` | Clones `OasisLMF/OasisPiWind` at `VERS_PIWIND` into `./OasisPiWind/`. No-ops once cloned. |
+| `get-scenarios.sh` | Runs `get-piwind.sh`, clones `OasisLMF/Scenarios` into `$SCENARIOS_PATH`, then runs that repository's `get_s3_data_reduced.sh` to download the model files. Each step is skipped if it has already been done. |
+
+The scripts are idempotent and safe to run on their own, which is the easy way
+to pre-stage model data on a server before deploying, or to refresh it without
+a redeploy:
+
+```bash
+SCENARIOS_PATH=/home/ubuntu/Scenarios ./get-scenarios.sh
+```
+
+When writing your own, keep it re-runnable: `install.sh` calls it on every
+deploy, including redeploys over an existing installation.
 
 ## Key Environment Variables
 
@@ -131,6 +201,25 @@ Conditionally loaded:
 
 See the `.env.*` templates for the full list with inline comments.
 
+### Deployment overrides
+
+These variables decide *what* gets deployed and *what the UI shows*, rather
+than how the platform is wired together. They are read straight from `.env` by
+`install.sh` and the Compose files, and each falls back to the layout in this
+repository — so a plain checkout still deploys unchanged with none of them set.
+They are not in the `.env.*` templates; add the ones a deployment needs.
+
+| Variable | Default | Purpose |
+|----------|---------|---------|
+| `MODEL_SET` | `piwind` | Which `docker-compose.models.<name>.yml` / `get-<name>.sh` pair to deploy. `-m/--model-set` overrides it for one run. |
+| `SCENARIOS_PATH` | *(unset)* | Host directory holding the scenario model data. Required by the `scenarios` model set — both `get-scenarios.sh` and the worker mounts read it. |
+| `UI_CONFIG` | `./ui-config.json` | The UI's config file: pages, post-login page, model-to-exposure map, footer, and `skip_login`. |
+| `UI_DEFAULTS` | `./defaults/` | Per-model default analysis settings the UI pre-fills when creating an analysis. |
+| `UI_ASSETS` | `./ui_assets/` | Files `UI_CONFIG` refers to as `ui_assets/<file>` — footer text, logos, anything a deployment supplies. |
+| `UI_STREAMLIT` | `./.streamlit/` | The Streamlit directory mounted read-only: `secrets.toml` and `config.toml`. |
+| `PYTHONUI_IMG` / `VERS_UI` | `coreoasis/oasispythonui_app` / `latest` | UI image pulled at deploy time, and the tag `make build` / `make push` produce. |
+
+
 ## Adding Users
 
 ### Simple auth
@@ -166,6 +255,10 @@ Usually first thing to try before anything is clearing browser cache/cookies for
 - The IdP database container must be healthy first: `docker compose ps`.
 - First startup can take 2–3 minutes while blueprints and realms are imported.
 
+**`install.sh` exits with `no model set '<name>'`**
+- The model set has no `docker-compose.models.<name>.yml` in the root directory.
+ Check the spelling of `-m/--model-set` or `MODEL_SET`.
+
 **Logs and status**
 ```bash
 docker compose ps # service health

.streamlit/secrets.toml

@@ -1,4 +1,4 @@
-auth_type='oidc'
+auth_type='simple'
 
 user='admin'
 password='password'

Makefile

@@ -0,0 +1,18 @@
+#!make
+include .env
+
+build:
+	docker build -f oasisui_st_app.Dockerfile . -t ${PYTHONUI_IMG}:${VERS_UI}
+
+push:
+	docker push ${PYTHONUI_IMG}:${VERS_UI}
+
+scenarios_portfolios:
+	python ./scripts/add_test_portfolios.py -c ./scenarios/portfolios.json
+
+scenarios_settings:
+	python ./scripts/add_settings_template.py -c ./scenarios/a_settings.json
+
+scenarios: scenarios_portfolios scenarios_settings
+
+build_and_push: build push

README.md

@@ -65,9 +65,16 @@ echo "127.0.0.1 ui.oasis.local" | sudo tee -a /etc/hosts
 ./install.sh
 ```
 
-The installer clones the PiWind demo model, processes OIDC templates (if
-applicable), builds the UI image, and starts all services. It will prompt
-before redeploying if a previous installation is detected.
+The installer stages the model data for the selected model set, processes OIDC
+templates (if applicable), pulls the images, and starts all services. It will
+prompt before redeploying if a previous installation is detected.
+
+| Option | Description |
+|--------|-------------|
+| `-m`, `--model-set <name>` | Model set to deploy. Defaults to `MODEL_SET` from `.env`, or `piwind`. |
+| `--build-ui` | Build the UI image locally instead of pulling `PYTHONUI_IMG:VERS_UI`. |
+| `-u`, `--uninstall` | Bring the stack down and delete its volumes. |
+| `-h`, `--help` | Show usage. |
 
 To tear everything down (removes containers and volumes):
 
@@ -104,19 +111,82 @@ All services are reachable on port 80 via Traefik after a successful install:
 
 ## Docker Compose Architecture
 
-The stack is assembled from multiple Compose files depending on auth type:
+`install.sh` layers several Compose files into a single `docker compose`
+command. The model workers live in a file of their own, so the core platform,
+the UI and the auth stack stay model-agnostic:
 
 ```
 Always loaded:
- docker-compose.yml # Core platform: server, worker, databases, broker
- docker-compose.ui.yml # Streamlit UI + Traefik reverse proxy
+ docker-compose.yml # Core platform: Traefik, server, websocket, databases, broker, filestore
+ docker-compose.models.<model-set>.yml # Model workers and model registration for one model set
+ docker-compose.ui.yml # Streamlit UI
 
 Conditionally loaded:
- docker-compose.keycloak.yml # Keycloak + its PostgreSQL DB (API_AUTH_TYPE=keycloak)
+ docker-compose.keycloak.yml # Keycloak + its PostgreSQL DB (API_AUTH_TYPE=keycloak)
  docker-compose.authentik.yml # Authentik + its PostgreSQL DB (API_AUTH_TYPE=authentik)
 ```
 
-`install.sh` builds the correct `docker compose -f ... up` command automatically.
+### Model sets — `docker-compose.models.<model-set>.yml`
+
+`docker-compose.yml` defines no model workers at all. Everything
+model-specific is confined to a `docker-compose.models.<model-set>.yml` file:
+
+- one worker service per model, carrying its `OASIS_MODEL_SUPPLIER_ID`,
+ `OASIS_MODEL_ID`, `OASIS_MODEL_VERSION_ID` and `OASIS_RUN_MODE`
+- the volume mount that supplies that model's data
+- any `model-registration` job needed to register the models with the API
+
+Exactly one model set is loaded per deployment. Pick it with `-m/--model-set`,
+or set `MODEL_SET` in `.env` so a bare `./install.sh` deploys it:
+
+```bash
+./install.sh -m piwind # default: the PiWind demo model
+./install.sh -m scenarios # PiWind plus the public scenario models
+```
+
+Model sets shipped in this repository:
+
+| File | Contents |
+|------|----------|
+| `docker-compose.models.piwind.yml` | A `model-registration` one-shot and `piwind-worker`, with model data from `./OasisPiWind/`. |
+| `docker-compose.models.scenarios.yml` | `piwind-worker` plus the scenario workers (Impact Forecasting, JBA, ARA, IPE), with model data from `${SCENARIOS_PATH}`. |
+
+Because the split is by filename, adding a model set means dropping two new
+files into the root directory — no edits to `docker-compose.yml`, `install.sh`
+or the auth files:
+
+1. Write `docker-compose.models.<name>.yml` with the worker services. The
+ workers join the core stack, so they can depend on `server`, `celery-db` and
+ `broker` and mount the shared `filestore-data` volume directly.
+2. Optionally add `get-<name>.sh` to fetch the model data (see below).
+3. Deploy with `./install.sh -m <name>`.
+
+`install.sh --uninstall` passes *every* `docker-compose.models.*.yml` to
+`docker compose down`, so the model workers are torn down whichever set was
+deployed.
+
+#### Model data — `get-<model-set>.sh`
+
+The Compose file describes how a model runs; the matching `get-<model-set>.sh`
+puts its data on disk. Before bringing the stack up, `install.sh` runs
+`get-$MODEL_SET.sh` if it exists, and otherwise assumes the data is already in
+place.
+
+| Script | What it does |
+|--------|--------------|
+| `get-piwind.sh` | Clones `OasisLMF/OasisPiWind` at `VERS_PIWIND` into `./OasisPiWind/`. No-ops once cloned. |
+| `get-scenarios.sh` | Runs `get-piwind.sh`, clones `OasisLMF/Scenarios` into `$SCENARIOS_PATH`, then runs that repository's `get_s3_data_reduced.sh` to download the model files. Each step is skipped if it has already been done. |
+
+The scripts are idempotent and safe to run on their own, which is the easy way
+to pre-stage model data on a server before deploying, or to refresh it without
+a redeploy:
+
+```bash
+SCENARIOS_PATH=/home/ubuntu/Scenarios ./get-scenarios.sh
+```
+
+When writing your own, keep it re-runnable: `install.sh` calls it on every
+deploy, including redeploys over an existing installation.
 
 ## Key Environment Variables
 
@@ -131,6 +201,25 @@ Conditionally loaded:
 
 See the `.env.*` templates for the full list with inline comments.
 
+### Deployment overrides
+
+These variables decide *what* gets deployed and *what the UI shows*, rather
+than how the platform is wired together. They are read straight from `.env` by
+`install.sh` and the Compose files, and each falls back to the layout in this
+repository — so a plain checkout still deploys unchanged with none of them set.
+They are not in the `.env.*` templates; add the ones a deployment needs.
+
+| Variable | Default | Purpose |
+|----------|---------|---------|
+| `MODEL_SET` | `piwind` | Which `docker-compose.models.<name>.yml` / `get-<name>.sh` pair to deploy. `-m/--model-set` overrides it for one run. |
+| `SCENARIOS_PATH` | *(unset)* | Host directory holding the scenario model data. Required by the `scenarios` model set — both `get-scenarios.sh` and the worker mounts read it. |
+| `UI_CONFIG` | `./ui-config.json` | The UI's config file: pages, post-login page, model-to-exposure map, footer, and `skip_login`. |
+| `UI_DEFAULTS` | `./defaults/` | Per-model default analysis settings the UI pre-fills when creating an analysis. |
+| `UI_ASSETS` | `./ui_assets/` | Files `UI_CONFIG` refers to as `ui_assets/<file>` — footer text, logos, anything a deployment supplies. |
+| `UI_STREAMLIT` | `./.streamlit/` | The Streamlit directory mounted read-only: `secrets.toml` and `config.toml`. |
+| `PYTHONUI_IMG` / `VERS_UI` | `coreoasis/oasispythonui_app` / `latest` | UI image pulled at deploy time, and the tag `make build` / `make push` produce. |
+
+
 ## Adding Users
 
 ### Simple auth
@@ -166,6 +255,10 @@ Usually first thing to try before anything is clearing browser cache/cookies for
 - The IdP database container must be healthy first: `docker compose ps`.
 - First startup can take 2–3 minutes while blueprints and realms are imported.
 
+**`install.sh` exits with `no model set '<name>'`**
+- The model set has no `docker-compose.models.<name>.yml` in the root directory.
+ Check the spelling of `-m/--model-set` or `MODEL_SET`.
+
 **Logs and status**
 ```bash
 docker compose ps # service health

.streamlit/secrets.toml

@@ -1,4 +1,4 @@
-auth_type='oidc'
+auth_type='simple'
 
 user='admin'
 password='password'

Makefile

@@ -0,0 +1,18 @@
+#!make
+include .env
+
+build:
+	docker build -f oasisui_st_app.Dockerfile . -t ${PYTHONUI_IMG}:${VERS_UI}
+
+push:
+	docker push ${PYTHONUI_IMG}:${VERS_UI}
+
+scenarios_portfolios:
+	python ./scripts/add_test_portfolios.py -c ./scenarios/portfolios.json
+
+scenarios_settings:
+	python ./scripts/add_settings_template.py -c ./scenarios/a_settings.json
+
+scenarios: scenarios_portfolios scenarios_settings
+
+build_and_push: build push

README.md

@@ -65,9 +65,16 @@ echo "127.0.0.1 ui.oasis.local" | sudo tee -a /etc/hosts
 ./install.sh
 ```
 
-The installer clones the PiWind demo model, processes OIDC templates (if
-applicable), builds the UI image, and starts all services. It will prompt
-before redeploying if a previous installation is detected.
+The installer stages the model data for the selected model set, processes OIDC
+templates (if applicable), pulls the images, and starts all services. It will
+prompt before redeploying if a previous installation is detected.
+
+| Option | Description |
+|--------|-------------|
+| `-m`, `--model-set <name>` | Model set to deploy. Defaults to `MODEL_SET` from `.env`, or `piwind`. |
+| `--build-ui` | Build the UI image locally instead of pulling `PYTHONUI_IMG:VERS_UI`. |
+| `-u`, `--uninstall` | Bring the stack down and delete its volumes. |
+| `-h`, `--help` | Show usage. |
 
 To tear everything down (removes containers and volumes):
 
@@ -104,19 +111,82 @@ All services are reachable on port 80 via Traefik after a successful install:
 
 ## Docker Compose Architecture
 
-The stack is assembled from multiple Compose files depending on auth type:
+`install.sh` layers several Compose files into a single `docker compose`
+command. The model workers live in a file of their own, so the core platform,
+the UI and the auth stack stay model-agnostic:
 
 ```
 Always loaded:
- docker-compose.yml # Core platform: server, worker, databases, broker
- docker-compose.ui.yml # Streamlit UI + Traefik reverse proxy
+ docker-compose.yml # Core platform: Traefik, server, websocket, databases, broker, filestore
+ docker-compose.models.<model-set>.yml # Model workers and model registration for one model set
+ docker-compose.ui.yml # Streamlit UI
 
 Conditionally loaded:
- docker-compose.keycloak.yml # Keycloak + its PostgreSQL DB (API_AUTH_TYPE=keycloak)
+ docker-compose.keycloak.yml # Keycloak + its PostgreSQL DB (API_AUTH_TYPE=keycloak)
  docker-compose.authentik.yml # Authentik + its PostgreSQL DB (API_AUTH_TYPE=authentik)
 ```
 
-`install.sh` builds the correct `docker compose -f ... up` command automatically.
+### Model sets — `docker-compose.models.<model-set>.yml`
+
+`docker-compose.yml` defines no model workers at all. Everything
+model-specific is confined to a `docker-compose.models.<model-set>.yml` file:
+
+- one worker service per model, carrying its `OASIS_MODEL_SUPPLIER_ID`,
+ `OASIS_MODEL_ID`, `OASIS_MODEL_VERSION_ID` and `OASIS_RUN_MODE`
+- the volume mount that supplies that model's data
+- any `model-registration` job needed to register the models with the API
+
+Exactly one model set is loaded per deployment. Pick it with `-m/--model-set`,
+or set `MODEL_SET` in `.env` so a bare `./install.sh` deploys it:
+
+```bash
+./install.sh -m piwind # default: the PiWind demo model
+./install.sh -m scenarios # PiWind plus the public scenario models
+```
+
+Model sets shipped in this repository:
+
+| File | Contents |
+|------|----------|
+| `docker-compose.models.piwind.yml` | A `model-registration` one-shot and `piwind-worker`, with model data from `./OasisPiWind/`. |
+| `docker-compose.models.scenarios.yml` | `piwind-worker` plus the scenario workers (Impact Forecasting, JBA, ARA, IPE), with model data from `${SCENARIOS_PATH}`. |
+
+Because the split is by filename, adding a model set means dropping two new
+files into the root directory — no edits to `docker-compose.yml`, `install.sh`
+or the auth files:
+
+1. Write `docker-compose.models.<name>.yml` with the worker services. The
+ workers join the core stack, so they can depend on `server`, `celery-db` and
+ `broker` and mount the shared `filestore-data` volume directly.
+2. Optionally add `get-<name>.sh` to fetch the model data (see below).
+3. Deploy with `./install.sh -m <name>`.
+
+`install.sh --uninstall` passes *every* `docker-compose.models.*.yml` to
+`docker compose down`, so the model workers are torn down whichever set was
+deployed.
+
+#### Model data — `get-<model-set>.sh`
+
+The Compose file describes how a model runs; the matching `get-<model-set>.sh`
+puts its data on disk. Before bringing the stack up, `install.sh` runs
+`get-$MODEL_SET.sh` if it exists, and otherwise assumes the data is already in
+place.
+
+| Script | What it does |
+|--------|--------------|
+| `get-piwind.sh` | Clones `OasisLMF/OasisPiWind` at `VERS_PIWIND` into `./OasisPiWind/`. No-ops once cloned. |
+| `get-scenarios.sh` | Runs `get-piwind.sh`, clones `OasisLMF/Scenarios` into `$SCENARIOS_PATH`, then runs that repository's `get_s3_data_reduced.sh` to download the model files. Each step is skipped if it has already been done. |
+
+The scripts are idempotent and safe to run on their own, which is the easy way
+to pre-stage model data on a server before deploying, or to refresh it without
+a redeploy:
+
+```bash
+SCENARIOS_PATH=/home/ubuntu/Scenarios ./get-scenarios.sh
+```
+
+When writing your own, keep it re-runnable: `install.sh` calls it on every
+deploy, including redeploys over an existing installation.
 
 ## Key Environment Variables
 
@@ -131,6 +201,25 @@ Conditionally loaded:
 
 See the `.env.*` templates for the full list with inline comments.
 
+### Deployment overrides
+
+These variables decide *what* gets deployed and *what the UI shows*, rather
+than how the platform is wired together. They are read straight from `.env` by
+`install.sh` and the Compose files, and each falls back to the layout in this
+repository — so a plain checkout still deploys unchanged with none of them set.
+They are not in the `.env.*` templates; add the ones a deployment needs.
+
+| Variable | Default | Purpose |
+|----------|---------|---------|
+| `MODEL_SET` | `piwind` | Which `docker-compose.models.<name>.yml` / `get-<name>.sh` pair to deploy. `-m/--model-set` overrides it for one run. |
+| `SCENARIOS_PATH` | *(unset)* | Host directory holding the scenario model data. Required by the `scenarios` model set — both `get-scenarios.sh` and the worker mounts read it. |
+| `UI_CONFIG` | `./ui-config.json` | The UI's config file: pages, post-login page, model-to-exposure map, footer, and `skip_login`. |
+| `UI_DEFAULTS` | `./defaults/` | Per-model default analysis settings the UI pre-fills when creating an analysis. |
+| `UI_ASSETS` | `./ui_assets/` | Files `UI_CONFIG` refers to as `ui_assets/<file>` — footer text, logos, anything a deployment supplies. |
+| `UI_STREAMLIT` | `./.streamlit/` | The Streamlit directory mounted read-only: `secrets.toml` and `config.toml`. |
+| `PYTHONUI_IMG` / `VERS_UI` | `coreoasis/oasispythonui_app` / `latest` | UI image pulled at deploy time, and the tag `make build` / `make push` produce. |
+
+
 ## Adding Users
 
 ### Simple auth
@@ -166,6 +255,10 @@ Usually first thing to try before anything is clearing browser cache/cookies for
 - The IdP database container must be healthy first: `docker compose ps`.
 - First startup can take 2–3 minutes while blueprints and realms are imported.
 
+**`install.sh` exits with `no model set '<name>'`**
+- The model set has no `docker-compose.models.<name>.yml` in the root directory.
+ Check the spelling of `-m/--model-set` or `MODEL_SET`.
+
 **Logs and status**
 ```bash
 docker compose ps # service health

.streamlit/secrets.toml

@@ -1,4 +1,4 @@
-auth_type='oidc'
+auth_type='simple'
 
 user='admin'
 password='password'

Makefile

@@ -0,0 +1,18 @@
+#!make
+include .env
+
+build:
+	docker build -f oasisui_st_app.Dockerfile . -t ${PYTHONUI_IMG}:${VERS_UI}
+
+push:
+	docker push ${PYTHONUI_IMG}:${VERS_UI}
+
+scenarios_portfolios:
+	python ./scripts/add_test_portfolios.py -c ./scenarios/portfolios.json
+
+scenarios_settings:
+	python ./scripts/add_settings_template.py -c ./scenarios/a_settings.json
+
+scenarios: scenarios_portfolios scenarios_settings
+
+build_and_push: build push

README.md

@@ -65,9 +65,16 @@ echo "127.0.0.1 ui.oasis.local" | sudo tee -a /etc/hosts
 ./install.sh
 ```
 
-The installer clones the PiWind demo model, processes OIDC templates (if
-applicable), builds the UI image, and starts all services. It will prompt
-before redeploying if a previous installation is detected.
+The installer stages the model data for the selected model set, processes OIDC
+templates (if applicable), pulls the images, and starts all services. It will
+prompt before redeploying if a previous installation is detected.
+
+| Option | Description |
+|--------|-------------|
+| `-m`, `--model-set <name>` | Model set to deploy. Defaults to `MODEL_SET` from `.env`, or `piwind`. |
+| `--build-ui` | Build the UI image locally instead of pulling `PYTHONUI_IMG:VERS_UI`. |
+| `-u`, `--uninstall` | Bring the stack down and delete its volumes. |
+| `-h`, `--help` | Show usage. |
 
 To tear everything down (removes containers and volumes):
 
@@ -104,19 +111,82 @@ All services are reachable on port 80 via Traefik after a successful install:
 
 ## Docker Compose Architecture
 
-The stack is assembled from multiple Compose files depending on auth type:
+`install.sh` layers several Compose files into a single `docker compose`
+command. The model workers live in a file of their own, so the core platform,
+the UI and the auth stack stay model-agnostic:
 
 ```
 Always loaded:
- docker-compose.yml # Core platform: server, worker, databases, broker
- docker-compose.ui.yml # Streamlit UI + Traefik reverse proxy
+ docker-compose.yml # Core platform: Traefik, server, websocket, databases, broker, filestore
+ docker-compose.models.<model-set>.yml # Model workers and model registration for one model set
+ docker-compose.ui.yml # Streamlit UI
 
 Conditionally loaded:
- docker-compose.keycloak.yml # Keycloak + its PostgreSQL DB (API_AUTH_TYPE=keycloak)
+ docker-compose.keycloak.yml # Keycloak + its PostgreSQL DB (API_AUTH_TYPE=keycloak)
  docker-compose.authentik.yml # Authentik + its PostgreSQL DB (API_AUTH_TYPE=authentik)
 ```
 
-`install.sh` builds the correct `docker compose -f ... up` command automatically.
+### Model sets — `docker-compose.models.<model-set>.yml`
+
+`docker-compose.yml` defines no model workers at all. Everything
+model-specific is confined to a `docker-compose.models.<model-set>.yml` file:
+
+- one worker service per model, carrying its `OASIS_MODEL_SUPPLIER_ID`,
+ `OASIS_MODEL_ID`, `OASIS_MODEL_VERSION_ID` and `OASIS_RUN_MODE`
+- the volume mount that supplies that model's data
+- any `model-registration` job needed to register the models with the API
+
+Exactly one model set is loaded per deployment. Pick it with `-m/--model-set`,
+or set `MODEL_SET` in `.env` so a bare `./install.sh` deploys it:
+
+```bash
+./install.sh -m piwind # default: the PiWind demo model
+./install.sh -m scenarios # PiWind plus the public scenario models
+```
+
+Model sets shipped in this repository:
+
+| File | Contents |
+|------|----------|
+| `docker-compose.models.piwind.yml` | A `model-registration` one-shot and `piwind-worker`, with model data from `./OasisPiWind/`. |
+| `docker-compose.models.scenarios.yml` | `piwind-worker` plus the scenario workers (Impact Forecasting, JBA, ARA, IPE), with model data from `${SCENARIOS_PATH}`. |
+
+Because the split is by filename, adding a model set means dropping two new
+files into the root directory — no edits to `docker-compose.yml`, `install.sh`
+or the auth files:
+
+1. Write `docker-compose.models.<name>.yml` with the worker services. The
+ workers join the core stack, so they can depend on `server`, `celery-db` and
+ `broker` and mount the shared `filestore-data` volume directly.
+2. Optionally add `get-<name>.sh` to fetch the model data (see below).
+3. Deploy with `./install.sh -m <name>`.
+
+`install.sh --uninstall` passes *every* `docker-compose.models.*.yml` to
+`docker compose down`, so the model workers are torn down whichever set was
+deployed.
+
+#### Model data — `get-<model-set>.sh`
+
+The Compose file describes how a model runs; the matching `get-<model-set>.sh`
+puts its data on disk. Before bringing the stack up, `install.sh` runs
+`get-$MODEL_SET.sh` if it exists, and otherwise assumes the data is already in
+place.
+
+| Script | What it does |
+|--------|--------------|
+| `get-piwind.sh` | Clones `OasisLMF/OasisPiWind` at `VERS_PIWIND` into `./OasisPiWind/`. No-ops once cloned. |
+| `get-scenarios.sh` | Runs `get-piwind.sh`, clones `OasisLMF/Scenarios` into `$SCENARIOS_PATH`, then runs that repository's `get_s3_data_reduced.sh` to download the model files. Each step is skipped if it has already been done. |
+
+The scripts are idempotent and safe to run on their own, which is the easy way
+to pre-stage model data on a server before deploying, or to refresh it without
+a redeploy:
+
+```bash
+SCENARIOS_PATH=/home/ubuntu/Scenarios ./get-scenarios.sh
+```
+
+When writing your own, keep it re-runnable: `install.sh` calls it on every
+deploy, including redeploys over an existing installation.
 
 ## Key Environment Variables
 
@@ -131,6 +201,25 @@ Conditionally loaded:
 
 See the `.env.*` templates for the full list with inline comments.
 
+### Deployment overrides
+
+These variables decide *what* gets deployed and *what the UI shows*, rather
+than how the platform is wired together. They are read straight from `.env` by
+`install.sh` and the Compose files, and each falls back to the layout in this
+repository — so a plain checkout still deploys unchanged with none of them set.
+They are not in the `.env.*` templates; add the ones a deployment needs.
+
+| Variable | Default | Purpose |
+|----------|---------|---------|
+| `MODEL_SET` | `piwind` | Which `docker-compose.models.<name>.yml` / `get-<name>.sh` pair to deploy. `-m/--model-set` overrides it for one run. |
+| `SCENARIOS_PATH` | *(unset)* | Host directory holding the scenario model data. Required by the `scenarios` model set — both `get-scenarios.sh` and the worker mounts read it. |
+| `UI_CONFIG` | `./ui-config.json` | The UI's config file: pages, post-login page, model-to-exposure map, footer, and `skip_login`. |
+| `UI_DEFAULTS` | `./defaults/` | Per-model default analysis settings the UI pre-fills when creating an analysis. |
+| `UI_ASSETS` | `./ui_assets/` | Files `UI_CONFIG` refers to as `ui_assets/<file>` — footer text, logos, anything a deployment supplies. |
+| `UI_STREAMLIT` | `./.streamlit/` | The Streamlit directory mounted read-only: `secrets.toml` and `config.toml`. |
+| `PYTHONUI_IMG` / `VERS_UI` | `coreoasis/oasispythonui_app` / `latest` | UI image pulled at deploy time, and the tag `make build` / `make push` produce. |
+
+
 ## Adding Users
 
 ### Simple auth
@@ -166,6 +255,10 @@ Usually first thing to try before anything is clearing browser cache/cookies for
 - The IdP database container must be healthy first: `docker compose ps`.
 - First startup can take 2–3 minutes while blueprints and realms are imported.
 
+**`install.sh` exits with `no model set '<name>'`**
+- The model set has no `docker-compose.models.<name>.yml` in the root directory.
+ Check the spelling of `-m/--model-set` or `MODEL_SET`.
+
 **Logs and status**
 ```bash
 docker compose ps # service health

.streamlit/secrets.toml

@@ -1,4 +1,4 @@
-auth_type='oidc'
+auth_type='simple'
 
 user='admin'
 password='password'

Makefile

@@ -0,0 +1,18 @@
+#!make
+include .env
+
+build:
+	docker build -f oasisui_st_app.Dockerfile . -t ${PYTHONUI_IMG}:${VERS_UI}
+
+push:
+	docker push ${PYTHONUI_IMG}:${VERS_UI}
+
+scenarios_portfolios:
+	python ./scripts/add_test_portfolios.py -c ./scenarios/portfolios.json
+
+scenarios_settings:
+	python ./scripts/add_settings_template.py -c ./scenarios/a_settings.json
+
+scenarios: scenarios_portfolios scenarios_settings
+
+build_and_push: build push

README.md

@@ -65,9 +65,16 @@ echo "127.0.0.1 ui.oasis.local" | sudo tee -a /etc/hosts
 ./install.sh
 ```
 
-The installer clones the PiWind demo model, processes OIDC templates (if
-applicable), builds the UI image, and starts all services. It will prompt
-before redeploying if a previous installation is detected.
+The installer stages the model data for the selected model set, processes OIDC
+templates (if applicable), pulls the images, and starts all services. It will
+prompt before redeploying if a previous installation is detected.
+
+| Option | Description |
+|--------|-------------|
+| `-m`, `--model-set <name>` | Model set to deploy. Defaults to `MODEL_SET` from `.env`, or `piwind`. |
+| `--build-ui` | Build the UI image locally instead of pulling `PYTHONUI_IMG:VERS_UI`. |
+| `-u`, `--uninstall` | Bring the stack down and delete its volumes. |
+| `-h`, `--help` | Show usage. |
 
 To tear everything down (removes containers and volumes):
 
@@ -104,19 +111,82 @@ All services are reachable on port 80 via Traefik after a successful install:
 
 ## Docker Compose Architecture
 
-The stack is assembled from multiple Compose files depending on auth type:
+`install.sh` layers several Compose files into a single `docker compose`
+command. The model workers live in a file of their own, so the core platform,
+the UI and the auth stack stay model-agnostic:
 
 ```
 Always loaded:
- docker-compose.yml # Core platform: server, worker, databases, broker
- docker-compose.ui.yml # Streamlit UI + Traefik reverse proxy
+ docker-compose.yml # Core platform: Traefik, server, websocket, databases, broker, filestore
+ docker-compose.models.<model-set>.yml # Model workers and model registration for one model set
+ docker-compose.ui.yml # Streamlit UI
 
 Conditionally loaded:
- docker-compose.keycloak.yml # Keycloak + its PostgreSQL DB (API_AUTH_TYPE=keycloak)
+ docker-compose.keycloak.yml # Keycloak + its PostgreSQL DB (API_AUTH_TYPE=keycloak)
  docker-compose.authentik.yml # Authentik + its PostgreSQL DB (API_AUTH_TYPE=authentik)
 ```
 
-`install.sh` builds the correct `docker compose -f ... up` command automatically.
+### Model sets — `docker-compose.models.<model-set>.yml`
+
+`docker-compose.yml` defines no model workers at all. Everything
+model-specific is confined to a `docker-compose.models.<model-set>.yml` file:
+
+- one worker service per model, carrying its `OASIS_MODEL_SUPPLIER_ID`,
+ `OASIS_MODEL_ID`, `OASIS_MODEL_VERSION_ID` and `OASIS_RUN_MODE`
+- the volume mount that supplies that model's data
+- any `model-registration` job needed to register the models with the API
+
+Exactly one model set is loaded per deployment. Pick it with `-m/--model-set`,
+or set `MODEL_SET` in `.env` so a bare `./install.sh` deploys it:
+
+```bash
+./install.sh -m piwind # default: the PiWind demo model
+./install.sh -m scenarios # PiWind plus the public scenario models
+```
+
+Model sets shipped in this repository:
+
+| File | Contents |
+|------|----------|
+| `docker-compose.models.piwind.yml` | A `model-registration` one-shot and `piwind-worker`, with model data from `./OasisPiWind/`. |
+| `docker-compose.models.scenarios.yml` | `piwind-worker` plus the scenario workers (Impact Forecasting, JBA, ARA, IPE), with model data from `${SCENARIOS_PATH}`. |
+
+Because the split is by filename, adding a model set means dropping two new
+files into the root directory — no edits to `docker-compose.yml`, `install.sh`
+or the auth files:
+
+1. Write `docker-compose.models.<name>.yml` with the worker services. The
+ workers join the core stack, so they can depend on `server`, `celery-db` and
+ `broker` and mount the shared `filestore-data` volume directly.
+2. Optionally add `get-<name>.sh` to fetch the model data (see below).
+3. Deploy with `./install.sh -m <name>`.
+
+`install.sh --uninstall` passes *every* `docker-compose.models.*.yml` to
+`docker compose down`, so the model workers are torn down whichever set was
+deployed.
+
+#### Model data — `get-<model-set>.sh`
+
+The Compose file describes how a model runs; the matching `get-<model-set>.sh`
+puts its data on disk. Before bringing the stack up, `install.sh` runs
+`get-$MODEL_SET.sh` if it exists, and otherwise assumes the data is already in
+place.
+
+| Script | What it does |
+|--------|--------------|
+| `get-piwind.sh` | Clones `OasisLMF/OasisPiWind` at `VERS_PIWIND` into `./OasisPiWind/`. No-ops once cloned. |
+| `get-scenarios.sh` | Runs `get-piwind.sh`, clones `OasisLMF/Scenarios` into `$SCENARIOS_PATH`, then runs that repository's `get_s3_data_reduced.sh` to download the model files. Each step is skipped if it has already been done. |
+
+The scripts are idempotent and safe to run on their own, which is the easy way
+to pre-stage model data on a server before deploying, or to refresh it without
+a redeploy:
+
+```bash
+SCENARIOS_PATH=/home/ubuntu/Scenarios ./get-scenarios.sh
+```
+
+When writing your own, keep it re-runnable: `install.sh` calls it on every
+deploy, including redeploys over an existing installation.
 
 ## Key Environment Variables
 
@@ -131,6 +201,25 @@ Conditionally loaded:
 
 See the `.env.*` templates for the full list with inline comments.
 
+### Deployment overrides
+
+These variables decide *what* gets deployed and *what the UI shows*, rather
+than how the platform is wired together. They are read straight from `.env` by
+`install.sh` and the Compose files, and each falls back to the layout in this
+repository — so a plain checkout still deploys unchanged with none of them set.
+They are not in the `.env.*` templates; add the ones a deployment needs.
+
+| Variable | Default | Purpose |
+|----------|---------|---------|
+| `MODEL_SET` | `piwind` | Which `docker-compose.models.<name>.yml` / `get-<name>.sh` pair to deploy. `-m/--model-set` overrides it for one run. |
+| `SCENARIOS_PATH` | *(unset)* | Host directory holding the scenario model data. Required by the `scenarios` model set — both `get-scenarios.sh` and the worker mounts read it. |
+| `UI_CONFIG` | `./ui-config.json` | The UI's config file: pages, post-login page, model-to-exposure map, footer, and `skip_login`. |
+| `UI_DEFAULTS` | `./defaults/` | Per-model default analysis settings the UI pre-fills when creating an analysis. |
+| `UI_ASSETS` | `./ui_assets/` | Files `UI_CONFIG` refers to as `ui_assets/<file>` — footer text, logos, anything a deployment supplies. |
+| `UI_STREAMLIT` | `./.streamlit/` | The Streamlit directory mounted read-only: `secrets.toml` and `config.toml`. |
+| `PYTHONUI_IMG` / `VERS_UI` | `coreoasis/oasispythonui_app` / `latest` | UI image pulled at deploy time, and the tag `make build` / `make push` produce. |
+
+
 ## Adding Users
 
 ### Simple auth
@@ -166,6 +255,10 @@ Usually first thing to try before anything is clearing browser cache/cookies for
 - The IdP database container must be healthy first: `docker compose ps`.
 - First startup can take 2–3 minutes while blueprints and realms are imported.
 
+**`install.sh` exits with `no model set '<name>'`**
+- The model set has no `docker-compose.models.<name>.yml` in the root directory.
+ Check the spelling of `-m/--model-set` or `MODEL_SET`.
+
 **Logs and status**
 ```bash
 docker compose ps # service health

.streamlit/secrets.toml

@@ -1,4 +1,4 @@
-auth_type='oidc'
+auth_type='simple'
 
 user='admin'
 password='password'

Makefile

@@ -0,0 +1,18 @@
+#!make
+include .env
+
+build:
+	docker build -f oasisui_st_app.Dockerfile . -t ${PYTHONUI_IMG}:${VERS_UI}
+
+push:
+	docker push ${PYTHONUI_IMG}:${VERS_UI}
+
+scenarios_portfolios:
+	python ./scripts/add_test_portfolios.py -c ./scenarios/portfolios.json
+
+scenarios_settings:
+	python ./scripts/add_settings_template.py -c ./scenarios/a_settings.json
+
+scenarios: scenarios_portfolios scenarios_settings
+
+build_and_push: build push

README.md

@@ -65,9 +65,16 @@ echo "127.0.0.1 ui.oasis.local" | sudo tee -a /etc/hosts
 ./install.sh
 ```
 
-The installer clones the PiWind demo model, processes OIDC templates (if
-applicable), builds the UI image, and starts all services. It will prompt
-before redeploying if a previous installation is detected.
+The installer stages the model data for the selected model set, processes OIDC
+templates (if applicable), pulls the images, and starts all services. It will
+prompt before redeploying if a previous installation is detected.
+
+| Option | Description |
+|--------|-------------|
+| `-m`, `--model-set <name>` | Model set to deploy. Defaults to `MODEL_SET` from `.env`, or `piwind`. |
+| `--build-ui` | Build the UI image locally instead of pulling `PYTHONUI_IMG:VERS_UI`. |
+| `-u`, `--uninstall` | Bring the stack down and delete its volumes. |
+| `-h`, `--help` | Show usage. |
 
 To tear everything down (removes containers and volumes):
 
@@ -104,19 +111,82 @@ All services are reachable on port 80 via Traefik after a successful install:
 
 ## Docker Compose Architecture
 
-The stack is assembled from multiple Compose files depending on auth type:
+`install.sh` layers several Compose files into a single `docker compose`
+command. The model workers live in a file of their own, so the core platform,
+the UI and the auth stack stay model-agnostic:
 
 ```
 Always loaded:
- docker-compose.yml # Core platform: server, worker, databases, broker
- docker-compose.ui.yml # Streamlit UI + Traefik reverse proxy
+ docker-compose.yml # Core platform: Traefik, server, websocket, databases, broker, filestore
+ docker-compose.models.<model-set>.yml # Model workers and model registration for one model set
+ docker-compose.ui.yml # Streamlit UI
 
 Conditionally loaded:
- docker-compose.keycloak.yml # Keycloak + its PostgreSQL DB (API_AUTH_TYPE=keycloak)
+ docker-compose.keycloak.yml # Keycloak + its PostgreSQL DB (API_AUTH_TYPE=keycloak)
  docker-compose.authentik.yml # Authentik + its PostgreSQL DB (API_AUTH_TYPE=authentik)
 ```
 
-`install.sh` builds the correct `docker compose -f ... up` command automatically.
+### Model sets — `docker-compose.models.<model-set>.yml`
+
+`docker-compose.yml` defines no model workers at all. Everything
+model-specific is confined to a `docker-compose.models.<model-set>.yml` file:
+
+- one worker service per model, carrying its `OASIS_MODEL_SUPPLIER_ID`,
+ `OASIS_MODEL_ID`, `OASIS_MODEL_VERSION_ID` and `OASIS_RUN_MODE`
+- the volume mount that supplies that model's data
+- any `model-registration` job needed to register the models with the API
+
+Exactly one model set is loaded per deployment. Pick it with `-m/--model-set`,
+or set `MODEL_SET` in `.env` so a bare `./install.sh` deploys it:
+
+```bash
+./install.sh -m piwind # default: the PiWind demo model
+./install.sh -m scenarios # PiWind plus the public scenario models
+```
+
+Model sets shipped in this repository:
+
+| File | Contents |
+|------|----------|
+| `docker-compose.models.piwind.yml` | A `model-registration` one-shot and `piwind-worker`, with model data from `./OasisPiWind/`. |
+| `docker-compose.models.scenarios.yml` | `piwind-worker` plus the scenario workers (Impact Forecasting, JBA, ARA, IPE), with model data from `${SCENARIOS_PATH}`. |
+
+Because the split is by filename, adding a model set means dropping two new
+files into the root directory — no edits to `docker-compose.yml`, `install.sh`
+or the auth files:
+
+1. Write `docker-compose.models.<name>.yml` with the worker services. The
+ workers join the core stack, so they can depend on `server`, `celery-db` and
+ `broker` and mount the shared `filestore-data` volume directly.
+2. Optionally add `get-<name>.sh` to fetch the model data (see below).
+3. Deploy with `./install.sh -m <name>`.
+
+`install.sh --uninstall` passes *every* `docker-compose.models.*.yml` to
+`docker compose down`, so the model workers are torn down whichever set was
+deployed.
+
+#### Model data — `get-<model-set>.sh`
+
+The Compose file describes how a model runs; the matching `get-<model-set>.sh`
+puts its data on disk. Before bringing the stack up, `install.sh` runs
+`get-$MODEL_SET.sh` if it exists, and otherwise assumes the data is already in
+place.
+
+| Script | What it does |
+|--------|--------------|
+| `get-piwind.sh` | Clones `OasisLMF/OasisPiWind` at `VERS_PIWIND` into `./OasisPiWind/`. No-ops once cloned. |
+| `get-scenarios.sh` | Runs `get-piwind.sh`, clones `OasisLMF/Scenarios` into `$SCENARIOS_PATH`, then runs that repository's `get_s3_data_reduced.sh` to download the model files. Each step is skipped if it has already been done. |
+
+The scripts are idempotent and safe to run on their own, which is the easy way
+to pre-stage model data on a server before deploying, or to refresh it without
+a redeploy:
+
+```bash
+SCENARIOS_PATH=/home/ubuntu/Scenarios ./get-scenarios.sh
+```
+
+When writing your own, keep it re-runnable: `install.sh` calls it on every
+deploy, including redeploys over an existing installation.
 
 ## Key Environment Variables
 
@@ -131,6 +201,25 @@ Conditionally loaded:
 
 See the `.env.*` templates for the full list with inline comments.
 
+### Deployment overrides
+
+These variables decide *what* gets deployed and *what the UI shows*, rather
+than how the platform is wired together. They are read straight from `.env` by
+`install.sh` and the Compose files, and each falls back to the layout in this
+repository — so a plain checkout still deploys unchanged with none of them set.
+They are not in the `.env.*` templates; add the ones a deployment needs.
+
+| Variable | Default | Purpose |
+|----------|---------|---------|
+| `MODEL_SET` | `piwind` | Which `docker-compose.models.<name>.yml` / `get-<name>.sh` pair to deploy. `-m/--model-set` overrides it for one run. |
+| `SCENARIOS_PATH` | *(unset)* | Host directory holding the scenario model data. Required by the `scenarios` model set — both `get-scenarios.sh` and the worker mounts read it. |
+| `UI_CONFIG` | `./ui-config.json` | The UI's config file: pages, post-login page, model-to-exposure map, footer, and `skip_login`. |
+| `UI_DEFAULTS` | `./defaults/` | Per-model default analysis settings the UI pre-fills when creating an analysis. |
+| `UI_ASSETS` | `./ui_assets/` | Files `UI_CONFIG` refers to as `ui_assets/<file>` — footer text, logos, anything a deployment supplies. |
+| `UI_STREAMLIT` | `./.streamlit/` | The Streamlit directory mounted read-only: `secrets.toml` and `config.toml`. |
+| `PYTHONUI_IMG` / `VERS_UI` | `coreoasis/oasispythonui_app` / `latest` | UI image pulled at deploy time, and the tag `make build` / `make push` produce. |
+
+
 ## Adding Users
 
 ### Simple auth
@@ -166,6 +255,10 @@ Usually first thing to try before anything is clearing browser cache/cookies for
 - The IdP database container must be healthy first: `docker compose ps`.
 - First startup can take 2–3 minutes while blueprints and realms are imported.
 
+**`install.sh` exits with `no model set '<name>'`**
+- The model set has no `docker-compose.models.<name>.yml` in the root directory.
+ Check the spelling of `-m/--model-set` or `MODEL_SET`.
+
 **Logs and status**
 ```bash
 docker compose ps # service health

.streamlit/secrets.toml

@@ -1,4 +1,4 @@
-auth_type='oidc'
+auth_type='simple'
 
 user='admin'
 password='password'

Makefile

@@ -0,0 +1,18 @@
+#!make
+include .env
+
+build:
+	docker build -f oasisui_st_app.Dockerfile . -t ${PYTHONUI_IMG}:${VERS_UI}
+
+push:
+	docker push ${PYTHONUI_IMG}:${VERS_UI}
+
+scenarios_portfolios:
+	python ./scripts/add_test_portfolios.py -c ./scenarios/portfolios.json
+
+scenarios_settings:
+	python ./scripts/add_settings_template.py -c ./scenarios/a_settings.json
+
+scenarios: scenarios_portfolios scenarios_settings
+
+build_and_push: build push

README.md

@@ -65,9 +65,16 @@ echo "127.0.0.1 ui.oasis.local" | sudo tee -a /etc/hosts
 ./install.sh
 ```
 
-The installer clones the PiWind demo model, processes OIDC templates (if
-applicable), builds the UI image, and starts all services. It will prompt
-before redeploying if a previous installation is detected.
+The installer stages the model data for the selected model set, processes OIDC
+templates (if applicable), pulls the images, and starts all services. It will
+prompt before redeploying if a previous installation is detected.
+
+| Option | Description |
+|--------|-------------|
+| `-m`, `--model-set <name>` | Model set to deploy. Defaults to `MODEL_SET` from `.env`, or `piwind`. |
+| `--build-ui` | Build the UI image locally instead of pulling `PYTHONUI_IMG:VERS_UI`. |
+| `-u`, `--uninstall` | Bring the stack down and delete its volumes. |
+| `-h`, `--help` | Show usage. |
 
 To tear everything down (removes containers and volumes):
 
@@ -104,19 +111,82 @@ All services are reachable on port 80 via Traefik after a successful install:
 
 ## Docker Compose Architecture
 
-The stack is assembled from multiple Compose files depending on auth type:
+`install.sh` layers several Compose files into a single `docker compose`
+command. The model workers live in a file of their own, so the core platform,
+the UI and the auth stack stay model-agnostic:
 
 ```
 Always loaded:
- docker-compose.yml # Core platform: server, worker, databases, broker
- docker-compose.ui.yml # Streamlit UI + Traefik reverse proxy
+ docker-compose.yml # Core platform: Traefik, server, websocket, databases, broker, filestore
+ docker-compose.models.<model-set>.yml # Model workers and model registration for one model set
+ docker-compose.ui.yml # Streamlit UI
 
 Conditionally loaded:
- docker-compose.keycloak.yml # Keycloak + its PostgreSQL DB (API_AUTH_TYPE=keycloak)
+ docker-compose.keycloak.yml # Keycloak + its PostgreSQL DB (API_AUTH_TYPE=keycloak)
  docker-compose.authentik.yml # Authentik + its PostgreSQL DB (API_AUTH_TYPE=authentik)
 ```
 
-`install.sh` builds the correct `docker compose -f ... up` command automatically.
+### Model sets — `docker-compose.models.<model-set>.yml`
+
+`docker-compose.yml` defines no model workers at all. Everything
+model-specific is confined to a `docker-compose.models.<model-set>.yml` file:
+
+- one worker service per model, carrying its `OASIS_MODEL_SUPPLIER_ID`,
+ `OASIS_MODEL_ID`, `OASIS_MODEL_VERSION_ID` and `OASIS_RUN_MODE`
+- the volume mount that supplies that model's data
+- any `model-registration` job needed to register the models with the API
+
+Exactly one model set is loaded per deployment. Pick it with `-m/--model-set`,
+or set `MODEL_SET` in `.env` so a bare `./install.sh` deploys it:
+
+```bash
+./install.sh -m piwind # default: the PiWind demo model
+./install.sh -m scenarios # PiWind plus the public scenario models
+```
+
+Model sets shipped in this repository:
+
+| File | Contents |
+|------|----------|
+| `docker-compose.models.piwind.yml` | A `model-registration` one-shot and `piwind-worker`, with model data from `./OasisPiWind/`. |
+| `docker-compose.models.scenarios.yml` | `piwind-worker` plus the scenario workers (Impact Forecasting, JBA, ARA, IPE), with model data from `${SCENARIOS_PATH}`. |
+
+Because the split is by filename, adding a model set means dropping two new
+files into the root directory — no edits to `docker-compose.yml`, `install.sh`
+or the auth files:
+
+1. Write `docker-compose.models.<name>.yml` with the worker services. The
+ workers join the core stack, so they can depend on `server`, `celery-db` and
+ `broker` and mount the shared `filestore-data` volume directly.
+2. Optionally add `get-<name>.sh` to fetch the model data (see below).
+3. Deploy with `./install.sh -m <name>`.
+
+`install.sh --uninstall` passes *every* `docker-compose.models.*.yml` to
+`docker compose down`, so the model workers are torn down whichever set was
+deployed.
+
+#### Model data — `get-<model-set>.sh`
+
+The Compose file describes how a model runs; the matching `get-<model-set>.sh`
+puts its data on disk. Before bringing the stack up, `install.sh` runs
+`get-$MODEL_SET.sh` if it exists, and otherwise assumes the data is already in
+place.
+
+| Script | What it does |
+|--------|--------------|
+| `get-piwind.sh` | Clones `OasisLMF/OasisPiWind` at `VERS_PIWIND` into `./OasisPiWind/`. No-ops once cloned. |
+| `get-scenarios.sh` | Runs `get-piwind.sh`, clones `OasisLMF/Scenarios` into `$SCENARIOS_PATH`, then runs that repository's `get_s3_data_reduced.sh` to download the model files. Each step is skipped if it has already been done. |
+
+The scripts are idempotent and safe to run on their own, which is the easy way
+to pre-stage model data on a server before deploying, or to refresh it without
+a redeploy:
+
+```bash
+SCENARIOS_PATH=/home/ubuntu/Scenarios ./get-scenarios.sh
+```
+
+When writing your own, keep it re-runnable: `install.sh` calls it on every
+deploy, including redeploys over an existing installation.
 
 ## Key Environment Variables
 
@@ -131,6 +201,25 @@ Conditionally loaded:
 
 See the `.env.*` templates for the full list with inline comments.
 
+### Deployment overrides
+
+These variables decide *what* gets deployed and *what the UI shows*, rather
+than how the platform is wired together. They are read straight from `.env` by
+`install.sh` and the Compose files, and each falls back to the layout in this
+repository — so a plain checkout still deploys unchanged with none of them set.
+They are not in the `.env.*` templates; add the ones a deployment needs.
+
+| Variable | Default | Purpose |
+|----------|---------|---------|
+| `MODEL_SET` | `piwind` | Which `docker-compose.models.<name>.yml` / `get-<name>.sh` pair to deploy. `-m/--model-set` overrides it for one run. |
+| `SCENARIOS_PATH` | *(unset)* | Host directory holding the scenario model data. Required by the `scenarios` model set — both `get-scenarios.sh` and the worker mounts read it. |
+| `UI_CONFIG` | `./ui-config.json` | The UI's config file: pages, post-login page, model-to-exposure map, footer, and `skip_login`. |
+| `UI_DEFAULTS` | `./defaults/` | Per-model default analysis settings the UI pre-fills when creating an analysis. |
+| `UI_ASSETS` | `./ui_assets/` | Files `UI_CONFIG` refers to as `ui_assets/<file>` — footer text, logos, anything a deployment supplies. |
+| `UI_STREAMLIT` | `./.streamlit/` | The Streamlit directory mounted read-only: `secrets.toml` and `config.toml`. |
+| `PYTHONUI_IMG` / `VERS_UI` | `coreoasis/oasispythonui_app` / `latest` | UI image pulled at deploy time, and the tag `make build` / `make push` produce. |
+
+
 ## Adding Users
 
 ### Simple auth
@@ -166,6 +255,10 @@ Usually first thing to try before anything is clearing browser cache/cookies for
 - The IdP database container must be healthy first: `docker compose ps`.
 - First startup can take 2–3 minutes while blueprints and realms are imported.
 
+**`install.sh` exits with `no model set '<name>'`**
+- The model set has no `docker-compose.models.<name>.yml` in the root directory.
+ Check the spelling of `-m/--model-set` or `MODEL_SET`.
+
 **Logs and status**
 ```bash
 docker compose ps # service health

.streamlit/secrets.toml

@@ -1,4 +1,4 @@
-auth_type='oidc'
+auth_type='simple'
 
 user='admin'
 password='password'

Makefile

@@ -0,0 +1,18 @@
+#!make
+include .env
+
+build:
+	docker build -f oasisui_st_app.Dockerfile . -t ${PYTHONUI_IMG}:${VERS_UI}
+
+push:
+	docker push ${PYTHONUI_IMG}:${VERS_UI}
+
+scenarios_portfolios:
+	python ./scripts/add_test_portfolios.py -c ./scenarios/portfolios.json
+
+scenarios_settings:
+	python ./scripts/add_settings_template.py -c ./scenarios/a_settings.json
+
+scenarios: scenarios_portfolios scenarios_settings
+
+build_and_push: build push

README.md

@@ -65,9 +65,16 @@ echo "127.0.0.1 ui.oasis.local" | sudo tee -a /etc/hosts
 ./install.sh
 ```
 
-The installer clones the PiWind demo model, processes OIDC templates (if
-applicable), builds the UI image, and starts all services. It will prompt
-before redeploying if a previous installation is detected.
+The installer stages the model data for the selected model set, processes OIDC
+templates (if applicable), pulls the images, and starts all services. It will
+prompt before redeploying if a previous installation is detected.
+
+| Option | Description |
+|--------|-------------|
+| `-m`, `--model-set <name>` | Model set to deploy. Defaults to `MODEL_SET` from `.env`, or `piwind`. |
+| `--build-ui` | Build the UI image locally instead of pulling `PYTHONUI_IMG:VERS_UI`. |
+| `-u`, `--uninstall` | Bring the stack down and delete its volumes. |
+| `-h`, `--help` | Show usage. |
 
 To tear everything down (removes containers and volumes):
 
@@ -104,19 +111,82 @@ All services are reachable on port 80 via Traefik after a successful install:
 
 ## Docker Compose Architecture
 
-The stack is assembled from multiple Compose files depending on auth type:
+`install.sh` layers several Compose files into a single `docker compose`
+command. The model workers live in a file of their own, so the core platform,
+the UI and the auth stack stay model-agnostic:
 
 ```
 Always loaded:
- docker-compose.yml # Core platform: server, worker, databases, broker
- docker-compose.ui.yml # Streamlit UI + Traefik reverse proxy
+ docker-compose.yml # Core platform: Traefik, server, websocket, databases, broker, filestore
+ docker-compose.models.<model-set>.yml # Model workers and model registration for one model set
+ docker-compose.ui.yml # Streamlit UI
 
 Conditionally loaded:
- docker-compose.keycloak.yml # Keycloak + its PostgreSQL DB (API_AUTH_TYPE=keycloak)
+ docker-compose.keycloak.yml # Keycloak + its PostgreSQL DB (API_AUTH_TYPE=keycloak)
  docker-compose.authentik.yml # Authentik + its PostgreSQL DB (API_AUTH_TYPE=authentik)
 ```
 
-`install.sh` builds the correct `docker compose -f ... up` command automatically.
+### Model sets — `docker-compose.models.<model-set>.yml`
+
+`docker-compose.yml` defines no model workers at all. Everything
+model-specific is confined to a `docker-compose.models.<model-set>.yml` file:
+
+- one worker service per model, carrying its `OASIS_MODEL_SUPPLIER_ID`,
+ `OASIS_MODEL_ID`, `OASIS_MODEL_VERSION_ID` and `OASIS_RUN_MODE`
+- the volume mount that supplies that model's data
+- any `model-registration` job needed to register the models with the API
+
+Exactly one model set is loaded per deployment. Pick it with `-m/--model-set`,
+or set `MODEL_SET` in `.env` so a bare `./install.sh` deploys it:
+
+```bash
+./install.sh -m piwind # default: the PiWind demo model
+./install.sh -m scenarios # PiWind plus the public scenario models
+```
+
+Model sets shipped in this repository:
+
+| File | Contents |
+|------|----------|
+| `docker-compose.models.piwind.yml` | A `model-registration` one-shot and `piwind-worker`, with model data from `./OasisPiWind/`. |
+| `docker-compose.models.scenarios.yml` | `piwind-worker` plus the scenario workers (Impact Forecasting, JBA, ARA, IPE), with model data from `${SCENARIOS_PATH}`. |
+
+Because the split is by filename, adding a model set means dropping two new
+files into the root directory — no edits to `docker-compose.yml`, `install.sh`
+or the auth files:
+
+1. Write `docker-compose.models.<name>.yml` with the worker services. The
+ workers join the core stack, so they can depend on `server`, `celery-db` and
+ `broker` and mount the shared `filestore-data` volume directly.
+2. Optionally add `get-<name>.sh` to fetch the model data (see below).
+3. Deploy with `./install.sh -m <name>`.
+
+`install.sh --uninstall` passes *every* `docker-compose.models.*.yml` to
+`docker compose down`, so the model workers are torn down whichever set was
+deployed.
+
+#### Model data — `get-<model-set>.sh`
+
+The Compose file describes how a model runs; the matching `get-<model-set>.sh`
+puts its data on disk. Before bringing the stack up, `install.sh` runs
+`get-$MODEL_SET.sh` if it exists, and otherwise assumes the data is already in
+place.
+
+| Script | What it does |
+|--------|--------------|
+| `get-piwind.sh` | Clones `OasisLMF/OasisPiWind` at `VERS_PIWIND` into `./OasisPiWind/`. No-ops once cloned. |
+| `get-scenarios.sh` | Runs `get-piwind.sh`, clones `OasisLMF/Scenarios` into `$SCENARIOS_PATH`, then runs that repository's `get_s3_data_reduced.sh` to download the model files. Each step is skipped if it has already been done. |
+
+The scripts are idempotent and safe to run on their own, which is the easy way
+to pre-stage model data on a server before deploying, or to refresh it without
+a redeploy:
+
+```bash
+SCENARIOS_PATH=/home/ubuntu/Scenarios ./get-scenarios.sh
+```
+
+When writing your own, keep it re-runnable: `install.sh` calls it on every
+deploy, including redeploys over an existing installation.
 
 ## Key Environment Variables
 
@@ -131,6 +201,25 @@ Conditionally loaded:
 
 See the `.env.*` templates for the full list with inline comments.
 
+### Deployment overrides
+
+These variables decide *what* gets deployed and *what the UI shows*, rather
+than how the platform is wired together. They are read straight from `.env` by
+`install.sh` and the Compose files, and each falls back to the layout in this
+repository — so a plain checkout still deploys unchanged with none of them set.
+They are not in the `.env.*` templates; add the ones a deployment needs.
+
+| Variable | Default | Purpose |
+|----------|---------|---------|
+| `MODEL_SET` | `piwind` | Which `docker-compose.models.<name>.yml` / `get-<name>.sh` pair to deploy. `-m/--model-set` overrides it for one run. |
+| `SCENARIOS_PATH` | *(unset)* | Host directory holding the scenario model data. Required by the `scenarios` model set — both `get-scenarios.sh` and the worker mounts read it. |
+| `UI_CONFIG` | `./ui-config.json` | The UI's config file: pages, post-login page, model-to-exposure map, footer, and `skip_login`. |
+| `UI_DEFAULTS` | `./defaults/` | Per-model default analysis settings the UI pre-fills when creating an analysis. |
+| `UI_ASSETS` | `./ui_assets/` | Files `UI_CONFIG` refers to as `ui_assets/<file>` — footer text, logos, anything a deployment supplies. |
+| `UI_STREAMLIT` | `./.streamlit/` | The Streamlit directory mounted read-only: `secrets.toml` and `config.toml`. |
+| `PYTHONUI_IMG` / `VERS_UI` | `coreoasis/oasispythonui_app` / `latest` | UI image pulled at deploy time, and the tag `make build` / `make push` produce. |
+
+
 ## Adding Users
 
 ### Simple auth
@@ -166,6 +255,10 @@ Usually first thing to try before anything is clearing browser cache/cookies for
 - The IdP database container must be healthy first: `docker compose ps`.
 - First startup can take 2–3 minutes while blueprints and realms are imported.
 
+**`install.sh` exits with `no model set '<name>'`**
+- The model set has no `docker-compose.models.<name>.yml` in the root directory.
+ Check the spelling of `-m/--model-set` or `MODEL_SET`.
+
 **Logs and status**
 ```bash
 docker compose ps # service health