Make repositories to check for newer versions configurable, by chart / namespace, ...

[fibbs]

Is your feature request related to a problem? Please describe.
I am having the problem that some charts seem to have several sources with the same name, such as:

Release Name              Installed              Latest           Old     Deprecated
============              =========              ======           ===     ==========
kafka-ui                  0.7.6                  1.4.9            true    false

For kafka-ui I have version 0.7.6 installed, which is the current one on the official repository:

> helm repo ls | grep kafka-ui
kafka-ui                    	https://provectus.github.io/kafka-ui-charts

> helm repo update kafka-ui
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "kafka-ui" chart repository
Update Complete. ⎈Happy Helming!⎈

elm search repo kafka-ui
NAME             	CHART VERSION	APP VERSION	DESCRIPTION
kafka-ui/kafka-ui	0.7.6        	v0.7.2     	A Helm chart for kafka-UI

On artifacthub.io, though, there is a version 1.4.9 in a repo called "kafbat". I am not sure wether this might really be better in this specific case (didn't check yet), but if we suppose I want to stay on exactly this version, it would be nice to configure that THIS specific Chart should only be searched for in THAT repository, somehow.

Describe the solution you'd like
A configuration option to search for either specific names of Helm Charts or for specific namespaces in specific clusters only inside specific repositories. One lovely solution could also be to have a secret or configmap inside the cluster's namespace hinting Nova to search at the right place. The last of my suggestions would even solve a situation where you might have internal registries and Helm Repositories where all upstream charts go through some kind of validation process and are then "published" internally. You could with this check for upstream with one test cluster, and for internal by referencing so with a cluster-internal "ruleset".

Additional context
A "rule-based nova configuration inside the K8S cluster" would also make possible to set unwanted versions like -rc.* or -beta.* per namespace, per chart name or such, maybe with a Regex based ruleset.
But in any case, I would be happy with any other solution that allows me to "pin" helm charts to be found only in specific Helm Repositories.

[sudermanjr]

Have you looked through all of the possible configuration options, and the config file options on this page? https://nova.docs.fairwinds.com/usage/#options

I don't know that they will perfectly handle the scenarios you've listed here, but I do believe we could get much closer than just the default configuration that you seem to be using here.

If you have, please share more details about the configuration that you are using and how it could be improved.

[fibbs]

Yes, I did look into the possible configuration options, and I see that many use cases are actually configurable:

• whether to "just poll artifacthub": --poll-artifacthub to match for the name of the chart
• which URLs to fetch for instead --url

But these settings are "per nova call", meaning that if I had one setting for one namespace, in one cluster, and another in another cluster and/or another namespace, I would have to supply the correct setting everywhere.

What I do miss is a possibility to configure a kind of ruleset, maybe as follows:

nova_rules:
  - namespace: default
    releases:
      - ".*" # or empty
    poll_artifacthub: true
  - namespace: other
    releases:
      - "myapplication.*"
    poll_artifacthub: false
    urls:
      - https://my-chart-repo.org
      - oci://my-chart-repo.org/oci

With a configuration style like this it would be easy to add new configuration options like modifying the release version prior to comparing it, like cutting stuff away or whatever, but selectively (this could fix #354 and #99, for example).

nova_rules:
  - namespace: default
    version_ignore: '(pre|beta)' # ignores any version containing these substrings
    version_regex: '^(\d+\.\d+\.\d)' # removes everything behind three dot-separated numbers

And if we think this further, one could place this INSIDE the cluster where nova checks against, either "globally" or per namespace. That would enable GitOps tools like Flux to deploy a Configmap resource alongside the application configuring how nova should handle checking for eventually existing updates for the release. Label selectors could be used to mark the configmap inside the namespace, and nova could just read it and use it as a per-namespace configuration.

I am probably dreaming a bit too much here, but if someone asked me how I would like it to work, that's how.