Release notes and documentation for Mendix for Private Cloud 2.21.0 (planned for release on Wednesday, February 19)

content/en/docs/deployment/private-cloud/private-cloud-cluster/_index.md

@@ -439,9 +439,11 @@ spec:
           limits:
             cpu: 1
             memory: 512Mi
+            ephemeral-storage: 4Mi
           requests:
             cpu: 100m
             memory: 512Mi
+            ephemeral-storage: 4Mi
 # ...
 # omitted lines for brevity
 # ...
@@ -462,30 +464,38 @@ spec:
     limits:
       cpu: 250m
       memory: 32Mi
+      ephemeral-storage: 4Mi
     requests:
       cpu: 100m
       memory: 16Mi
+      ephemeral-storage: 4Mi
   metricsSidecarResources:
     limits:
       cpu: 100m
       memory: 32Mi
+      ephemeral-storage: 4Mi
     requests:
       cpu: 100m
       memory: 16Mi
+      ephemeral-storage: 4Mi
   buildResources:
     limits:
       cpu: '1'
       memory: 256Mi
+      ephemeral-storage: 2Gi
     requests:
       cpu: 250m
       memory: 64Mi
+      ephemeral-storage: 2Gi
   runtimeResources:
     limits:
       cpu: 1000m
       memory: 512Mi
+      ephemeral-storage: 256Mi
     requests:
       cpu: 100m
       memory: 512Mi
+      ephemeral-storage: 256Mi
   runtimeLivenessProbe:
     initialDelaySeconds: 60
     periodSeconds: 15
@@ -629,9 +639,11 @@ resources:
   limits:
     cpu: 1
     memory: 512Mi
+    ephemeral-storage: 256Mi
   requests:
     cpu: 100m
     memory: 512Mi
+    ephemeral-storage: 256Mi
 ```
 
 This section allows the configuration of the lower and upper resource boundaries, the `requests` and `limits` respectively.
@@ -938,6 +950,20 @@ In most cases, this option is only needed when an app is partially scaled down (
 Some container runtimes or network configurations prevent a terminating pod from receiving traffic or opening new connections. The Mendix Runtime can still use its existing database connections from the connection pool and keep processing any running microflows and requests, but uploading files or calling external REST services may fail.
 {{% /alert %}}
 
+### Read-only RootFS {#readonlyrootfs}
+
+Mendix app container images are locked down by default - they run as a non-root user, cannot request elevated permissions, and file ownership and permissions prevent modification of system and critical paths. Kubernetes allows you to lock down containers even further, by mounting the container filesystem as read-only if the container's security context specifies [readOnlyRootFilesystem: true](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/). With this option enabled, any files and paths from the container image cannot be modified by any user.
+
+Starting from Mendix Operator version 2.21.0, all system containers and pods use `readOnlyRootFilesystem` by default. It is possible to specify if an environment's app container should also have a read-only filesystem. For Mendix apps, the `readOnlyRootFilesystem` option is off by default, as some Java actions in marketplace modules might expect some paths to be writable.
+
+If you enable the `runtimeReadOnlyRootFilesystem` option in the MendixApp CRD (for standalone clusters) or in the Private Cloud Portal, the Mendix app container also uses a read-only root filesystem. As Mendix apps needs certain paths to be writable, an [emptyDir](https://kubernetes.io/docs/concepts/storage/volumes/#emptydir) is used for writable paths. Each path is mounted as a separate `subPath` to keep data separated. The `emptyDir` size is set to the `ephemeral-storage` [resource limit](#advanced-resource-customization).
+
+In addition to internal Mendix Runtime paths, `/tmp` is mounted for any temporary files that might be created through Java actions. For Java actions to work correctly, ensure that they only create files in `/tmp`, for example, by using the `File.createTempFile` or `File.createTempDirectory` Java methods.
+
+{{% alert color="info" %}}
+If your app works without issues when read-only root filesystem is enabled, it is best to enable it wherever possible. We recommend using a non-production environment to validate that your app keeps working correctly with a read-only RootFS.
+{{% /alert %}}
+
 ### GKE Autopilot Workarounds {#gke-autopilot-workarounds}
 
 In GKE Autopilot, one of the key features is its ability to automatically adjust resource settings based on the observed resource utilization of the containers. GKE Autopilot verifies the resource allocations and limits for all containers, and makes adjustments to deployments when the resources are not as per its requirements.
@@ -954,16 +980,20 @@ spec:
     limits:
       cpu: "1"
       memory: 256Mi
+      ephemeral-storage: 2Gi
     requests:
       cpu: "1"
       memory: 256Mi
+      ephemeral-storage: 2Gi
   metricsSidecarResources:
     limits:
       cpu: 100m
       memory: 32Mi
+      ephemeral-storage: 4Mi
     requests:
       cpu: 100m
       memory: 32Mi
+      ephemeral-storage: 4Mi
 ```
 
 Run the following command in order to update the core resources in the `OperatorConfiguration`:

content/en/docs/deployment/private-cloud/private-cloud-operator.md

@@ -79,9 +79,11 @@ spec:
     limits: # Upper limit - process will be stopped if it tries to use more
       cpu: 500m # 500 millicores - half of a vCPU
       memory: 512Mi # 512 megabytes - suitable for small-scale non-production apps
+      ephemeral-storage: 256Mi # 256 megabytes - for temporary files such as generated Excel documents
     requests: # Lower limit - needs at least these resources
       cpu: 250m
       memory: 256Mi
+      ephemeral-storage: 256Mi
   runtimeDeploymentPodAnnotations: # Optional, can be omitted : set custom annotations for Mendix Runtime Pods
     # example: inject the Linkerd proxy sidecar
     linkerd.io/inject: enabled
@@ -173,6 +175,7 @@ spec:
     rollingUpdate:
       maxSurge: 0
       maxUnavailable: 50%
+  runtimeReadOnlyRootFilesystem: true # Optional: specify if the Mendix Runtime container should use a read-only root filesystem
 ```
 
 You need to make the following changes:
@@ -230,6 +233,7 @@ You need to make the following changes:
 * **customPodLabels** - specify additional pod labels (please avoid using labels that start with the `privatecloud.mendix.com/` prefix)
     * **general** - specify additional labels for all pods of the app
 * **deploymentStrategy** - specify parameters for the deployment strategy; for more information, see the reduced downtime deployment documentation.
+* **runtimeReadOnlyRootFilesystem** - specify if the Runtime container should mount the root filesystem in [read-only mode](/developerportal/deploy/private-cloud-cluster/#readonlyrootfs).
 
 #### Setting App Constants{#set-app-constants}
 

content/en/docs/deployment/private-cloud/private-cloud-supported-environments.md

@@ -36,7 +36,7 @@ If deploying to Red Hat OpenShift, you need to specify that specifically when cr
 
 Mendix for Private Cloud Operator `v2.*.*` is the latest version which officially supports:
 
-* Kubernetes versions 1.19 through 1.31
+* Kubernetes versions 1.19 through 1.32
 * OpenShift 4.6 through 4.17
 
 {{% alert color="warning" %}}
@@ -65,7 +65,7 @@ To install the Mendix Operator, the cluster administrator will need permissions
 * Create roles in the target namespace or project
 * Create role bindings in the target namespace or project
 
-The cluster should have at least 2 CPU cores and 2 GB memory *available*. This is enough to run one simple app - but does not include additional resources required by Kubernetes core components.
+The cluster should have at least 2 CPU cores, 2 GB memory and 3 GB ephemeral-storage available on a Kubernetes node. This is enough to run one simple app, but does not include additional resources required by Kubernetes core components.
 
 In OpenShift, the cluster administrator must have a `system:admin` role.
 

content/en/docs/deployment/private-cloud/private-cloud-upgrade-guide.md

@@ -12,11 +12,18 @@ This document describes how an existing installation of Mendix for Private Cloud
 This procedure allows you to upgrade to any supported (v1.9.0 and later) version of the Mendix for Private Cloud Operator.
 
 {{% alert color="warning" %}}
+There are special considerations that you must be aware of in the following cases:
+
+* when using the `mxpc-cli` installation and configuration tool version 2.20.1 or earlier.
+* when manually installing or upgrading CRDs with `kubectl apply`.
+
 Upgrading the Mendix for Private Cloud Operator in a namespace will modify global resources such as Mendix Custom Resource Definitions in the cluster.
 
 [Custom Resource Definitions](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/) allow Mendix applications to be managed with Kubernetes APIs and tools such as `kubectl` and `oc`.
 
 Once you have installed a particular version of the Mendix Operator into any namespace in the cluster, you should not install older versions of the Mendix Operator into the same cluster, even if they are in other namespaces. This is because all the CRDs are global resources and operators in all namespaces use the same one, which may not be compatible across versions.
+
+Starting from `mxpc-cli` version 2.21.0, the installation or upgrade process checks to see if the CRDs in the cluster are newer than the CRDs bundled with `mxpc-cli`. If the cluster has newer CRDs, `mxpc-cli` will skip the CRD installation step and avoid downgrading CRDs.
 {{% /alert %}}
 
 If you are using your own private registry, follow the [Migrating to Your Own Registry](/developerportal/deploy/private-cloud-migrating/) guide first

content/en/docs/releasenotes/deployment/mendix-for-private-cloud.md

@@ -12,6 +12,22 @@ For information on the current status of deployment to Mendix for Private Cloud
 
 ## 2025
 
+### February 19, 2025
+
+#### Mendix Operator v2.21.0 {#2.21.0}
+
+* We have switched all system containers to use a read-only root filesystem. For Mendix app containers, we added an option to use a read-only rootfs, which is disabled by default.
+* We have added a default on ephemeral storage usage to ensure that temporary file storage is reserved and is limited, so that a container gets a guaranteed amount of temporary file storage that cannot be exceeded.
+* We have added a check in `mxpc-cli` to prevent CRD downgrades; starting from `mxpc-cli` version 2.21.0, the installation or upgrade process will keep cluster CRDs unchanged if the cluster has newer CRDs than what is included with the installer.
+* We have updated components to use the latest dependency versions in order to improve security score ratings for container images.
+* We have fixed a *Failed to determine if DDL migration needs approval* error message that sometimes appeared when using a **Recreate** deployment strategy. This error message does not mean that there is an issue, and can therefore be ignored.
+* We have updated documentation with information that Kubernetes 1.32 is supported by the Mendix Operator.
+* Upgrading to Mendix Operator v2.21.0 from a previous version will restart environments managed by that version of the Operator. Environments with 2 or more replicas and a **PreferRolling** update strategy will be restarted without downtime.
+
+#### Important Upgrade Information
+
+With the introduction of ephemeral storage requests and limits, building an app requires at least 2 GB of ephemeral storage available on the Kubernetes node. If your nodes do not have enough temporary storage, the build pods cannot start and their status remains **Pending**. To resolve this issue, you can lower the values for `ephemeral-storage` in the [buildResources](/developerportal/deploy/private-cloud-cluster/#resource-definition-ocm) configuration.
+
 ### February 12, 2025
 
 #### Documentation Updates
@@ -38,7 +54,7 @@ For information on the current status of deployment to Mendix for Private Cloud
 * We have updated a library used to validate licenses to the latest non-alpha version.
 * We have updated documentation that OpenShift 4.17 and Postgres 17 are supported by the Mendix Operator.
 * We have addressed a rare deadlock situation which could prevent a failing environment from restarting.
-* Upgrading to Mendix Operator v2.20.0 from a previous version will restart environments managed by that version of the Operator. Environments with 2 or more replicas and a **PreferRolling** update strategy will be restarted without downtime.
+* Upgrading to Mendix Operator v2.20.1 from a previous version will restart environments managed by that version of the Operator. Environments with 2 or more replicas and a **PreferRolling** update strategy will be restarted without downtime.
 
 #### Known Limitations