[BUG] - Configure conda-store allowed channels via nebari config

Describe the bug

I’d like to configure the CondaStore.conda_allowed_channels via the nebari configuration file. This should be possible as described here:

conda_store:
  extra-settings:
     CondaStore:
       conda_allowed_channels = []

However, this does not validate according the nebari scheme, which requires “extra_settings”.

Trying this configuration instead:

conda_store:
  extra_settings:
     CondaStore:
       conda_allowed_channels = []

…does validate but may result in a broken conda-store service.

Expected behavior

In general any configuration parameter should be possible to pass through to conda-store via nebari-config.yaml.

OS and architecture in which you are running Nebari

GKE

How to Reproduce the problem?

Try the example configs given above and deploy.

Command output

No response

Versions and dependencies used.

Nebari version 2022.11.1.

Compute environment

GCP

Integrations

conda-store

Anything else?

Originally discussed here: https://github.com/nebari-dev/nebari/discussions/1567.

[viniciusdc]

Hi @alimanfoo. Thanks for reporting this. If I understood correctly, you got a problem with the extra-config not being a standard key for conda_store, right? Have you encountered any issues with using extra_config instead, if so, could you post them as @costrouc commented above?

Just give some context, the reason why extra-config failed is mostly probably dues to a typo here: https://github.com/nebari-dev/nebari/blob/49bca7153d14965f06340bf50f24e054fc0ca4d7/nebari/stages/input_vars.py#L288-L292 and here: https://github.com/nebari-dev/nebari/blob/49bca7153d14965f06340bf50f24e054fc0ca4d7/nebari/schema.py#L125-L126 It should be extra-setting and extra-config to comply with conda-store docs.

This also means that for Nebari (at least the current versions), the standard key will be extra_config/extra_settings. They should not break conda-store because they are correctly passed later to conda-store with the correct syntax here: https://github.com/nebari-dev/nebari/blob/49bca7153d14965f06340bf50f24e054fc0ca4d7/nebari/template/stages/07-kubernetes-services/conda-store.tf#L63-L64

I do agree that having those different structures to the same keys are confusing and unnecessary, so an action item would be to rename that to the correct syntax as per conda-store docs

[alimanfoo]

Hi folks, thanks so much for following this one up, much appreciated. Just wanted to say apologies I’m unlikely to have time to do more on this in the short term and I’m afraid logs from when I tried this before will be long gone having been through a number of cycles of destroying and redeploying clusters since.