[WORKBENCH] Incorrect order of Launcher.profiles

[TheisFerre]

I am using Workbench Kubernetes in AKS, where i want to use the launcher profiles to configure sessions for different users. I am using Helm chart version 0.5.26 to deploy Workbench.

I have four profiles in the following order in my helm values:

1. @auto-az-workben-prod-base-r
2. @auto-az-workben-prod-medium-r
3. @auto-az-workben-prod-large-r
4. @auto-az-workben-prod-gpu-r

When i look into the Workbench pod where it is mounted, the order is not the same. It seems to be in alphabetical order as follows:

1. @auto-az-workben-prod-base-r
2. @auto-az-workben-prod-gpu-r
3. @auto-az-workben-prod-large-r
4. @auto-az-workben-prod-medium-r

From your documentation (https://docs.posit.co/job-launcher/latest/kube.html) you write that the profiles are ordered from top to bottom, which is not the case.

See the attached images for more detail

[colearendt]

Ugh. You're right 😢

I am not quite sure how we can fix this. I will have to do some noodling! Unfortunately, the names of the groups are considered a "map" and by definition in Golang, maps are unordered 😭

As a fix in the interim (if it can be called a "fix"), you can always inline a file yourself:

launcher.kubernetes.profiles.conf: |
  [@my-order]
  [@will-be]
  [@preserved]

Unfortunately, that removes all of the benefits of how we can help generate your file though... and it conflicts with how we handle profiles, so you have to put it under config.server too 😭 That's definitely a bug we can fix.

config:
  server:
    launcher.kubernetes.profiles.conf: |
      [@my-order]
      [@will-be]
      [@preserved]

[colearendt]

Looks like another possible workaround:

helm/charts/rstudio-library/templates/_profiles.tpl

Lines 33 to 34 in c48d94f

	{{- include "rstudio-library.debug.type-check" (dict "name" "config data" "object" $data "expected" "map" "description" "of section headers and configuration" ) }}
	{{- range $key, $config := $data -}}

• allow for strings here
• allow putting an array here, and concatenate the results somehow (since lists are ordered)... this is somewhat advanced and may not be worth it 😓

[samssann]

Hi @colearendt

I got the following error trying to workaround the problem

helm.go:84: [debug] template: rstudio-workbench/templates/NOTES.txt:44:53: executing "rstudio-workbench/templates/NOTES.txt" at <"launcher.kubernetes.profiles.conf">: range can't iterate over 
[*]
allow-custom-resources=0
allow-unknown-images=0
...

the values.yaml

config:
  server:
    ...
    launcher.kubernetes.profiles.conf: |
      [*]
      allow-custom-resources=0
      allow-unknown-images=0
      resource-profiles=small
      [@sgz_rsw_prod_user]
      allow-unknown-images=0
      placement-constraints=topology.kubernetes.io/region:westeurope
      resource-profiles=small
      [@sgz_rsw_prod_power]
      allow-unknown-images=0
      placement-constraints=topology.kubernetes.io/region:westeurope
      resource-profiles=small,power
      [@sgz_rsw_prod_advanced]
      allow-custom-resources=1
      allow-unknown-images=1
      placement-constraints=topology.kubernetes.io/region:westeurope
      resource-profiles=small,power,advanced
    ...
  profiles:
    launcher.kubernetes.profiles.conf: |
      [*]
      allow-custom-resources=0
      allow-unknown-images=0
      resource-profiles=small
      [@sgz_rsw_prod_user]
      allow-unknown-images=0
      placement-constraints=topology.kubernetes.io/region:westeurope
      resource-profiles=small
      [@sgz_rsw_prod_power]
      allow-unknown-images=0
      placement-constraints=topology.kubernetes.io/region:westeurope
      resource-profiles=small,power
      [@sgz_rsw_prod_advanced]
      allow-custom-resources=1
      allow-unknown-images=1
      placement-constraints=topology.kubernetes.io/region:westeurope
      resource-profiles=small,power,advanced

What am I missing?

[MariaSemple]

Hi @samssann, thanks for filing this issue! This is an unfortunate behaviour, we'd definitely like to see this get fixed. Did you end up finding a viable solution? We're going to do some additional investigation to see if we can find a way to preserve order in the helm charts for the long term.