âž¹ New Feature implementation request
At the moment, the different hooks have different ways of configuring similar data. For example, to provide credentials or other secrets:
notification: Configures an env in values.yaml (Values.env), pulls it into the env in the templatepersistence-defectdojo: Configures a link to a secret (Values.defectdojo.authentication.userSecret) and the keys inside the secret that should be used (Values.defectdojo.authentication.usernameKey and apiKeyKey)persistence-elastic: Configures a link to a secret (Values.authentication.userSecret or apiKeySecret) that uses fixed keys to find the actual user and password inside this secret.
In the same way, other configuration options are sometimes under a key that has the title of the hook inside it (defectdojo), sometimes in a key that has the title of the entity being configured (kibana vs. elasticsearch), and sometimes just plain first-level keys in the values.yaml (notification, parts of persistence-elastic, ...). I'm also sure that there are additional issues of consistency that I have not yet identified, these are just the ones that came up while working on #454.
Describe the solution you'd like
We should find a consistent way to define how the data should be given in the values.yaml so that it is less surprising for people doing the configurating. This includes:
- What is the structure for the configuration options? Are they under a specific key in the values?
- Do secrets have hard-coded subkeys that are being accessed, or are they specified in the values.yaml?
- ... (This is an incomplete list, just listing the most obvious problems I saw - we'd have to take another look at this together and figure out a good naming scheme / structure, and then implement and document it)
Changing this would be a breaking change, so it would require a major version release, but it may be a candidate for inclusion in SCB v4.
Describe alternatives you've considered
Leave everything as-is. It works, after all, and it is listed in the documentation, so people are able to work with hooks. However, it is not pretty to look at, and the inconsistencies will only get worse the more hooks we add.
âž¹ New Feature implementation request
At the moment, the different hooks have different ways of configuring similar data. For example, to provide credentials or other secrets:
notification: Configures anenvin values.yaml (Values.env), pulls it into the env in the templatepersistence-defectdojo: Configures a link to a secret (Values.defectdojo.authentication.userSecret) and the keys inside the secret that should be used (Values.defectdojo.authentication.usernameKeyandapiKeyKey)persistence-elastic: Configures a link to a secret (Values.authentication.userSecretorapiKeySecret) that uses fixed keys to find the actual user and password inside this secret.In the same way, other configuration options are sometimes under a key that has the title of the hook inside it (defectdojo), sometimes in a key that has the title of the entity being configured (kibana vs. elasticsearch), and sometimes just plain first-level keys in the values.yaml (notification, parts of persistence-elastic, ...). I'm also sure that there are additional issues of consistency that I have not yet identified, these are just the ones that came up while working on #454.
Describe the solution you'd like
We should find a consistent way to define how the data should be given in the values.yaml so that it is less surprising for people doing the configurating. This includes:
Changing this would be a breaking change, so it would require a major version release, but it may be a candidate for inclusion in SCB v4.
Describe alternatives you've considered
Leave everything as-is. It works, after all, and it is listed in the documentation, so people are able to work with hooks. However, it is not pretty to look at, and the inconsistencies will only get worse the more hooks we add.