Description
There are a few examples of workspaces Pods annotations (openshift.io/scc or runtimeClassName) or Pods spec fields (runtimeClassName, schedulerName) that users want to be able to specify.
The approach until now has been to use spec.template.attributes. But that requires code/spec changes for every new field/annotation that we want to support. To avoid that, and allow users to set arbitrary Pods fields, we could add a DevWorspace.spec.pods field for that:
kind: DevWorkspace
apiVersion: workspace.devfile.io/v1alpha2
metadata:
name: myspacework
spec:
started: true
+ pods:
+ metadata:
+ annotations:
+ io.openshift.userns: "true"
+ io.kubernetes.cri-o.userns-mode: "auto:size=65536;map-to-root=true" # <-- user namespace
+ openshift.io/scc: container-build
+ spec:
+ runtimeClassName: kata
+ schedulerName: stork
template:
(...)
Additional context
Release Notes Text
Using a Devfile in the git repository, a developer can override any workspace Pod and containers fields. This includes runtimeClassName, schedulerName and kubernetes extended resources such as nvidia.com/gpu.
Description
There are a few examples of workspaces Pods annotations (
openshift.io/sccorruntimeClassName) or Pods spec fields (runtimeClassName,schedulerName) that users want to be able to specify.The approach until now has been to use
spec.template.attributes. But that requires code/spec changes for every new field/annotation that we want to support. To avoid that, and allow users to set arbitrary Pods fields, we could add aDevWorspace.spec.podsfield for that:Additional context
Release Notes Text
Using a Devfile in the git repository, a developer can override any workspace Pod and containers fields. This includes
runtimeClassName,schedulerNameand kubernetes extended resources such asnvidia.com/gpu.