Support pre-configured list values for flags

[richardcase]

Proposal

There are situations where the value for a flag is generally going to be 1 of a small number of possible values. For example, if you are using the Rancher provider you may only have 3 different api-endpoint that you use. Asking the user to enter the api-endpoint all the time isn't a great experience.

Its proposed that we introduce a mechanism by which we define a list of possible values in the config.yaml and have the user select from the list instead. The functionality should be generally applicable to any flag value.

Using api-endpoint as an example a couple of initial ideas:

Idea 1 - Explicit lists definition and mapping

In this we explicitly define lists of name/value pairs. Each list could be re-used for different flag values. For example:

apiVersion: kconnect.fidelity.github.com/v1alpha1
kind: Configuration
spec:
  global:
    username: [email protected]
  providers:
    eks:
      region: eu-west-2
      username: [email protected]
    rancher:
      api-endpoint: $rancherEndpoints
  lists:
    rancherEndpoints:
      - name: cluster1
        value: https://cluster1/v3
      - name: cluster2
        value: https://cluster3-abcd/v3

In this example we define a new list called rancherEndpoints that has 2 possible selections. We then use the special value $rancherEndpoints for the value of the api-endpoint config item for the rancher provider.

When the user runs kconnect and they don't supply a value for the --api-endpoint flag then the following will happen:

1. The resolver will see that the api-endpoint has a value of $rancherEndpoints defined.
2. The resolver will then look for a list defined in config.yaml for a list called rancherEndpoints
3. The resolver will read the name/value pairs and display the selection list to the user with the these values
4. The user will select an item and the api-endpoint will be set to the value of the selected item

Idea 1 - Inplace lists with implicit mapping

In this we define list in place as name/value pairs. The list is mapped implicitly to its corresponding flag via naming convention. For example:

apiVersion: kconnect.fidelity.github.com/v1alpha1
kind: Configuration
spec:
  global:
    username: [email protected]
  providers:
    eks:
      region: eu-west-2
      username: [email protected]
    rancher:
      list-api-endpoint:
        - name: cluster1
          value: https://cluster1/v3
        - name: cluster2
          value: https://cluster3-abcd/v3

In this example we define a config item called list-api-endpoint that has 2 name/value items. The name of this config item is special in that fact that any config item prefixed with list- will be used as a list of possible value for a config item whose name is with the prefix removed (i.e. api-endpoint in this example)

When the user runs kconnect and they don't supply a value for the --api-endpoint flag then the following will happen:

1. The resolver will see that there is a config item in config.yaml called list-api-endpoint. From the name it will know that this is a special list of values for a config called api-endpoint.
2. The resolver will read the name/value pairs in list-api-endpoint and display the selection list to the user with these values
3. The user will select an item and the api-endpoint will be set to the value of the selected item

Note: with this approach the user could also set the api-config config item as well and so precedence rules or errors would need to be added.

[richardcase]

I think i prefer 1 for the following reasons:

• Lists are explicit
• List can be reused between config items
• There will be no clash between an explicit value for a flag and having a list defined

However, if a list is referenced and the list doesn't exist then we would need to error.

[seankelly001]

I also prefer the first option, think it is cleaner

[richardcase]

We'll go with that then as i also think that's the best option, thanks @seankelly001