It's not immediately obvious how the `additional*Properties` are supposed to be set

[chgl]

In the values.yaml the default value for setting additionalProperties is set as {}, suggesting that a dict object is expected: https://github.com/trinodb/charts/blob/main/charts/trino/values.yaml#L199-L207. However, in the templates this value is processed using range (https://github.com/trinodb/charts/blob/main/charts/trino/templates/configmap-coordinator.yaml#L62-L64) suggesting a list of values. In theory, using the same approach as when configuring the additionalCatalog (

charts/charts/trino/templates/configmap-catalog.yaml

Lines 22 to 25 in 533ace5

 {{- range $catalogName, $catalogProperties := .Values.additionalCatalogs }} 
   {{ $catalogName }}.properties: | 
     {{- $catalogProperties | nindent 4 }} 
 {{- end }} 

) would work:

additionalConfigProperties:
    new-properties: |
      internal-communication.shared-secret=${ENV:TRINO_SHARED_SECRET}
      http-server.process-forwarded=true
    more-properties: |
      web-ui.authentication.type=oauth2

However, the template is missing correct indentation (nindent 4). So instead one has to set the properties as a list:

  additionalConfigProperties:
    - "internal-communication.shared-secret=${ENV:TRINO_SHARED_SECRET}"
    - "http-server.process-forwarded=true"
    - "web-ui.authentication.type=oauth2"

To make configuration more consistent I would suggest to either:

1. change the type of additionalConfigProperties to string so it can be configured as follows:

     additionalConfigProperties: |
       internal-communication.shared-secret=${ENV:TRINO_SHARED_SECRET}
       http-server.process-forwarded=true
       web-ui.authentication.type=oauth2

2. Keep the type as-is, but fix the template to include nindent 4.

Personally, I'd prefer 1. since its more obvious how the string settings correspond to the trino properties. In 2. the nested new-properties, more-properties don't serve a purpose anyway.

[Jan Waś]

We need to keep them as arrays to preserve backward compatibility. I've opened #169 to fix the defaults and add proper documentation with examples.

We'd have to add extra logic to recognize when they're defined as strings. We're open to contributions, but if that's desired, let's have a separate issue and/or PR for this.