Load configuration from files instead of ConfigMaps

[AndersBennedsgaard]

/kind feature

Why you need this feature:

The actual centraldashboard-config ConfigMap is read every time a user interacts with the central dashboard. This puts unnecessary load on the Kubernetes API server, and increases latency for the dashboard.

Describe the solution you'd like:

I propose that the configuration is read from files mounted with the ConfigMap instead, using simple Pod volumes and volume mounts. The resulting Deployment would look something like:

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: centraldashboard
  name: centraldashboard
spec:
  replicas: 1
  selector:
    matchLabels:
      app: centraldashboard
  template:
    metadata:
      labels:
        app: centraldashboard
      annotations:
        sidecar.istio.io/inject: "true"
    spec:
      containers:
        - name: centraldashboard
          image: docker.io/kubeflownotebookswg/centraldashboard
          imagePullPolicy: IfNotPresent
          livenessProbe:
            httpGet:
              path: /healthz
              port: 8082
            initialDelaySeconds: 30
            periodSeconds: 30
          ports:
            - containerPort: 8082
              protocol: TCP
          env:
            - name: USERID_HEADER
              value: CD_USERID_HEADER_PLACEHOLDER
            - name: USERID_PREFIX
              value: CD_USERID_PREFIX_PLACEHOLDER
            - name: PROFILES_KFAM_SERVICE_HOST
              value: profiles-kfam.kubeflow
            - name: REGISTRATION_FLOW
              value: CD_REGISTRATION_FLOW_PLACEHOLDER
            - name: LOGOUT_URL
              value: "/authservice/logout"
            - name: POD_NAMESPACE
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace
          volumeMounts:
            - name: centraldashboard-config
              mountPath: /etc/centraldashboard # can be changed
      volumes:
        - name: centraldashboard-config
          configMap:
            name: centraldashboard-config
      serviceAccountName: centraldashboard

(adapted from https://github.com/kubeflow/kubeflow/blob/master/components/centraldashboard/manifests/base/deployment.yaml)

Instead of calling the KubeAPI server on every GET, the dashboard would just have to parse files mounted somewhere in the container.
It would also be possible to get dynamic updates to the dashboard, since files mounted in this way are dynamically updated in the container, so we don't need to restart the deployment on config change.

Related lines of code:

https://github.com/kubeflow/kubeflow/blob/bd7f250df22e144b114177536309d28651b4ddbb/components/centraldashboard/app/api.ts#L82-L111

https://github.com/kubeflow/kubeflow/blob/bd7f250df22e144b114177536309d28651b4ddbb/components/centraldashboard-angular/backend/app/api.ts#L72-L101

[rookiehelm]

I would support having files for all configurations. Right now, it's very cluttered especially for provider specific variables, one has to go through the source code just for installation.

[andreyvelich]

/transfer dashboard

[google-oss-prow]

@AndersBennedsgaard: The label(s) kind/feature cannot be applied, because the repository doesn't have them.

In response to this:

/kind feature

Why you need this feature:

The actual centraldashboard-config ConfigMap is read every time a user interacts with the central dashboard. This puts unnecessary load on the Kubernetes API server, and increases latency for the dashboard.

Describe the solution you'd like:

I propose that the configuration is read from files mounted with the ConfigMap instead, using simple Pod volumes and volume mounts. The resulting Deployment would look something like:

apiVersion: apps/v1
kind: Deployment
metadata:
 labels:
   app: centraldashboard
 name: centraldashboard
spec:
 replicas: 1
 selector:
   matchLabels:
     app: centraldashboard
 template:
   metadata:
     labels:
       app: centraldashboard
     annotations:
       sidecar.istio.io/inject: "true"
   spec:
     containers:
       - name: centraldashboard
         image: docker.io/kubeflownotebookswg/centraldashboard
         imagePullPolicy: IfNotPresent
         livenessProbe:
           httpGet:
             path: /healthz
             port: 8082
           initialDelaySeconds: 30
           periodSeconds: 30
         ports:
           - containerPort: 8082
             protocol: TCP
         env:
           - name: USERID_HEADER
             value: CD_USERID_HEADER_PLACEHOLDER
           - name: USERID_PREFIX
             value: CD_USERID_PREFIX_PLACEHOLDER
           - name: PROFILES_KFAM_SERVICE_HOST
             value: profiles-kfam.kubeflow
           - name: REGISTRATION_FLOW
             value: CD_REGISTRATION_FLOW_PLACEHOLDER
           - name: LOGOUT_URL
             value: "/authservice/logout"
           - name: POD_NAMESPACE
             valueFrom:
               fieldRef:
                 fieldPath: metadata.namespace
         volumeMounts:
           - name: centraldashboard-config
             mountPath: /etc/centraldashboard # can be changed
     volumes:
       - name: centraldashboard-config
         configMap:
           name: centraldashboard-config
     serviceAccountName: centraldashboard

(adapted from https://github.com/kubeflow/kubeflow/blob/master/components/centraldashboard/manifests/base/deployment.yaml)

Instead of calling the KubeAPI server on every GET, the dashboard would just have to parse files mounted somewhere in the container.
It would also be possible to get dynamic updates to the dashboard, since files mounted in this way are dynamically updated in the container, so we don't need to restart the deployment on config change.

Related lines of code:

https://github.com/kubeflow/kubeflow/blob/bd7f250df22e144b114177536309d28651b4ddbb/components/centraldashboard/app/api.ts#L82-L111

https://github.com/kubeflow/kubeflow/blob/bd7f250df22e144b114177536309d28651b4ddbb/components/centraldashboard-angular/backend/app/api.ts#L72-L101

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[juliusvonkohout]

/lifecycle frozen