With the advent of external workspace routing controllers, there has arisen the need to configure them on per-workspace basis. In another words it should be possible to pass down routing class specific configuration to the external controller.
== Proposed Solution
There is a precedent for handling this kind of "polymorphism" in Kubernetes with the Ingress annotations, e.g. https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/.
I would like to propose configuring the workspace routing controller using annotations on the DevWorkspace object.
Let's say we have a workspace routing controller handling the myrouting routing class.
We would be able to configure it on the DevWorkspace object like this:
kind: DevWorkspace
apiVersion: workspace.devfile.io/v1alpha1
metadata:
name: cloud-shell
annotations:
controller.devfile.io/restricted-access: "true"
controller.devfile.io/other-cotroller-annotation: "yes"
myrouting.routingclass.controller.devfile.io/answer: "42"
spec:
started: true
routingClass: myrouting
template:
...This would create a workspace routing object with the 2 following annotations:
kind: WorkspaceRouting
apiVersion: workspace.devfile.io/v1alpha1
metadata:
name: ...
annotations:
controller.devfile.io/restricted-access: "true"
myrouting.routingclass.controller.devfile.io/answer: "42"
...The restricted-access is already being passed down by the existing code. myrouting.routingclass.controller.devfile.io/answer is considered a configuration property of the controller and therefore is passed down to the WorkspaceRouting object. controller.devfile.io/other-cotroller-annotation is NOT passed down, because it is unrelated to the workpace routing.
== Alternative Solution
We could also specify the configuration directly in the spec of the Devworkspace, e.g.:
kind: DevWorkspace
apiVersion: workspace.devfile.io/v1alpha1
metadata:
name: cloud-shell
annotations:
controller.devfile.io/restricted-access: "true"
controller.devfile.io/other-cotroller-annotation: "yes"
spec:
started: true
routingClass: myrouting
routingAnnotations:
answer: "42"
template:
...This feels a little bit less idiomatic Kubernetes to me though.
With the advent of external workspace routing controllers, there has arisen the need to configure them on per-workspace basis. In another words it should be possible to pass down routing class specific configuration to the external controller.
== Proposed Solution
There is a precedent for handling this kind of "polymorphism" in Kubernetes with the Ingress annotations, e.g. https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/.
I would like to propose configuring the workspace routing controller using annotations on the
DevWorkspaceobject.Let's say we have a workspace routing controller handling the
myroutingrouting class.We would be able to configure it on the
DevWorkspaceobject like this:This would create a workspace routing object with the 2 following annotations:
The
restricted-accessis already being passed down by the existing code.myrouting.routingclass.controller.devfile.io/answeris considered a configuration property of the controller and therefore is passed down to theWorkspaceRoutingobject.controller.devfile.io/other-cotroller-annotationis NOT passed down, because it is unrelated to the workpace routing.== Alternative Solution
We could also specify the configuration directly in the spec of the
Devworkspace, e.g.:This feels a little bit less idiomatic Kubernetes to me though.