From c5b3863f61768c6a00f8f234554bc2675f529bd6 Mon Sep 17 00:00:00 2001 From: Tasko Olevski Date: Wed, 23 Mar 2022 08:55:38 +0100 Subject: [PATCH 1/7] chore: add native Rstudio sessions rfc --- .../004-native-rstudio-sessions.md | 241 ++++++++++++++++++ 1 file changed, 241 insertions(+) create mode 100644 design/004-native-rstudio-sessions/004-native-rstudio-sessions.md diff --git a/design/004-native-rstudio-sessions/004-native-rstudio-sessions.md b/design/004-native-rstudio-sessions/004-native-rstudio-sessions.md new file mode 100644 index 0000000..8db72e6 --- /dev/null +++ b/design/004-native-rstudio-sessions/004-native-rstudio-sessions.md @@ -0,0 +1,241 @@ +- Start Date: 22-03-2022 +- Status: Proposed + +# Native Rstudio Sessions + +## Summary + +Enable Amalthea to support native Rstudio sessions without relying on jupyterlab. +In order to tackle this problem this proposal also tries to make Amalthea even more +general and adaptable so that in the future we can accomodate similar "native" sessions +if the need arises. + +## Motivation + +The reason for this is that a large portion of Renku users are actually R users. +As such they rely on our R images and Rstudio. But these images include all of the +regular stuff that a python/jupyterlab image contains in addition to R and Rstudio. +Therefore these images have a problems: +- they take long to build +- they are large +- they are a bit hard to maintain because you have to setup all of the jupyter-rstudio +proxying and make sure that works + +## Design Detail + +Amalthea (and by extension the notebook service) should support native Rstudio sessions. + +Requirements for this feature are: +- Have one k8s resource for both Jupyter and Rstudio sessions. Relying on a different CRD +for each session type is not feasible because: (1) the notebook service has to do extra +work to merge responses from multiple calls to the k8s API, (2) the performance of the notebook +service degrades the more calls it has to make. +- Enable Amalthea / notebook service to accomodate other types of "custom"/"native" sessions +that may (and will) come up in the future. For now we only have a need for Rstudio-native sessions +but it is very likely in the future a different type of sessions may be needed. + +### Current workflow for sessions in Amalthea + +```mermaid +graph TD + style A2 fill:#f00 + A1[Read k8s manifest] + A2[Read hardcoded Jinja templates] + B[Parse variables from k8s manifest] + C[Parse patches from k8s manifest] + D[Render Jinja tempaltes to yaml] + E[Patch yaml] + F[Create k8s resources] + + A1 --> B + A1 --> C + B --> D + A2 --> D + D --> E + C --> E + E --> F +``` + +There are a lot of assumptions that we "bake into" the hardcoded Jinja templates. +Then further in the Amalthea code we further reinforce and rely on these. + +### More flexibility + +Make the "base Jinja templates" be a resource in k8s that users add. The current +Jupyterserver templates can be one of many that are used. Any assumptions or strong decisions +made about structure, organization, etc. Can be made there. + +```mermaid +graph TD + style C1 fill:#f00 + style A2 fill:#f00 + A1[Read k8s manifest] + A2[Read fewer hardcoded Jinja templates] + B[Parse variables from k8s manifest] + C[Parse patches from k8s manifest] + C1[Parse Jinja configmap from k8s manifest] + D[Render Jinja tempaltes to yaml] + E[Patch yaml] + F[Create k8s resources] + + A1 --> B + A1 --> C + A1 --> C1 + B --> D + C1 --> D + A2 --> D + D --> E + C --> E + E --> F +``` + +### Current assumptions hardcoded in Amalthea Jinja templates +- Session is a statefulset, contains session container and authentication proxy +- Session container listens on port 8888 +- Authentication proxy listens on port 4180 +- Service points to authentication proxy (4180) +- Ingress points to service which leads only to authentication proxy +- Secrets for Jupyterlab and authentication +- Configmap for Jupyterlab config (mounted in session container) +- PVC for session storage + +### Some of these assumptions will remain hardcoded +- PVC/Storage, but expect the user to patch in volume mount +- Ingress, keep as is point service to auth proxy +- Authentication, keep as is port 4180 is only entry and it goes through the auth proxy + +### Why not move everything to configmaps and make zero assumptions? +- Then the Amalthea manifest is useless. The spec for amalthea just needs one field that points to a configmap that is then rendered and a list of patches. +- The manifest also is a way to "surface" useful information about the session. I.e. about resources, ingress, +storage, authentication. + +### Current manifest + +```yaml +spec: + culling: + idleSecondsThreshold: 0 + maxAgeSecondsThreshold: 0 + auth: + oidc: + authorizedEmails: + - + authorizedGroups: [] + clientId: OidcClientName + clientSecret: + value: OidcSecretValue + enabled: true + issuerUrl: https://dev.renku.ch/auth/realms/Renku + token: "" + jupyterServer: + defaultUrl: + image: + resources: + rootDir: /home/jovyanl/work/ + routing: + host: dev.renku.ch + ingressAnnotations: + kubernetes.io/ingress.class: nginx + nginx.ingress.kubernetes.io/proxy-body-size: "0" + nginx.ingress.kubernetes.io/proxy-buffer-size: 8k + nginx.ingress.kubernetes.io/proxy-request-buffering: "off" + path: /sessions/ + tls: + enabled: true + secretName: dev-renku-ch-tls + storage: + pvc: + enabled: + mountPath: /home/jovyanl/work + storageClassName: + size: +``` + +### Proposed revised manifest + +```yaml +spec: + template: + configMap: + name: jupyter-configmap + culling: + idleCheckEndpoint: + idleSecondsThreshold: 0 + maxAgeSecondsThreshold: 0 + auth: + oidc: + token: + servers: + - containerName: jupyter-server + url: /lab + image: + resources: + requests: + memory: 1G + cpu: 1 + port: 8889 + storage: + pvc: + enabled: true + mountPath: /home/jovyanl/work + storageClassName: cinder-csi + size: 1G + livenessProbe: {} + readinessProbe: {} + startupProbe: {} + routing: + host: dev.renku.ch + ingressAnnotations: + kubernetes.io/ingress.class: nginx + nginx.ingress.kubernetes.io/proxy-body-size: "0" + nginx.ingress.kubernetes.io/proxy-buffer-size: 8k + nginx.ingress.kubernetes.io/proxy-request-buffering: "off" + path: /sessions/ + tls: + enabled: true + secretName: dev-renku-ch-tls +``` + +### Ingress + +```mermaid +graph LR + Internet[Internet] + Internet --> Ingress[Ingress] + subgraph K8s + Ingress --> Auth[Auth proxy
:4180
/sesssion/name] + subgraph Pod + Auth --> Traefik[Traefik
:8888] + Traefik --> S1[Server 1
:8889
/lab] + Traefik --> S2[Server 2
:8890
/dashboard] + end + end +``` + +### Anonymous sessions +Remove auth proxy, get Traefik to do simple token-based auth. + +## Drawbacks + +We can decide to not do this because currently Rstudio sessions work well. And yes our images +for Rstudio are big and bloated but they work. Changing things introduces the risk of bugs and +requires more effort. + +However I believe that the payoff from enable native Rstudio sessions and even more importantly +from making Amalthea and the notebook service more general is worth it. + +## Rationale and Alternatives + +> Why is this design the best in the space of possible designs? + +> What other designs have been considered and what is the rationale for not choosing them? + +> What is the impact of not doing this? + +## Unresolved questions + +> What parts of the design do you expect to resolve through the RFC process before this gets merged? + +> What parts of the design do you expect to resolve through the implementation of this feature before stabilisation? + +> What related issues do you consider out of scope for this RFC that could be addressed in the future independently of the solution that comes out of this RFC? From 1bfff2f28aa9783bef20e443c3982cdcfd70a9f5 Mon Sep 17 00:00:00 2001 From: Tasko Olevski Date: Wed, 23 Mar 2022 10:22:14 +0100 Subject: [PATCH 2/7] chore: modify crd --- .../004-native-rstudio-sessions.md | 46 +++++++++++-------- 1 file changed, 27 insertions(+), 19 deletions(-) diff --git a/design/004-native-rstudio-sessions/004-native-rstudio-sessions.md b/design/004-native-rstudio-sessions/004-native-rstudio-sessions.md index 8db72e6..8a273d8 100644 --- a/design/004-native-rstudio-sessions/004-native-rstudio-sessions.md +++ b/design/004-native-rstudio-sessions/004-native-rstudio-sessions.md @@ -159,30 +159,38 @@ spec: configMap: name: jupyter-configmap culling: - idleCheckEndpoint: + idleCheckEndpoint: http://jupyter-server/active idleSecondsThreshold: 0 maxAgeSecondsThreshold: 0 auth: oidc: token: - servers: - - containerName: jupyter-server - url: /lab - image: - resources: - requests: - memory: 1G - cpu: 1 - port: 8889 - storage: - pvc: - enabled: true - mountPath: /home/jovyanl/work - storageClassName: cinder-csi - size: 1G - livenessProbe: {} - readinessProbe: {} - startupProbe: {} + server: + containerName: jupyter-server + image: + resources: + requests: + memory: 1G + cpu: 1 + ingress: + - port: 8889 + url: /lab + - port: 8890 + url: /active + - port: 8891 + url: /dashboard + storage: + pvc: + enabled: true + storageClassName: cinder-csi + size: 1G + mountPath: /home/jovyan/work + livenessProbe: {} + readinessProbe: {} + startupProbe: {} + auxContainers: + # same structure as server, but list + # add option to mount main server storage as read only in a specific place routing: host: dev.renku.ch ingressAnnotations: From f0be2ac15093347010cc13f97f37206f25c4c691 Mon Sep 17 00:00:00 2001 From: Tasko Olevski Date: Wed, 23 Mar 2022 14:28:14 +0100 Subject: [PATCH 3/7] chore: add multi container session rfc --- .../004-native-rstudio-sessions.md | 249 ------------------ .../005-multi-container-sessions.md | 163 ++++++++++++ 2 files changed, 163 insertions(+), 249 deletions(-) delete mode 100644 design/004-native-rstudio-sessions/004-native-rstudio-sessions.md create mode 100644 design/005-multi-container-sessions/005-multi-container-sessions.md diff --git a/design/004-native-rstudio-sessions/004-native-rstudio-sessions.md b/design/004-native-rstudio-sessions/004-native-rstudio-sessions.md deleted file mode 100644 index 8a273d8..0000000 --- a/design/004-native-rstudio-sessions/004-native-rstudio-sessions.md +++ /dev/null @@ -1,249 +0,0 @@ -- Start Date: 22-03-2022 -- Status: Proposed - -# Native Rstudio Sessions - -## Summary - -Enable Amalthea to support native Rstudio sessions without relying on jupyterlab. -In order to tackle this problem this proposal also tries to make Amalthea even more -general and adaptable so that in the future we can accomodate similar "native" sessions -if the need arises. - -## Motivation - -The reason for this is that a large portion of Renku users are actually R users. -As such they rely on our R images and Rstudio. But these images include all of the -regular stuff that a python/jupyterlab image contains in addition to R and Rstudio. -Therefore these images have a problems: -- they take long to build -- they are large -- they are a bit hard to maintain because you have to setup all of the jupyter-rstudio -proxying and make sure that works - -## Design Detail - -Amalthea (and by extension the notebook service) should support native Rstudio sessions. - -Requirements for this feature are: -- Have one k8s resource for both Jupyter and Rstudio sessions. Relying on a different CRD -for each session type is not feasible because: (1) the notebook service has to do extra -work to merge responses from multiple calls to the k8s API, (2) the performance of the notebook -service degrades the more calls it has to make. -- Enable Amalthea / notebook service to accomodate other types of "custom"/"native" sessions -that may (and will) come up in the future. For now we only have a need for Rstudio-native sessions -but it is very likely in the future a different type of sessions may be needed. - -### Current workflow for sessions in Amalthea - -```mermaid -graph TD - style A2 fill:#f00 - A1[Read k8s manifest] - A2[Read hardcoded Jinja templates] - B[Parse variables from k8s manifest] - C[Parse patches from k8s manifest] - D[Render Jinja tempaltes to yaml] - E[Patch yaml] - F[Create k8s resources] - - A1 --> B - A1 --> C - B --> D - A2 --> D - D --> E - C --> E - E --> F -``` - -There are a lot of assumptions that we "bake into" the hardcoded Jinja templates. -Then further in the Amalthea code we further reinforce and rely on these. - -### More flexibility - -Make the "base Jinja templates" be a resource in k8s that users add. The current -Jupyterserver templates can be one of many that are used. Any assumptions or strong decisions -made about structure, organization, etc. Can be made there. - -```mermaid -graph TD - style C1 fill:#f00 - style A2 fill:#f00 - A1[Read k8s manifest] - A2[Read fewer hardcoded Jinja templates] - B[Parse variables from k8s manifest] - C[Parse patches from k8s manifest] - C1[Parse Jinja configmap from k8s manifest] - D[Render Jinja tempaltes to yaml] - E[Patch yaml] - F[Create k8s resources] - - A1 --> B - A1 --> C - A1 --> C1 - B --> D - C1 --> D - A2 --> D - D --> E - C --> E - E --> F -``` - -### Current assumptions hardcoded in Amalthea Jinja templates -- Session is a statefulset, contains session container and authentication proxy -- Session container listens on port 8888 -- Authentication proxy listens on port 4180 -- Service points to authentication proxy (4180) -- Ingress points to service which leads only to authentication proxy -- Secrets for Jupyterlab and authentication -- Configmap for Jupyterlab config (mounted in session container) -- PVC for session storage - -### Some of these assumptions will remain hardcoded -- PVC/Storage, but expect the user to patch in volume mount -- Ingress, keep as is point service to auth proxy -- Authentication, keep as is port 4180 is only entry and it goes through the auth proxy - -### Why not move everything to configmaps and make zero assumptions? -- Then the Amalthea manifest is useless. The spec for amalthea just needs one field that points to a configmap that is then rendered and a list of patches. -- The manifest also is a way to "surface" useful information about the session. I.e. about resources, ingress, -storage, authentication. - -### Current manifest - -```yaml -spec: - culling: - idleSecondsThreshold: 0 - maxAgeSecondsThreshold: 0 - auth: - oidc: - authorizedEmails: - - - authorizedGroups: [] - clientId: OidcClientName - clientSecret: - value: OidcSecretValue - enabled: true - issuerUrl: https://dev.renku.ch/auth/realms/Renku - token: "" - jupyterServer: - defaultUrl: - image: - resources: - rootDir: /home/jovyanl/work/ - routing: - host: dev.renku.ch - ingressAnnotations: - kubernetes.io/ingress.class: nginx - nginx.ingress.kubernetes.io/proxy-body-size: "0" - nginx.ingress.kubernetes.io/proxy-buffer-size: 8k - nginx.ingress.kubernetes.io/proxy-request-buffering: "off" - path: /sessions/ - tls: - enabled: true - secretName: dev-renku-ch-tls - storage: - pvc: - enabled: - mountPath: /home/jovyanl/work - storageClassName: - size: -``` - -### Proposed revised manifest - -```yaml -spec: - template: - configMap: - name: jupyter-configmap - culling: - idleCheckEndpoint: http://jupyter-server/active - idleSecondsThreshold: 0 - maxAgeSecondsThreshold: 0 - auth: - oidc: - token: - server: - containerName: jupyter-server - image: - resources: - requests: - memory: 1G - cpu: 1 - ingress: - - port: 8889 - url: /lab - - port: 8890 - url: /active - - port: 8891 - url: /dashboard - storage: - pvc: - enabled: true - storageClassName: cinder-csi - size: 1G - mountPath: /home/jovyan/work - livenessProbe: {} - readinessProbe: {} - startupProbe: {} - auxContainers: - # same structure as server, but list - # add option to mount main server storage as read only in a specific place - routing: - host: dev.renku.ch - ingressAnnotations: - kubernetes.io/ingress.class: nginx - nginx.ingress.kubernetes.io/proxy-body-size: "0" - nginx.ingress.kubernetes.io/proxy-buffer-size: 8k - nginx.ingress.kubernetes.io/proxy-request-buffering: "off" - path: /sessions/ - tls: - enabled: true - secretName: dev-renku-ch-tls -``` - -### Ingress - -```mermaid -graph LR - Internet[Internet] - Internet --> Ingress[Ingress] - subgraph K8s - Ingress --> Auth[Auth proxy
:4180
/sesssion/name] - subgraph Pod - Auth --> Traefik[Traefik
:8888] - Traefik --> S1[Server 1
:8889
/lab] - Traefik --> S2[Server 2
:8890
/dashboard] - end - end -``` - -### Anonymous sessions -Remove auth proxy, get Traefik to do simple token-based auth. - -## Drawbacks - -We can decide to not do this because currently Rstudio sessions work well. And yes our images -for Rstudio are big and bloated but they work. Changing things introduces the risk of bugs and -requires more effort. - -However I believe that the payoff from enable native Rstudio sessions and even more importantly -from making Amalthea and the notebook service more general is worth it. - -## Rationale and Alternatives - -> Why is this design the best in the space of possible designs? - -> What other designs have been considered and what is the rationale for not choosing them? - -> What is the impact of not doing this? - -## Unresolved questions - -> What parts of the design do you expect to resolve through the RFC process before this gets merged? - -> What parts of the design do you expect to resolve through the implementation of this feature before stabilisation? - -> What related issues do you consider out of scope for this RFC that could be addressed in the future independently of the solution that comes out of this RFC? diff --git a/design/005-multi-container-sessions/005-multi-container-sessions.md b/design/005-multi-container-sessions/005-multi-container-sessions.md new file mode 100644 index 0000000..07f9cb7 --- /dev/null +++ b/design/005-multi-container-sessions/005-multi-container-sessions.md @@ -0,0 +1,163 @@ +- Start Date: 22-03-2022 +- Status: Proposed + +# Native Rstudio Sessions + +## Summary + +Enable Amalthea to support defining more than one container that is exposed and accessible not +just the regular /lab endpoint. In the case of Rstudio currently we support both /lab and /studio +but the proxying for this is done at the Jupyterlab level. The idea here is that such proxying +should be done by Amalthea. + +## Motivation + +- Users can run additional programs like dashboards beside their regular session +- We can run alternative UIs like vscode or rstudio alongside jupyterlab without relying on the proxying +from rstudio +- We further generalize Amalthea to accept any type of service/container + +## Design Detail + +### Current manifest + +```yaml +spec: + culling: + idleSecondsThreshold: 0 + maxAgeSecondsThreshold: 0 + auth: + oidc: + authorizedEmails: + - + authorizedGroups: [] + clientId: OidcClientName + clientSecret: + value: OidcSecretValue + enabled: true + issuerUrl: https://dev.renku.ch/auth/realms/Renku + token: "" + jupyterServer: + defaultUrl: + image: + resources: + rootDir: /home/jovyanl/work/ + routing: + host: dev.renku.ch + ingressAnnotations: + kubernetes.io/ingress.class: nginx + nginx.ingress.kubernetes.io/proxy-body-size: "0" + nginx.ingress.kubernetes.io/proxy-buffer-size: 8k + nginx.ingress.kubernetes.io/proxy-request-buffering: "off" + path: /sessions/ + tls: + enabled: true + secretName: dev-renku-ch-tls + storage: + pvc: + enabled: + mountPath: /home/jovyanl/work + storageClassName: + size: +``` + +### Proposed revised manifest + +```yaml +spec: + template: + configMap: + name: jupyter-configmap + culling: + idleSecondsThreshold: 0 + maxAgeSecondsThreshold: 0 + idleProbe: # NEW similar syntax expected to http get k8s probe + auth: + oidc: + token: + servers: # NEW + - containerName: jupyter-server + image: + resources: + requests: + memory: 1G + cpu: 1 + ingress: + - port: 8889 + url: /lab + livenessProbe: {} + readinessProbe: {} + startupProbe: {} + - containerName: dashboard + image: + resources: + requests: + memory: 1G + cpu: 1 + ingress: + - port: 8890 + url: /dashboard + livenessProbe: {} + readinessProbe: {} + startupProbe: {} + routing: + host: dev.renku.ch + ingressAnnotations: + kubernetes.io/ingress.class: nginx + nginx.ingress.kubernetes.io/proxy-body-size: "0" + nginx.ingress.kubernetes.io/proxy-buffer-size: 8k + nginx.ingress.kubernetes.io/proxy-request-buffering: "off" + path: /sessions/ + tls: + enabled: true + secretName: dev-renku-ch-tls + storage: + pvc: + enabled: + mountPath: /home/jovyanl/work + storageClassName: + size: +``` + +### Ingress + +```mermaid +graph LR + Internet[Internet] + Internet --> Ingress[Ingress] + subgraph K8s + Ingress --> Auth[Auth proxy
:4180
/sesssion/name] + subgraph Pod + Auth --> Traefik[Traefik
:8888] + Traefik --> S1[Jupyterlab
:8889
/lab] + Traefik --> S2[Dashboard
:8890
/dashboard] + end + end +``` + +### Anonymous sessions +Remove auth proxy, get Traefik to do simple token-based auth. Alternatively also just allow anyone with the +link to the anonymous sessions to access it. The link can be generated with some random characters so that it +is hard to guess. + +## Drawbacks + +We need to add a traefik proxy in order to do this. + +We are adding a bit more complexity to the code. + +## Rationale and Alternatives + +> Why is this design the best in the space of possible designs? + +> What other designs have been considered and what is the rationale for not choosing them? + +> What is the impact of not doing this? + +## Unresolved questions + +> What parts of the design do you expect to resolve through the RFC process before this gets merged? + +> What parts of the design do you expect to resolve through the implementation of this feature before stabilisation? + +> What related issues do you consider out of scope for this RFC that could be addressed in the future independently of the solution that comes out of this RFC? From 118be35175f76f90d7ead42a3a58be888f346a91 Mon Sep 17 00:00:00 2001 From: Tasko Olevski Date: Tue, 20 Sep 2022 11:22:10 +0200 Subject: [PATCH 4/7] chore: move rfc to new location --- .../009-multi-container-sessions}/005-multi-container-sessions.md | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename {design/005-multi-container-sessions => rfcs/009-multi-container-sessions}/005-multi-container-sessions.md (100%) diff --git a/design/005-multi-container-sessions/005-multi-container-sessions.md b/rfcs/009-multi-container-sessions/005-multi-container-sessions.md similarity index 100% rename from design/005-multi-container-sessions/005-multi-container-sessions.md rename to rfcs/009-multi-container-sessions/005-multi-container-sessions.md From ea694ce7b64a6855a79afdf9c6d0f8ce6caa05c9 Mon Sep 17 00:00:00 2001 From: Tasko Olevski Date: Tue, 20 Sep 2022 11:22:48 +0200 Subject: [PATCH 5/7] chore: rename file --- ...ulti-container-sessions.md => 009-multi-container-sessions.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename rfcs/009-multi-container-sessions/{005-multi-container-sessions.md => 009-multi-container-sessions.md} (100%) diff --git a/rfcs/009-multi-container-sessions/005-multi-container-sessions.md b/rfcs/009-multi-container-sessions/009-multi-container-sessions.md similarity index 100% rename from rfcs/009-multi-container-sessions/005-multi-container-sessions.md rename to rfcs/009-multi-container-sessions/009-multi-container-sessions.md From 297d5028088d1d6af020093820f34172f88ff055 Mon Sep 17 00:00:00 2001 From: Tasko Olevski Date: Tue, 20 Sep 2022 11:28:56 +0200 Subject: [PATCH 6/7] chore: address comments --- .../009-multi-container-sessions.md | 18 ++++-------------- 1 file changed, 4 insertions(+), 14 deletions(-) diff --git a/rfcs/009-multi-container-sessions/009-multi-container-sessions.md b/rfcs/009-multi-container-sessions/009-multi-container-sessions.md index 07f9cb7..f5e8068 100644 --- a/rfcs/009-multi-container-sessions/009-multi-container-sessions.md +++ b/rfcs/009-multi-container-sessions/009-multi-container-sessions.md @@ -14,7 +14,7 @@ should be done by Amalthea. - Users can run additional programs like dashboards beside their regular session - We can run alternative UIs like vscode or rstudio alongside jupyterlab without relying on the proxying -from rstudio +from jupyterlab - We further generalize Amalthea to accept any type of service/container ## Design Detail @@ -41,14 +41,9 @@ spec: defaultUrl: image: resources: - rootDir: /home/jovyanl/work/ + rootDir: /home/jovyan/work/ routing: host: dev.renku.ch - ingressAnnotations: - kubernetes.io/ingress.class: nginx - nginx.ingress.kubernetes.io/proxy-body-size: "0" - nginx.ingress.kubernetes.io/proxy-buffer-size: 8k - nginx.ingress.kubernetes.io/proxy-request-buffering: "off" path: /sessions/ tls: enabled: true @@ -56,7 +51,7 @@ spec: storage: pvc: enabled: - mountPath: /home/jovyanl/work + mountPath: /home/jovyan/work storageClassName: size: ``` @@ -102,11 +97,6 @@ spec: startupProbe: {} routing: host: dev.renku.ch - ingressAnnotations: - kubernetes.io/ingress.class: nginx - nginx.ingress.kubernetes.io/proxy-body-size: "0" - nginx.ingress.kubernetes.io/proxy-buffer-size: 8k - nginx.ingress.kubernetes.io/proxy-request-buffering: "off" path: /sessions/ tls: enabled: true @@ -114,7 +104,7 @@ spec: storage: pvc: enabled: - mountPath: /home/jovyanl/work + mountPath: /home/jovyan/work storageClassName: size: ``` From e8706e481e790b2c6730c2f7b35fee8e77dec4dc Mon Sep 17 00:00:00 2001 From: Tasko Olevski Date: Tue, 20 Sep 2022 11:47:26 +0200 Subject: [PATCH 7/7] squashme: edits --- .../009-multi-container-sessions.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/rfcs/009-multi-container-sessions/009-multi-container-sessions.md b/rfcs/009-multi-container-sessions/009-multi-container-sessions.md index f5e8068..81acb8e 100644 --- a/rfcs/009-multi-container-sessions/009-multi-container-sessions.md +++ b/rfcs/009-multi-container-sessions/009-multi-container-sessions.md @@ -104,7 +104,6 @@ spec: storage: pvc: enabled: - mountPath: /home/jovyan/work storageClassName: size: ``` @@ -151,3 +150,6 @@ We are adding a bit more complexity to the code. > What parts of the design do you expect to resolve through the implementation of this feature before stabilisation? > What related issues do you consider out of scope for this RFC that could be addressed in the future independently of the solution that comes out of this RFC? + +> Where to mount the PVC in additional containers? Currently we mount at `/home/jovyan/work` but what if a `jovyan` user does not +exist in the image that is used to run a container? Should we be asking users for this specifically?