Per-workspace backup status tracking #1549
The backup controller now tracks backup status individually for each DevWorkspace using annotations. When a backup job completes or fails, the following annotations are set on the DevWorkspace:
controller.devfile.io/last-backup-time: timestamp of the last backup attemptcontroller.devfile.io/last-backup-successful: whether the last backup succeeded
This allows the controller to determine when each workspace needs a new backup based on its own backup history rather than a global timestamp.
Restore workspace from backup #1525
DevWorkspaces can now be restored from a backup by setting the controller.devfile.io/restore-workspace: 'true' attribute. When this attribute is set, the workspace deployment includes a restore init container that pulls the backed-up /projects content from an OCI registry instead of cloning from Git.
By default, the restore source is derived from the admin-configured registry at <registry>/<namespace>/<workspace>:latest. Users can optionally specify a custom source image using the controller.devfile.io/restore-source-image attribute.
kind: DevWorkspace
spec:
template:
attributes:
controller.devfile.io/restore-workspace: 'true'
# Optional: restore from a specific image instead of the default backup registry
controller.devfile.io/restore-source-image: 'registry.example.com/my-backup:latest'Configurable backup job retry limit #1579
Administrators can now configure the maximum number of retries for backup jobs in the DevWorkspaceOperatorConfig via the backoffLimit field. The default value is 1.
apiVersion: controller.devfile.io/v1alpha1
kind: DevWorkspaceOperatorConfig
metadata:
name: devworkspace-operator-config
config:
workspace:
backupCronJob:
backoffLimit: 5Inject HOST_USERS environment variable for user namespace configuration #1582
When hostUsers is set to false in the workspace configuration, the HOST_USERS=false environment variable is now automatically injected into workspace containers. This allows container images to detect that they are running in a dedicated user namespace and adjust their behavior accordingly.
- Sort automount configmaps and secrets to ensure deterministic ordering #1578
- Set owner reference for image-builder rolebindings to enable cleanup on DevWorkspace deletion #1590
- Fix trailing slashes in registry path causing malformed image references #1592
- Update Go to 1.25.7 #1574
Implement backup feature for DevWorkspaces #1524
An automated backup mechanism is now available for non-ephemeral DevWorkspaces. The backup feature can be configured through the DevWorkspaceOperatorConfig to periodically backup workspace /project content.
The backup process:
- Identifies stopped DevWorkspaces from a configurable time period
- Creates a Job in the user's namespace to generate a container image containing
/projectsfrom the DevWorkspace's PVC - Pushes the backup image to an external image registry
See docs/dwo-configuration.md for configuration details.
Add the ability to configure custom init containers #1559
Cluster administrators can now configure custom init containers for DevWorkspaces in the DevWorkspaceOperatorConfig.
Example use cases are:
- Injecting custom configuration and tools
- Overriding the built-in
init-persistent-homelogic by providing a custom container with the same name
Example configuration:
apiVersion: controller.devfile.io/v1alpha1
kind: DevWorkspaceOperatorConfig
metadata:
name: devworkspace-operator-config
config:
workspace:
initContainers:
- name: install-tools
image: custom-image:latest
command: ["/bin/sh", "-c"]
args:
- |
echo "Setting up custom tools"
mkdir -p /home/user/custom-toolsSee docs/dwo-configuration.md for configuration details.
Add container resource caps enforcement #1561
Administrators can now set maximum resource limits and requests for workspace containers through the DevWorkspaceOperatorConfig. This prevents users from creating DevWorkspaces with excessive CPU or memory requirements.
Example configuration:
apiVersion: controller.devfile.io/v1alpha1
kind: DevWorkspaceOperatorConfig
metadata:
name: devworkspace-operator-config
config:
workspace:
containerResourceCaps:
limits:
cpu: "1"
memory: 2Gi
requests:
cpu: "0.1"
memory: 100MiWhen a container specifies resource requirements exceeding the caps, they will be limited to the configured maximum values.
- Fix project clone image missing UID 1234 in /etc/passwd #1560
Improved debugging for failing postStart commands #1538
Previously, if a postStart command failed, the container would often crash and enter CrashLoopBackOff loop, making it difficult to debug the reason for the postStart command failure.
With this release, when the controller.devfile.io/debug-start: "true" annotation is set on a failing DevWorkspace, any failure in a postStart command will cause the container to sleep for a configured duration (based on config.workspace.progressTimeout in the DevWorkspaceOperatorConfig) instead of terminating.
This gives the opportunity exec into the failing container and inspect logs in the /tmp/poststart-stdout.txt and /tmp/poststart-stderr.txt files to determine the root cause of the failure.
- Set readOnlyRootFilesystem for deployments to true #1534
- Make container status check less restrictive #1528
- Increase default per-workspace PVC size from 5Gi to 10Gi #1514
Add hostUsers field to DWOC #1493
The DevWorkspace pod's spec.hostUsers field can now be set in the DevWorkspaceOperatorConfig:
apiVersion: controller.devfile.io/v1alpha1
kind: DevWorkspaceOperatorConfig
metadata:
name: devworkspace-operator-config
config:
workspace:
hostUsers: false
Setting the spec.hostUsers field to false is useful when leveraging user-namespaces for pods.
Note: This field is only respected when the UserNamespacesSupport feature is enabled in the cluster. If the feature is disabled, setting hostUsers: false may lead to an endless workspace start loop.
Provide timeout for postStart events #1496
A timeout can now be configured for postStart events to prevent workspace pods from being stuck in a terminating state:
apiVersion: controller.devfile.io/v1alpha1
kind: DevWorkspaceOperatorConfig
metadata:
name: devworkspace-operator-config
config:
workspace:
postStartTimeout: '30s'
By default, this timeout is disabled.
- Add E2E test to verify that DevWorkspace contents are persisted during restarts #1467
- make run fails on m4 MacBook #1494
- Upgrade Go toolchain to 1.24.6 #1509
- Remove group writable permissions from container images #1516
Remove kube-rbac-proxy from the controller Deployment #1437
The kube-rbac-proxy container is now removed from the devworkspace-controller-manager Deployment. Instead, the metrics endpoint is protected with the WithAuthenticationAndAuthorization feature provided by the controller-runtime project.
This allows setting only the controller container's resource constraints using the Subscription resource as defined here. The resource constraints defined in the Subscription apply the constraints to all containers in the devworkspace-controller-manager Deployment. As a result, previously both the controller and kube-rbac-proxy container's constraints were updated, when in most cases only the controller container was the desired container to be updated.
Execute preStart devfile events after the project-clone init-container has run #1454
The project-clone init container is now the first init container for DevWorkspace Pods. This ensures that the project is already cloned when running pre-start events defined in the Devfile.
Make workspace PVC's Access mode configurable #1019
It is now possible to configure the storage access mode of per-user and per-workspace PVCs from the global DevWorkspaceOperatorConfig. For example:
apiVersion: controller.devfile.io/v1alpha1
kind: DevWorkspaceOperatorConfig
metadata:
name: devworkspace-operator-config
namespace: $OPERATOR_INSTALL_NAMESPACE
config:
workspace:
imagePullPolicy: Always
storageAccessMode:
- ReadWriteMany