Chore/k8s chart cleanup

.gitignore

@@ -13,4 +13,5 @@ __pycache__
 **/.fuse*
 dev/.env
 .venv
-.env
+.env
+/deployment/dev/data/stroke

deployment/dev/.env.example

@@ -1,8 +1,8 @@
 # Versions
 EXAFLOW=1.0.0
-PLATFORM_BACKEND=9.1.1
-PLATFORM_UI=1.0.1
-MIP=9.0.2
+PLATFORM_BACKEND=9.1.2
+PLATFORM_UI=1.0.2
+MIP=9.0.3
 
 # Toggle authentication
 AUTHENTICATION=0

deployment/dev/docker-compose.yml

@@ -180,9 +180,6 @@ services:
       PLATFORM_BACKEND_SERVER: platform-backend:8080
       PLATFORM_BACKEND_CONTEXT: services
       NOTEBOOK_ENABLED: 0
-      FRONTEND_VERSION: "${PLATFORM_UI}"
-      BACKEND_VERSION: "${PLATFORM_BACKEND}"
-      EXAFLOW_VERSION: "${EXAFLOW}"
       MIP_VERSION: "${MIP}"
     depends_on:
       - platform-backend

deployment/kubernetes/README.md

@@ -6,7 +6,7 @@ MIP now supports two Kubernetes infrastructure options:
 1. **VM-based / microk8s clusters** – the remainder of this document (starting in the Requirements section) walks through preparing Ubuntu virtual machines and installing the stack on top of microk8s.
 2. **Managed clusters** – for cloud-managed Kubernetes (AKS/EKS/GKE, etc.) follow the [mip-infra getting started guide](https://github.com/Medical-Informatics-Platform/mip-infra?tab=readme-ov-file#-getting-started) to provision the cluster and its base services. Once the cluster is available, return here for component configuration details as needed.
 
-Choose between these modes via the Helm values: set `managed_cluster: true` (managed) or `false` (microk8s/VM). The templates react to this flag to deploy the components with the right assumptions for networking, storage, and access.
+Choose between these modes via the Helm values: set `cluster.managed: true` (managed) or `false` (microk8s/VM). The chart now keeps the same workload shape in both modes and uses the flag only to select the storage class and, for microk8s, bootstrap the local `StorageClass`.
 
 ## Requirements
 ### Hardware
@@ -53,54 +53,40 @@ Afterward, The dataset CSV files should be placed in their proper pathology fold
 ## Configuration
 Prior to deploying it (on a microk8s K8s cluster of one or more nodes), there are a few adjustments to make in `values.yaml`. Each top-level section controls a part of the stack:
 
-* `cluster`: namespace, storage classes and whether the cluster provisions persistent volumes dynamically (`managed: true`).
-* `network`: public hostname, protocols, and whether the UI is exposed directly or through a reverse proxy (`link`).
-* `platform-ui`, `platform-backend`, `platformBackendDatabase`: container images and component specific options (including the platform-ui ingress/tls settings).
-* `keycloak`: toggles the connection parameters to the external Keycloak instance (`enabled`, `host`, `protocol`, `realm`, `clientId`).
+* `cluster`: storage classes and whether the chart should use the managed storage class or the microk8s local storage class.
+* `global`: shared public hostname used by the ingress and backend redirects.
+* `platform-ui`, `platform-backend`, `platformBackendDatabase`: container images and component specific options (including the shared ingress/tls settings and PVC sizes).
+* `keycloak`: toggles the connection parameters to the external Keycloak instance (`enabled`, `host`, `protocol`, `realm`).
 
 Copy `values.yaml` to a new file (for example `my-values.yaml`) and edit it in-place. A few important knobs:
 
 ```yaml
-network:
-  link: proxied            # use "direct" when exposing the UI publicly
+global:
   publicHost: mip.example.org
-  publicProtocol: https
 
 platform-ui:
   backend:
     host: platform-backend-service
     port: 8080
     context: services
   ingress:
-    redirectRootTo: /home       # optional 302 redirect for the landing page
     tlsSecretName: platform-ui-tls
 
 keycloak:
   enabled: true
   host: iam.example.org
-  protocol: https
-  realm: MIP
-  clientId: mipfed
 ```
 
-The reachability diagram from the legacy profiles is still valid as a reference for deciding the correct `network.*` settings:
+The reachability diagram from the legacy profiles is still valid as a reference for deciding the correct public URL:
 ![MIP Reachability Scheme](../docs/MIP_Configuration.png)
 
-### MACHINE_MAIN_IP
-This is the machine's main IP address. Generally, it's the IP address of the first NIC after the local one.  
-If the MIP is running on top of a VPN, you may want to put the VPN interface's IP address.  
-If you reach the machine through a public IP, if this IP is **NOT** directly assigned on the machine, but is using static NAT, you still **MUST** set the **INTERNAL** IP of the machine itself!
+`global.publicHost` defaults to `hbpmip.link`. Override it in your custom values file or with `--set-string global.publicHost=<hostname>` whenever a deployment needs a different public hostname.
 
-### MACHINE_PUBLIC_FQDN
-This is the public, fully qualified domain name of the MIP, the main URL on which you want to reach the MIP from the Internet. This may point:
-* Directly on the public IP of the MIP, for a **direct** use case. It may be assigned on the machine or used in front as a static NAT
-* On the public IP of the reverse-proxy server, for a **proxied** use case
+`global.publicHost` must be the bare hostname served by the ingress, without `http://` or `https://`.
 
-### MACHINE_PRIVATE_FQDN_OR_IP
-This is **ONLY** used in a **proxied** use case situation.  
-It's actually the internal IP or address from which the reverse-proxy server "sees" (reaches) the MIP machine.
+`keycloak.protocol` defaults to `https` and `keycloak.realm` defaults to `MIP`. Override them only when your external Keycloak differs from those defaults.
 
-These three settings map directly to the `network` section in `values.yaml` (`publicHost`, `link`, `publicProtocol`). When running behind a reverse proxy also set `externalProtocol` to describe the protocol used between the proxy and the MIP pods.
+If you deploy behind a reverse proxy or load balancer, forward the standard `X-Forwarded-*` headers to the backend so Spring can reconstruct the public request URL correctly.
 
 **WARNING!**: In **ANY** case, when you use an **EXTERNAL** KeyCloak service (i.e. iam.ebrains.eu), make sure that you use the correct *CLIENT_ID* and *CLIENT_SECRET* to match the MIP instance you're deploying!
 
@@ -124,7 +110,7 @@ sudo adduser mipadmin microk8s
 
 As *mipadmin* user:
 ```
-microk8s enable dns helm3 ingress
+microk8s enable dns helm3 ingress storage
 ```
 ```
 sudo mkdir -p /data/<MIP_INSTANCE_OR_FEDERATION_NAME>
@@ -133,6 +119,8 @@ sudo mkdir -p /data/<MIP_INSTANCE_OR_FEDERATION_NAME>
 sudo chown -R mipadmin.mipadmin /data
 ```
 
+The web-app chart uses dynamically provisioned PVCs on microk8s too. The `storage` addon provides the `k8s.io/microk8s-hostpath` provisioner, and the chart bootstraps a local `StorageClass` on top of it for the MIP PVCs.
+
 For a "federated" deployment, you may want to add nodes to your cluster. "microk8s add-node" will give you a **one-time usage** token, which you can use on a worker node to actually "join" the cluster. This process must be repeated on all the worker nodes.
 
 ### Exaflow Deployment
@@ -182,9 +170,11 @@ For a more in-depth guide on deploying Exaflow, please refer to the documentatio
   ```
 
 * Copy `values.yaml` to `/opt/mip-deployment/kubernetes/my-values.yaml` and tailor it to your environment.
+  * On microk8s, keep `cluster.managed: false` so the chart uses the local storage class it bootstraps.
 * Deploy (or upgrade) the Helm release with your customised values
   ```
   microk8s helm3 upgrade --install mip \
+    --namespace <target-namespace> \
     -f /opt/mip-deployment/kubernetes/my-values.yaml \
     /opt/mip-deployment/kubernetes
   ```