init.sh should account for configuration keys

[zbialik]

I tried to override the default routername configuration key using an env var and learned that it gets overridden by the init.sh stored in the ConfigMap.

Specifically was using values.yaml likeso:

solace:
  extraEnvVars:
   - name: routername
     value: "solace"

The specific override can be found in this line. However, I feel this is something that the chart overall should be accommodating. It seems like the use of configuration keys isn't 100% supported by this chart as the user will have to check whether or not the init.sh overrides those env configs.

For now, I will have to use kustomize to patch/override the init.sh in the ConfigMap, but I think most users (including myself) would want the ability to set extraEnvVars for configuration keys (it's also advertised in the values.yaml, too).

[bczoma]

Hi @zbialik , thanks for raising this. Can you provide more about the motivation/use case for setting the routername differently than the defaults offered? The issue is that even if env vars setting did overwrite init.sh settings, in an HA deployment each broker requires a unique routername so there cannot be a common setting through the config.

[zbialik]

@bczoma Sure thing.

For some background: I'm working on a project where the goal is to dynamically spin up test envs that consist of a solace VMR, solace cache, and several other services that subscribe to solace topics (most will publish messages to cache topics on startup). This test infra was previously orchestrated with docker-compose, but I'm working on improving the orchestration using k8s.

Right now, all of the underlying services that subscribe to solace are hardcoded with a specific routername. I can probably go ahead and update these services to use the default routername, unless configured otherwise, but it would be a little easier to just have the ability to setup the routername on startup of solace VMR.