fairwindsops / nova

Find outdated or deprecated Helm charts running in your cluster.

Find outdated or deprecated Helm charts running in your cluster.

Nova scans your cluster for installed Helm charts, then cross-checks them against all known Helm repositories. If it finds an updated version of the chart you're using, or notices your current version is deprecated, it will let you know.

Nova can also scan your cluster for out of date container images. Find out more in the docs.

Documentation

Check out the documentation at docs.fairwinds.com

Join the Fairwinds Open Source Community

The goal of the Fairwinds Community is to exchange ideas, influence the open source roadmap, and network with fellow Kubernetes users. Chat with us on Slack or join the user group to get involved!

Other Projects from Fairwinds

Enjoying Nova? Check out some of our other projects:

• Polaris - Audit, enforce, and build policies for Kubernetes resources, including over 20 built-in checks for best practices
• Goldilocks - Right-size your Kubernetes Deployments by compare your memory and CPU settings against actual usage
• Pluto - Detect Kubernetes resources that have been deprecated or removed in future versions
• rbac-manager - Simplify the management of RBAC in your Kubernetes clusters

Or check out the full list

Fairwinds Insights

If you're interested in running Nova in multiple clusters, tracking the results over time, integrating with Slack, Datadog, and Jira, or unlocking other functionality, check out Fairwinds Insights, a platform for auditing and enforcing policy in Kubernetes clusters.

nova's Issues

[Feature request]: Service with metrics support

Would be nice to have k8s service similar to https://github.com/jetstack/version-checker with metrics support.

Thanks

Error: concurrent map writes

What happened?

When trying to run nova find on my eks cluster it fails with the following error:

fatal error: concurrent map writes

goroutine 154 [running]:
runtime.throw({0x2444bc8, 0x10})
        /usr/local/go/src/runtime/panic.go:1198 +0x71 fp=0xc0044d7e60 sp=0xc0044d7e30 pc=0x1033211
runtime.mapassign_faststr(0x6563727500000003, 0xc00a9e9710, {0xc00a9e9710, 0xf})
        /usr/local/go/src/runtime/map_faststr.go:211 +0x39c fp=0xc0044d7ec8 sp=0xc0044d7e60 pc=0x1012a7c
github.com/fairwindsops/nova/pkg/helm.(*ArtifactHubPackageClient).MultiSearch.func1(0x747365742f737473, {0xc00a9e9710, 0xf}, 0xc000340060, 0xc007a0de88)
        /go/src/github.com/fairwindsops/nova/pkg/helm/artifacthub.go:264 +0x196 fp=0xc0044d7fa8 sp=0xc0044d7ec8 pc=0x20464f6
github.com/fairwindsops/nova/pkg/helm.(*ArtifactHubPackageClient).MultiSearch·dwrap·3()
        /go/src/github.com/fairwindsops/nova/pkg/helm/artifacthub.go:273 +0x3e fp=0xc0044d7fe0 sp=0xc0044d7fa8 pc=0x204631e
runtime.goexit()
        /usr/local/go/src/runtime/asm_amd64.s:1581 +0x1 fp=0xc0044d7fe8 sp=0xc0044d7fe0 pc=0x1063041
created by github.com/fairwindsops/nova/pkg/helm.(*ArtifactHubPackageClient).MultiSearch
        /go/src/github.com/fairwindsops/nova/pkg/helm/artifacthub.go:259 +0x605

EKS Version: 1.21

What did you expect to happen?

Standard output of Nova find

How can we reproduce this?

Re run Nova version commands.

Version

3.0.2

Search

• I did search for other open and closed issues before opening this.

Code of Conduct

• I agree to follow this project's Code of Conduct

Additional context

No response

splunk-connect-for-kubernetes subcharts versions are not identified properly

What happened?

Nova tool was unable to identify the upstream versions of splunk-connect-for-kubernetes:

$ nova find -a -u https://splunk.github.io/splunk-connect-for-kubernetes/
Release Name                         Installed      Latest          Old      Deprecated
============                         =========      ======          ===      ==========
...
splunk-kubernetes-logging            1.4.14                         false    false    
splunk-kubernetes-objects            1.4.14                         false    false    

No matter which URL I specify, the latest version is no identified.

Original charts are coming from this repo: https://github.com/splunk/splunk-connect-for-kubernetes. Helm repo listing looks as follows:

$ helm repo list
NAME            URL                                                                         
...
splunk          https://splunk.github.io/splunk-connect-for-kubernetes/ 

What did you expect to happen?

Nova would identify the latest versions of the charts.

How can we reproduce this?

Install corresponding splunk charts and try executing nova find -a -u https://splunk.github.io/splunk-connect-for-kubernetes/ command against the cluster that has them installed.

Version

Version:3.0.2 Commit:f8f0448ca2362fff6797578a595308dd956ce462

Search

• I did search for other open and closed issues before opening this.

Code of Conduct

• I agree to follow this project's Code of Conduct

Additional context

No response

Use Artifact Hub for repository listing to replace Helm Hub

Is your feature request related to a problem? Please describe.
There's a lot of helm repos out there now that stable/incubator are disabled. Some of them are very common to use.

Describe the solution you'd like
Add a bunch of repos to the default list, some examples from my current list.

https://charts.helm.sh/stable
https://charts.helm.sh/incubator
https://charts.fairwinds.com/stable
https://charts.jetstack.io
https://charts.rimusz.net
https://helm.linkerd.io/stable
https://helm.linkerd.io/edge
https://charts.fairwinds.com/incubator
https://grafana.github.io/loki/charts
https://argoproj.github.io/argo-helm
https://kubecost.github.io/cost-analyzer/
https://charts.sudermanjr.com
https://agones.dev/chart/stable
https://helm.influxdata.com/
https://jupyterhub.github.io/helm-chart/
https://charts.deliveryhero.io/
https://kubernetes.github.io/autoscaler
https://prometheus-community.github.io/helm-charts
https://open-match.dev/chart/stable
https://charts.gitlab.io
https://aws.github.io/eks-charts
https://helm.datadoghq.com
https://helm.linkerd.io/stable
https://runatlantis.github.io/helm-charts
https://kubernetes.github.io/ingress-nginx
https://falcosecurity.github.io/charts
https://dl.gitea.io/charts/
https://charts.drone.io
https://jtblin.github.io/kube2iam
https://spotinst.github.io/spotinst-kubernetes-helm-charts
https://kubernetes-sigs.github.io/aws-ebs-csi-driver
https://releases.rancher.com/server-charts/latest
https://kubernetes.github.io/dashboard
https://aws.github.io/eks-charts
https://awslabs.github.io/k8s-cloudwatch-adapter/charts/k8s-cloudwatch-adapter
https://kubernetes-sigs.github.io/aws-efs-csi-driver
https://helm.releases.hashicorp.com
https://infracloudio.github.io/charts
https://helm.twun.io
https://oauth2-proxy.github.io/manifests
https://charts.bitnami.com/bitnami

Describe alternatives you've considered
another alternative might be to add the current list you have locally to the default list? Not sure if that's good or bad

Filter output to old = true

Hi,

Really like the tool, but we have a lot of helm deployments per cluster. is it possible to filter results to only those with old = true or deprecated = true?

Ability to scan helm charts located in local file system

Is your feature request related to a problem? Please describe.
We are deploying helm charts via ArgoCD and this approach doesn't create release information that nova can look for.

Describe the solution you'd like
We are keeping helm charts in git repository. It would be great if nova can have additional option to scan local folders with helm charts. It could also scan all subfolders recursively.

Describe alternatives you've considered
Nothing at this point.

Additional context
This is a folder structure as an example:
\helm-chars\dev\chart01
\helm-chars\dev\chart02
\helm-chars\prod\chart01
\helm-chars\prod\chart01
etc.

Enable scanning yaml that has been templated from a helm chart

Is your feature request related to a problem? Please describe.
If I generate my yaml and then apply it, there's no helm release object, rendering nova useless to me.

Describe the solution you'd like
If I want to maintain a repository of Yaml manifests that have been generated by a helm template command, the generated yaml will still generally have the helm annotations that say what chart it came from. Nova could detect that and do its magic after that. This could work on all in-cluster objects too, depending on what you wanted to give nova access to

Describe alternatives you've considered
This could be somewhat mitigated by #18 as well.

Additional context
Related to #45, which is working with a similar problem statement in that ArgoCD is in use. (I'm using argocd with the generated yaml manifests)

2.0 installs as Nova instead of nova

Installation Process

Tried both with downloading a release, and with brew

Nova Version

2.0.1

Expected Behavior

Should run as nova

Actual Behavior

runs as Nova

Steps to Reproduce

Additional Context

References

The results are not finding the upstream releases for certain helm repos

What happened?

Ran the nova find cmd on my cluster.

What did you expect to happen?

Return the helm chart versions I have installed and also the latest versions from each helm-chart repo. I got most new releases back but there were some which did not work.

How can we reproduce this?

Install the below helm charts on a k8s cluster and run nova find

• sorry-cypress v1.2.0 (https://github.com/sorry-cypress/charts)
• chaos-mesh v2.0.1 (https://github.com/chaos-mesh/charts)

You should see that the Latest column is empty for both.

Version

0.0.1

Search

• I did search for other open and closed issues before opening this.

Code of Conduct

• I agree to follow this project's Code of Conduct

Additional context

FYI - Chaos mesh has no releases published in its Charts repo so wondering if this could be a problem. However sorry-cypress does have releases published.

Kustomize Helm support - detect outdated helmCharts in kustomization.yaml

Problem Statement

When installing Helm charts via Kustomize, because Kustomize renders the helm template to apply instead of running a helm install, Nova does not address the use case of outdated Helm charts in Kustomize configurations.

Use Case Example

My public kubernetes repo with lots of *-kustomization.yaml files with Helm charts embedded in them:

https://github.com/HariSekhon/Kubernetes-configs

Proposed Solution

Nova could scan kustomization.y*ml files for the helmCharts section and extract the chart repo/name to check for outdated versions.

This shouldn't be difficult to do, and is much cleaner than the alternatives.

Alternatives considered

1. Parsing the kustomization.yaml myself, installing the Helm charts the old fashioned non-GitOps way using the helm command against a CI/CD K8s cluster and then running Nova against the CI/CD cluster. Obviously this is far from ideal, compared to Nova just comparing the versions in the yaml to the upstream repo.

2. Installing all the Kustomizations to a CI/CD cluster and then hoping #62 is implemented to be able to scan from annotations, but that is not yet implemented either.

My proposed solution for Kustomize is simpler, faster and more lightweight than either option above.

Additional context

Relates to #62 and #45

Ability to specify a namespace

Is your feature request related to a problem? Please describe.
Nova does two things according to the README:
Nova scans your cluster for installed Helm charts, then cross-checks them against all known Helm repositories

I'd like to be able to use Nova by namespace.

Describe the solution you'd like
Add an option as -n

Support install via asdf

Is your feature request related to a problem? Please describe.
Currently, I can install Nova a few different ways (e.g. go or homebrew). It would be nice to also support installation via an asdf plugin.

Describe the solution you'd like
Create an asdf plugin for Nova. See their docs for more info.

Describe alternatives you've considered
Installing via homebrew or go. However, homebrew installation is system wide and doesn't fit into our version management workflows.

Additional context
Other FairwindsOps tools also support installation via asdf (e.g. Pluto). For background, we rely heavily on asdf's .tool-version files to manage our binary tool versions in local code. For us, having nova work into the same workflow would make it easier for us to work with and more likely to adopt.

no Auth Provider found for name "oidc"

Installation Process

Github release on local-machine

Nova Version

nova version 0.0.1

Expected Behavior

Normal output

Actual Behavior

Nova find --helm-version=auto
E0807 09:44:51.330033   27135 kube.go:56] Error creating kubernetes client: no Auth Provider found for name "oidc"

Steps to Reproduce

enable the oidc provider on the kube-apiserver and try to run nova

`nova --containers` recommends wrong image

What happened?

ran nova --containers and it found docker.io/bitnami/jenkins:2.249.3-debian-10-r6. It recommended tag 2.332.3 instead of 2.332.3-debian-11-r6.

Tricky situation but I think we should be able to parse it.

What did you expect to happen?

Recommend a debian tag

How can we reproduce this?

Install docker.io/bitnami/jenkins:2.249.3-debian-10-r6 and run nova --containers

Version

3.2.0

Search

• I did search for other open and closed issues before opening this.

Code of Conduct

• I agree to follow this project's Code of Conduct

Additional context

No response

Shouldn't nova be a helm plugin

Is your feature request related to a problem? Please describe.

Not really a problem, but it is confusing me that i would have to use a separate tool for a functionality which is strongly related to the helm release lifecycle (and very helpful).

Describe the solution you'd like

I'd like nova to be installable as a helm plugin and use it as a subcommand like helm whatsnew [...] including proper tab completion like other helm plugins provide.

Describe alternatives you've considered

Using nova standalone.

Additional context

• https://github.com/search?q=topic%3Ahelm-plugin&type=Repositories
• https://helm.sh/docs/topics/plugins/

Support passing chart version overrides file or parameter

Is your feature request related to a problem? Please describe.

I have a curated set of "standards" that is effectively a list of charts and version that I want to be on. Currently, this doesn't work with Nova because it assumes I want to be on the latest version of any chart that is installed.

Describe the solution you'd like

I think a possible solution is to be able to pass "overrides" either as a flag(s), or as a config file. Basically, say `ingress-nginx=

Describe alternatives you've considered
Use a different tool, like OPA

Context Deadline

Is your feature request related to a problem? Please describe.
We are getting context deadline exceeded for most of our images. This is because our registry is kinda slow:

company.registry.com/minio/console:v0.15.6                                                                                                                            Get "https://company.registry.com/v2/minio/console/tags/list?n=1000": context deadline exceeded                                                    
company.registry.com/tekton-releases/github.com/tektoncd/pipeline/cmd/webhook:v0.33.3@sha256:957d3c2da071258e2b54bd4002b4a92d8f6efdcd9045af7fcc2e68e4314aa3c3         Get "https://company.registry.com/v2/tekton-releases/github.com/tektoncd/pipeline/cmd/webhook/tags/list?n=1000": context deadline exceeded         
company.registry.com/coredns/coredns:1.9.2                                                                                                                            Get "https://company.registry.com/v2/coredns/coredns/tags/list?n=1000": context deadline exceeded                                                  
company.registry.com/fluxcd/source-controller:v0.24.4                                                                                                                 Get "https://company.registry.com/v2/fluxcd/source-controller/tags/list?n=1000": context deadline exceeded                                         
company.registry.com/jetstack/cert-manager-controller:v1.8.0                                                                                                          Get "https://company.registry.com/v2/jetstack/cert-manager-controller/tags/list?n=1000": context deadline exceeded                                 
company.registry.com/jettech/kube-webhook-certgen:v1.3.0                                                                                                              Get "https://company.registry.com/v2/jettech/kube-webhook-certgen/tags/list?n=1000": context deadline exceeded                                     
company.registry.com/kyverno/kyverno:v1.7.1                                                                                                                           Get "https://company.registry.com/v2/kyverno/kyverno/tags/list?n=1000": context deadline exceeded 

Therefor the container scan only works for images which are not on our registry:

Container Name                                            Current Version    Old     Latest     Latest Minor     Latest Patch
==============                                            ===============    ===     ======     =============    =============
quay.io/prometheus-operator/prometheus-config-reloader    v0.55.0            true    v0.58.0    v0.55.0          v0.55.1    
ghcr.io/weaveworks/tf-controller                          v0.10.0-rc.6       true    v0.11.0    v0.10.0-rc.6     v0.10.1    
ghcr.io/kyverno/policy-reporter                           1.9.0              true    2.8.0      1.10.3           1.9.0   

Describe the solution you'd like
Increase the context deadline

Describe alternatives you've considered
We will clean up our registry in the future to improve it's performance

The "poll-helm-hub" and "url" features in the config file no longer work

What happened?

Hello, After the Nova 3.0.0 update, the "url:" and "poll-helm-hub:" features are no longer present.
As a result, I find myself with versions of charts in nightly-build and not in release version or tags that no longer corresponds to the original convention : example for "kubed".

Also, Artifacthub does not have the set of available helms : example for "csi-secrets-store".

Example output (2.3.0) :

Release Name                    Installed    Latest      Old      Deprecated

vector-aggregator               0.18.1         0.21.2      true     false
csi-secrets-store                 0.1.0          1.0.1         true     false
kubed                                    v0.12.0      v0.13.1     true     false

And

Example output (3.0.0) :

Release Name                    Installed           Latest                                        Old      Deprecated
============                 =========    ======                                     ===      ==========

kubed                                    v0.12.0           0.13.1                                         true     false
vector-aggregator               0.18.1              0.20.0-nightly-2022-01-04    true     false

In 3.0.0 output, we don't have the csi-secrets-store, the vector-aggregator have a nightly build verison and kubed change the tag convention

What did you expect to happen?

After run the command `nova find --config=config.ymlà, I expect to have a result that corresponds to a check between the urls charts of my config file and the currently installed charts in my cluster K8S.

How can we reproduce this?

Use the config file :

#config.yml

poll-helm-hub: false

url:
  - https://charts.appscode.com/stable
  - https://helm.vector.dev
  - https://raw.githubusercontent.com/Azure/secrets-store-csi-driver-provider-azure/master/charts

And run this command on nova 3.0.0 :

nova find --config=config.yml

Result :

Release Name                    Installed    Latest                       Old      Deprecated
============                    =========    ======                       ===      ==========
kubed                           v0.12.0      0.13.1                       true     false
vector-aggregator               0.18.1       0.20.0-nightly-2022-01-04    true     false

And with the 2.3.0 version :

Release Name                    Installed    Latest     Old      Deprecated
kubed                                 v0.12.0      v0.13.1    true      false
csi-secrets-store               0.1.0         1.0.1        true      false
vector-aggregator             0.18.1       0.21.2      true      false

version

3.0.0

Search

• I did search for other open and closed issues before opening this.

Code of Conduct

• I agree to follow this project's Code of Conduct

Additional context

No response

Nova does not work with github.io and googleapis.com Helm repositories

Installation Process

Local machine, macOS Big Sur 11.2.3

Nova Version

Version:2.3.1 Commit:7ea59ea5d19baaa700fdec9438d586ba4039a7d9

Expected Behavior

Nova compares installed versions with latest ones.

Actual Behavior

It does not work for github.io and googleapis.com hosted repos.

Steps to Reproduce

Deploy some charts to your K8s cluster from any github.io Helm repository with Flux and Kustomize.

Additional Context

I0422 12:45:48.788949    2546 chartrepo.go:83] Could not load chart repo https://godaddy.github.io/kubernetes-external-secrets: yaml: line 9: mapping values are not allowed in this context
I0422 12:45:49.025367    2546 chartrepo.go:83] Could not load chart repo https://bloomberg.github.io/solr-operator/charts: yaml: line 9: mapping values are not allowed in this context
I0422 12:45:49.490985    2546 chartrepo.go:83] Could not load chart repo https://redskyops.dev/charts: yaml: line 562: mapping values are not allowed in this context
I0422 12:45:49.675294    2546 chartrepo.go:83] Could not load chart repo https://funkypenguin.github.io/helm-charts: yaml: line 9: mapping values are not allowed in this context
I0422 12:45:49.740848    2546 chartrepo.go:83] Could not load chart repo https://fasterbytes.github.io/charts: yaml: line 9: mapping values are not allowed in this context
I0422 12:45:52.251689    2546 chartrepo.go:83] Could not load chart repo https://logicmonitor.github.com/k8s-helm-charts: yaml: line 9: mapping values are not allowed in this context

I0422 12:45:47.970431    2546 chartrepo.go:83] Could not load chart repo https://kubernetes-charts-incubator.storage.googleapis.com: yaml: unmarshal errors:
  line 1: cannot unmarshal !!str `<?xml v...` into helm.ChartReleases
I0422 12:45:47.977293    2546 chartrepo.go:83] Could not load chart repo https://kubernetes-charts-incubator.storage.googleapis.com: yaml: unmarshal errors:
  line 1: cannot unmarshal !!str `<?xml v...` into helm.ChartReleases
I0422 12:45:47.992443    2546 chartrepo.go:83] Could not load chart repo https://kubernetes-charts.storage.googleapis.com: yaml: unmarshal errors:
  line 1: cannot unmarshal !!str `<?xml v...` into helm.ChartReleases
I0422 12:45:48.185981    2546 chartrepo.go:83] Could not load chart repo https://kubernetes-charts.storage.googleapis.com: yaml: unmarshal errors:
  line 1: cannot unmarshal !!str `<?xml v...` into helm.ChartReleases

References

Additional Cache Enhancements

Is your feature request related to a problem? Please describe.
When running locally in quick succession it is likely you will hit rate limits on the artifacthub API, especially if you have a lot of helm releases.

Describe the solution you'd like
A local cache file that is on by default. We'll want the file to include the datetime of when it was last pulled. There can be a configurable expiry duration that will bypass the cache. It should hold all the search data that was gathered from artifacthub. If nova is run in quick succession after a helm chart is added to the cluster, there needs to be a fallback to call artifacthub only for new things that are not in the cache.

Describe alternatives you've considered
Nothing right now.

Additional context
N/A

Nova unable to flag deprecated Helm charts

What happened?

While working on a blog post about Nova, I wasn't able to get the tool to flag 2 deprecated charts.

I installed nginx-ingress and kube2iam from the deprecated helm chart repo, but nova is still reporting that these are not deprecated:

Release Name      Installed    Latest    Old      Deprecated
============      =========    ======    ===      ==========
kube2iam          2.5.3        2.6.0     true     false
metrics-server    3.8.0        3.8.2     true     false
nginx-ingress     1.41.0       1.41.2    true     false
vpa               1.4.0        1.4.0     false    false

I'm running Nova v3.2.0.

What did you expect to happen?

I expect Nova identify charts with deprecated: true in their Chart.yaml as deprecated.

How can we reproduce this?

kubewatch is a deprecated chart.

Install it with the command:

helm repo add bitnami https://charts.bitnami.com/bitnami
helm install my-release bitnami/kubewatch

Then, run nova find and you will see

Release Name             Installed    Latest    Old      Deprecated
============             =========    ======    ===      ==========
kubewatch                3.3.4        3.3.4    false    false

Per @sudermanjr, the artifacthub functionality broke the Deprecated function.

If you disable artifact hub, and specify the repository directly, it gets the field to flip:

nova find --poll-artifacthub=false --url=https://charts.bitnami.com/bitnami

Release Name    Installed    Latest    Old      Deprecated
============    =========    ======    ===      ==========
kubewatch       3.3.4        3.3.4     false    true

Version

3.2.0

Search

• I did search for other open and closed issues before opening this.

Code of Conduct

• I agree to follow this project's Code of Conduct

Additional context

No response

nova find --containers output to file

Is your feature request related to a problem? Please describe.
nova find can output to a file. This does not work with --containers

Describe the solution you'd like
I would like an output file option the same as nova find

Find containers - timeout

What happened?

When I launch nova find --containers --show-errored-containers --format table on my Kubernetes clusters, I get the following error : Get "https://index.docker.io/v2/": context deadline exceeded

What did you expect to happen?

No timeout

How can we reproduce this?

Launch nova find --containers --show-errored-containers --format table on a cluster with a lot of pods

Version

Version:3.4.0 Commit:e73dbcef4e82ebb2a17137e9e22dee8ab073f40a

Search

• I did search for other open and closed issues before opening this.

Code of Conduct

• I agree to follow this project's Code of Conduct

Additional context

In the following function

func handleContainers(kubeContext string) (*output.ContainersOutput, error) {
	// Set up a context we can use to cancel all operations to external container registries if we need to
	ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)

The timeout seems to be the problem here. If we change it for 100 seconds for example, everything is working

Flag to only show old Charts

Is your feature request related to a problem? Please describe.
We have a lot of charts in our cluster and it would be nice to be able to find only the ones that are on an old version, so hiding all the ones that are Old false.

Describe the solution you'd like
A flag when you run nova find to only show old charts

Describe alternatives you've considered
I can get it working with awk commands but would be nice to have it built in

`--include-all` seems to be used inconsistently

What happened?

The --include-all flag says it will "Show all charts even if no latest version is found."

However, when using --containers, it seems to work more like --show-old=false. By default --containers only outputs old containers, but adding --include-all causes it to show up-to-date containers.

What did you expect to happen?

• Updated documentation for flags that reference Helm charts but can be used in --containers context
• Consistent use of flags in both contexts
• Consistent default behavior in both contexts (i.e. show all by default, but a flag filters out up-to-date things)

How can we reproduce this?

Install a mix of current and old containers

Version

3.2.0

Search

• I did search for other open and closed issues before opening this.

Code of Conduct

• I agree to follow this project's Code of Conduct

Additional context

No response

Release name pattern change causes dynamic downloads to fail

What happened?

The latest release name was changed from major.minor.patch ({0-9}.{0-9}.{0-9}) to v major.minor.patch (v {0-9}.{0-9}.{0-9}). This pattern change breaks automatic generated download url and therefore is failing the download of the release files.

Download url with 3.6.1:
https://github.com/FairwindsOps/nova/releases/download/3.6.1/nova_3.6.1_linux_amd64.tar.gz

Download url with v3.6.2:
https://github.com/FairwindsOps/nova/releases/download/v3.6.2/nova_3.6.2_linux_amd64.tar.gz

What did you expect to happen?

In the past the release name pattern was major.minor.patch . Therefore, I assume that this happened by mistake. I would expect that if the release name is changed then this would be communicated in the release note. One of the following options can be implemented to fix this issue:

• rename latest release to major.minor.patch (remove v)
• rename release files by adding the v to all file names to have a consistent release name pattern (for example: nova_v3.6.2_linux_amd64.tar.gz)
• use new release name from now on for future release names and communicate in release notes that this pattern will be used from now on

I'm created this bug in case someone else also discovered this issue. It's not a big deal and can be easily changed by the consumer. However, it would be great to know if this is a permanent change so that it will not break again if the next release is named without v.

How can we reproduce this?

I'm using dynamic generated download url to nightly build an ubuntu docker image with nova. Enclosed you find the code to reproduce the dynamic url:

NOVA_VERSION=$(curl -L https://api.github.com/repos/FairwindsOps/nova/releases/latest | jq .name -r)
echo ${NOVA_VERSION}
echo "download url: https://github.com/FairwindsOps/nova/releases/download/${NOVA_VERSION}/nova_${NOVA_VERSION}_$(uname -s)_amd64.tar.gz"

(click on download url will result in not found error message)

Version

v3.6.2

Search

• I did search for other open and closed issues before opening this.

Code of Conduct

• I agree to follow this project's Code of Conduct

Additional context

No response

Kustomize Helm update tracking

Would it be possible for Nova to scan Kustomize's kustomization.yaml helmCharts versions and notify if the chart version in there is outdata?

An example of such a kustomization.yaml implementing the Polaris helm chart is here:

https://github.com/HariSekhon/Kubernetes-configs/blob/master/polaris/base/kustomization.yaml

Detect chart dependency updates

Is your feature request related to a problem? Please describe.
I want to know if helm chart dependencies have updates.

As an example, the helm chart bitnami/keycloak also deploys bitnami/postgresql as a dependency. The version tag version: 10.x.x allows postgresql to get updates.
https://github.com/bitnami/charts/blob/master/bitnami/keycloak/Chart.yaml

Describe the solution you'd like
A new output column that indicates whether dependency updates are available.

Describe alternatives you've considered
Maybe list the dependencies as a separate row.

Doesn't work with public helm charts due to request throttling from artifacthub

What happened?

nova find only works the first time you run it.

After that, artifacthub immediately throttles you with 429s due to the huge volume of requests nova makes to do its work.

Example:

> nova find -v 5
I1016 13:18:22.086983    7541 root.go:129] config not set, using flags only
I1016 13:18:22.087045    7541 root.go:213] Settings: map[containers:false context: desired-versions:map[] include-all:false output-file: poll-artifacthub:true show-errored-containers:false show-non-semver:false show-old:false url:[] wide:false]
I1016 13:18:22.087068    7541 root.go:214] All Keys: [containers context poll-artifacthub show-non-semver desired-versions url output-file include-all show-errored-containers show-old wide]
I1016 13:18:24.176990    7541 artifacthub.go:411] attempt 1 failed to GET https://artifacthub.io/api/v1/packages/search with status code: 429
I1016 13:18:24.177149    7541 artifacthub.go:411] attempt 1 failed to GET https://artifacthub.io/api/v1/packages/search with status code: 429
I1016 13:18:24.177155    7541 artifacthub.go:411] attempt 1 failed to GET https://artifacthub.io/api/v1/packages/search with status code: 429
I1016 13:18:24.177173    7541 artifacthub.go:411] attempt 1 failed to GET https://artifacthub.io/api/v1/packages/search with status code: 429
I1016 13:18:24.178163    7541 artifacthub.go:411] attempt 1 failed to GET https://artifacthub.io/api/v1/packages/search with status code: 429
I1016 13:18:24.178444    7541 artifacthub.go:411] attempt 1 failed to GET https://artifacthub.io/api/v1/packages/search with status code: 429
I1016 13:18:24.178939    7541 artifacthub.go:411] attempt 1 failed to GET https://artifacthub.io/api/v1/packages/search with status code: 429
I1016 13:18:24.179150    7541 artifacthub.go:411] attempt 1 failed to GET https://artifacthub.io/api/v1/packages/search with status code: 429
I1016 13:18:24.179381    7541 artifacthub.go:411] attempt 1 failed to GET https://artifacthub.io/api/v1/packages/search with status code: 429
I1016 13:18:24.179611    7541 artifacthub.go:411] attempt 1 failed to GET https://artifacthub.io/api/v1/packages/search with status code: 429
I1016 13:18:24.179845    7541 artifacthub.go:411] attempt 1 failed to GET https://artifacthub.io/api/v1/packages/search with status code: 429
I1016 13:18:24.180125    7541 artifacthub.go:411] attempt 1 failed to GET https://artifacthub.io/api/v1/packages/search with status code: 429
I1016 13:18:24.180319    7541 artifacthub.go:411] attempt 1 failed to GET https://artifacthub.io/api/v1/packages/search with status code: 429
I1016 13:18:24.182105    7541 artifacthub.go:411] attempt 2 failed to GET https://artifacthub.io/api/v1/packages/search with status code: 429
I1016 13:18:24.182273    7541 artifacthub.go:411] attempt 2 failed to GET https://artifacthub.io/api/v1/packages/search with status code: 429
I1016 13:18:24.182456    7541 artifacthub.go:411] attempt 2 failed to GET https://artifacthub.io/api/v1/packages/search with status code: 429
I1016 13:18:24.183659    7541 artifacthub.go:411] attempt 2 failed to GET https://artifacthub.io/api/v1/packages/search with status code: 429
I1016 13:18:24.183861    7541 artifacthub.go:411] attempt 2 failed to GET https://artifacthub.io/api/v1/packages/search with status code: 429
I1016 13:18:24.184187    7541 artifacthub.go:411] attempt 2 failed to GET https://artifacthub.io/api/v1/packages/search with status code: 429
I1016 13:18:24.184428    7541 artifacthub.go:411] attempt 2 failed to GET https://artifacthub.io/api/v1/packages/search with status code: 429
I1016 13:18:24.184689    7541 artifacthub.go:411] attempt 2 failed to GET https://artifacthub.io/api/v1/packages/search with status code: 429
I1016 13:18:24.184965    7541 artifacthub.go:411] attempt 2 failed to GET https://artifacthub.io/api/v1/packages/search with status code: 429
I1016 13:18:24.185527    7541 artifacthub.go:411] attempt 2 failed to GET https://artifacthub.io/api/v1/packages/search with status code: 429
I1016 13:18:24.185843    7541 artifacthub.go:411] attempt 2 failed to GET https://artifacthub.io/api/v1/packages/search with status code: 429
I1016 13:18:24.186055    7541 artifacthub.go:411] attempt 2 failed to GET https://artifacthub.io/api/v1/packages/search with status code: 429
I1016 13:18:24.198882    7541 artifacthub.go:302] error GETing response for with search term 'ingress-nginx': error code: 429
I1016 13:18:24.198891    7541 artifacthub.go:265] error searching for term error code: 429
I1016 13:18:24.199245    7541 artifacthub.go:411] attempt 5 failed to GET https://artifacthub.io/api/v1/packages/search with status code: 429
I1016 13:18:24.199255    7541 artifacthub.go:302] error GETing response for with search term 'metrics-server': error code: 429
I1016 13:18:24.199261    7541 artifacthub.go:265] error searching for term error code: 429
I1016 13:18:24.200512    7541 artifacthub.go:411] attempt 4 failed to GET https://artifacthub.io/api/v1/packages/search with status code: 429
I1016 13:18:24.200716    7541 artifacthub.go:411] attempt 5 failed to GET https://artifacthub.io/api/v1/packages/search with status code: 429
I1016 13:18:24.200725    7541 artifacthub.go:302] error GETing response for with search term 'redis': error code: 429
I1016 13:18:24.200732    7541 artifacthub.go:265] error searching for term error code: 429
I1016 13:18:24.200888    7541 artifacthub.go:411] attempt 5 failed to GET https://artifacthub.io/api/v1/packages/search with status code: 429
I1016 13:18:24.200898    7541 artifacthub.go:302] error GETing response for with search term 'mongodb': error code: 429
I1016 13:18:24.200904    7541 artifacthub.go:265] error searching for term error code: 429
I1016 13:18:24.201459    7541 artifacthub.go:411] attempt 5 failed to GET https://artifacthub.io/api/v1/packages/search with status code: 429
I1016 13:18:24.201477    7541 artifacthub.go:302] error GETing response for with search term 'elasticsearch': error code: 429
I1016 13:18:24.201490    7541 artifacthub.go:265] error searching for term error code: 429
I1016 13:18:24.201647    7541 artifacthub.go:411] attempt 5 failed to GET https://artifacthub.io/api/v1/packages/search with status code: 429
I1016 13:18:24.201659    7541 artifacthub.go:302] error GETing response for with search term 'postgresql': error code: 429
I1016 13:18:24.201668    7541 artifacthub.go:265] error searching for term error code: 429
I1016 13:18:24.201853    7541 artifacthub.go:411] attempt 5 failed to GET https://artifacthub.io/api/v1/packages/search with status code: 429
I1016 13:18:24.201861    7541 artifacthub.go:302] error GETing response for with search term 'kibana': error code: 429
I1016 13:18:24.201869    7541 artifacthub.go:265] error searching for term error code: 429
I1016 13:18:24.202696    7541 artifacthub.go:411] attempt 5 failed to GET https://artifacthub.io/api/v1/packages/search with status code: 429
I1016 13:18:24.202715    7541 artifacthub.go:302] error GETing response for with search term 'fluent-bit': error code: 429
I1016 13:18:24.202726    7541 artifacthub.go:265] error searching for term error code: 429
I1016 13:18:24.202870    7541 artifacthub.go:411] attempt 5 failed to GET https://artifacthub.io/api/v1/packages/search with status code: 429
I1016 13:18:24.202881    7541 artifacthub.go:302] error GETing response for with search term 'graylog': error code: 429
I1016 13:18:24.202889    7541 artifacthub.go:265] error searching for term error code: 429
I1016 13:18:24.203079    7541 artifacthub.go:411] attempt 5 failed to GET https://artifacthub.io/api/v1/packages/search with status code: 429
I1016 13:18:24.203087    7541 artifacthub.go:302] error GETing response for with search term 'helm-operator': error code: 429
I1016 13:18:24.203093    7541 artifacthub.go:265] error searching for term error code: 429
I1016 13:18:24.203502    7541 artifacthub.go:411] attempt 5 failed to GET https://artifacthub.io/api/v1/packages/search with status code: 429
I1016 13:18:24.203518    7541 artifacthub.go:302] error GETing response for with search term 'cert-manager': error code: 429
I1016 13:18:24.203527    7541 artifacthub.go:265] error searching for term error code: 429
I1016 13:18:24.203780    7541 artifacthub.go:411] attempt 5 failed to GET https://artifacthub.io/api/v1/packages/search with status code: 429
I1016 13:18:24.203790    7541 artifacthub.go:302] error GETing response for with search term 'sealed-secrets': error code: 429
I1016 13:18:24.203796    7541 artifacthub.go:265] error searching for term error code: 429
I1016 13:18:24.204637    7541 artifacthub.go:411] attempt 5 failed to GET https://artifacthub.io/api/v1/packages/search with status code: 429
I1016 13:18:24.204654    7541 artifacthub.go:302] error GETing response for with search term 'flux': error code: 429
I1016 13:18:24.204664    7541 artifacthub.go:265] error searching for term error code: 429

What did you expect to happen?

Nova should work properly when ran 2 or more times.

How can we reproduce this?

Install nova and run it a couple of times.

Version

Version:3.2.0 Commit:2d64fbc53116ebf8c65e8abf1e9c53039d44a32f

Search

• I did search for other open and closed issues before opening this.

Code of Conduct

• I agree to follow this project's Code of Conduct

Additional context

No response

Set version from build args rather than static

This would prevent the version from being forgotten during updates.

Image version checking

nova version shows wrong version

Installation Process

I downloaded verson 1.0.0 from https://github.com/FairwindsOps/Nova/releases/download/1.0.0/Nova_1.0.0_linux_amd64.tar.gz and installed Nova executable to ~/bin/nova

Nova Version

nova version 0.0.1

Expected Behavior

It should show correct version 1.0.0

Actual Behavior

It shows wrong version 0.0.1

Steps to Reproduce

Install nova from the link above and run nova version

Additional Context

--

References

--

Nova sometimes does not detect previously detected events

Installation Process

Nova is installed by Homebrew.

Nova Version

nova version 0.0.1

Don't know why version is not showing correct version string, installation date was shortly before this ticket.

Expected Behavior

Nova should always show the correct version information.

Actual Behavior

Nova showed an update available for weave-flux once, but the next run this was gone

Steps to Reproduce

Repeat nova find multiple times.

(⎈ |cluster-1:default)➜  ~ nova find --helm-version=auto --wide
Release Name           Chart Name             Namespace          Installed    Latest    Old      Deprecated
flux-global            flux                   base-deployment    1.3.0        1.5.0     true     false
flux                   flux                   base-deployment    1.3.0        1.5.0     true     false
helm-operator          helm-operator          base-deployment    1.0.1        1.2.0     true     false
promtail               promtail               base-logging       0.23.0       2.0.0     true     false
prometheus-operator    prometheus-operator    base-monitoring    9.3.1        9.3.2     true     false
traefik                traefik                base-routing       8.8.0                  false    false
sealed-secrets         sealed-secrets         base-secrets       1.9.0        1.11.0    true     false
(⎈ |cluster-1:default)➜  ~ nova find --wide
Release Name           Chart Name             Namespace          Installed    Latest    Old      Deprecated
flux-global            flux                   base-deployment    1.3.0                  false    false
flux                   flux                   base-deployment    1.3.0                  false    false
helm-operator          helm-operator          base-deployment    1.0.1                  false    false
promtail               promtail               base-logging       0.23.0       2.0.0     true     false
prometheus-operator    prometheus-operator    base-monitoring    9.3.1        9.3.2     true     false
traefik                traefik                base-routing       8.8.0        9.1.1     true     false
sealed-secrets         sealed-secrets         base-secrets       1.9.0        1.11.0    true     false

Additional Context

Helm Charts are installed by HelmOperator.

References

Issues with artifact.io rate limiting

Does anyone have issues around the rate limiting given a large number of helm charts? Is there a way to filter out which helm charts are being searched for?

Sometimes Nova fails to complete running because of not finding private Charts in ArtifactHub

What happened?

We have a lot of private Helm Charts that don't exist in AH and mostly that works fine with Nova. Sporadically Nova quits unexpectedly with the following message: Error getting artifacthub package repos: failed to search for packages for term <chart name>

What did you expect to happen?

For Nova to mark the Chart as not-outdated and continue to process the next Chart.

How can we reproduce this?

I don't know

Version

3.6.2

Search

• I did search for other open and closed issues before opening this.

Code of Conduct

• I agree to follow this project's Code of Conduct

Additional context

No response

Support scanning for updates to Helm-backed ArgoCD Application CRDs

Is your feature request related to a problem? Please describe.
ArgoCD has the concept of Application CRDs. These can source from Helm charts themselves, but do not install helm in the traditional manner. Rather, it renders the templates, and then applies those to the cluster. As such, you do not see helm installs with the helm cli, and as such, Nova seems not to be able to find them and assess upgradable candidates.

This feature request is to add this functionality to Nova.

Describe the solution you'd like
Add a flag to Nova to allow it to also scan ArgoCD Application CRD instances on your cluster and check them for updates if they are based on Helm charts.

Describe alternatives you've considered
I am unaware that any exist.

Additional context
I don't see that any is required here but let me know if you do.

Configure CLA

Ability to manually specify charts to check

Is your feature request related to a problem? Please describe.

Nova does two things according to the README:

Nova scans your cluster for installed Helm charts, then cross-checks them against all known Helm repositories

I'd like to be able to use Nova for that second part (cross-checking Helm charts against their repositories to see if they're outdated and/or deprecated) without the first part (discovering the charts by scanning a cluster).

For example, scanning may fail if you didn't use helm install to install a chart (see #6). Or you may want to see if a chart is deprecated before you install it.

Describe the solution you'd like
Ability to manually specify the set of charts to check. Something like a --charts CLI option. Specifying this option would disable scanning for charts in the cluster and instead check the specified charts.

Describe alternatives you've considered
If you don't want scanning for charts, then perhaps there is a more purpose built tool that would make sense to use instead of Nova?

Make it easier to output JSON

Is your feature request related to a problem? Please describe.
If I want to output JSON, I seem to have to set --output-file. There's no way to output JSON to stdout, or non-json to a file

Describe the solution you'd like
Have separate --output-file and --format flags

Describe alternatives you've considered
Better documentation of existing behavior

Additional context
https://fairwindscommunity.slack.com/archives/C02C608F6E7/p1647604190597329

Homebrew Tap does not support m1

Installation Process

N/A

Nova Version

N/A

Expected Behavior

Installation should work on m1 mac machines

Actual Behavior

FairwindsOps/pluto#197

Steps to Reproduce

1. Have an m1 mac
2. brew install FairwindsOps/tap/nova

Additional Context

N/A

References

• FairwindsOps/pluto#197

I can submit a PR to fix this. I think we just need to add a goreleaser build for ARM + Darwin

Support for helm template

Is your feature request related to a problem? Please describe.
If helm is only used for templating, no applications are discovered.

Describe the solution you'd like
Since helm has standards, and those include app versions and such, it should be possible to discover installations via annotations, rather than expecting helm install to have been used. This will allow terraform and pulumi based helm installations to be shown.

Add a flag to enable pre-release versions

What happened?

✗ nova find
Release Name      Installed    Latest          Old      Deprecated
============      =========    ======          ===      ==========
cert-manager      v1.5.5       1.8.0           true     false
external-dns      6.2.4        6.2.4           false    false
gitea             5.0.4        5.0.4           false    false
ingress-nginx     4.0.19       4.1.0-beta.1    true     false
metrics-server    5.8.9        5.11.7          true     false
synapse           1.1.5        1.1.5           false    false
infrastructure/resources   ⎈ do-sfo3-iratepublik (gitea)  main
▶ helm search repo ingress-nginx
NAME                            CHART VERSION   APP VERSION     DESCRIPTION
ingress-nginx/ingress-nginx     4.0.19          1.1.3           Ingress controller for Kubernetes using NGINX a...

What did you expect to happen?

I expected to see 4.0.19 as the latest version for ingress-nginx

How can we reproduce this?

Install ingress-nginx chart, run nova find

Version

Version:3.0.2 Commit:f8f0448ca2362fff6797578a595308dd956ce462

Search

• I did search for other open and closed issues before opening this.

Code of Conduct

• I agree to follow this project's Code of Conduct

Additional context

No response

Find always outputs in json

What happened?

Running nova find and nova find --wide always output in json

What did you expect to happen?

Expected output to be in a readable format (or prettyfied)

How can we reproduce this?

install via brew
run nova find or nova find --wide

Version

3.6.0

Search

• I did search for other open and closed issues before opening this.

Code of Conduct

• I agree to follow this project's Code of Conduct

Additional context

No response

Generate prometheus metrics

Feature.

In production environment we want get alerts when a chart become deprecated, or when a chart is not up to date

Description
For each helm charts found on K8S cluster nova create a prometheus metrics. This metrics contains many labels.

The metrics nove_helm_uptodate_metrics will be equal to 1 if chart deployed is not up to date.

nova_helm_uptodate_chart{chart="cert-manager", installed="v0.11.0", latest=" v0.15.0", deprecated="false"} 1

And other metrics should be a metrics on a deprecated chart:

If chart is deprecated the metrics equal 1 otherwise equal 0.

nova_helm_deprecated_charts{chart="cert-manager", installed="v0.11.0", latest=" v0.15.0", deprecated="true"} 1

And after prometheus scrap nova and get metrics and we can create this alerts:

nova_helm_uptodate_chart < 0
nova_helm_deprecated_charts < 0

Add e2e testing

Adding e2e testing via venom would enable some validation of functionality beyond unit testing. Similar to how Pluto does it

Nova find - could not detect helm 3 charts

What happened?

I have helm version - v3.3.1 and able to list helm releases in cluster
When I run nova command, I am getting this error.

$ nova find

root.go:207] error getting helm releases: could not detect helm 3 charts: list: failed to list: stream error when reading response body, may be caused by closed connection. Please retry. Original error: stream error: stream ID 1; INTERNAL_ERROR; received from peer

What did you expect to happen?

It should run as expected to list helm chart versions

How can we reproduce this?

I have helm version - v3.3.1 and able to list helm releases in cluster
When I run nova command, I am getting this error.

$ nova find

root.go:207] error getting helm releases: could not detect helm 3 charts: list: failed to list: stream error when reading response body, may be caused by closed connection. Please retry. Original error: stream error: stream ID 1; INTERNAL_ERROR; received from peer

Version

3.0.2

Search

• I did search for other open and closed issues before opening this.

Code of Conduct

• I agree to follow this project's Code of Conduct

Additional context

No response

The CHANGELOG.md is not update in repo

Hello,

I noticed that the change log does not have information on new releases (example on breaking changes).

What do you think ? Should we remove it or add a task in the CI to verify that the CHANGELOG file has been updated before merging.

Allow to configure an ignore list of charts that don't need checking

Is your feature request related to a problem? Please describe.
We have a lot of private charts installed and we don't need Nova telling us that they don't have updates or even worse, they might match names that exist in artifacthub and then Nova claims they have updates, so we would like to tell Nova what charts to ignore. Sometimes Nova throws an error like Error getting artifacthub package repos: failed to search for packages for term broca for some of our private packages, which this would solve as well

Describe the solution you'd like
Add a CLI flag and a Config file option to add a list of ignored Chart names

Make Docker Image Public Available

Is your feature request related to a problem? Please describe.
Instead of installing many small tools on my local machine I often just use the container image since its faster to update or even has auto update when you use the latest tag.

I can see that there is already exist a Dockerfile in this repo but the Image doesn't seem to be public available.

Describe the solution you'd like
Push the Container Image to Docker Hub or Gitlab Container Registry.

Due to the Docker Pull limits I suggest the Gitlab Container Registry if you don't want to push to both.

consider supporting --context or --kube-context

Is your feature request related to a problem? Please describe.
there appears to be no way to pick a kubeconfig context, which forces user to separate specific contexts into individual kubeconfigs

Describe the solution you'd like
support --context or --kube-context cli option to select appropriate context from kubeconfig

Describe alternatives you've considered
one can generate a separate kubeconfig with the following

kubectl --context=${context_name} config view --minify --flatten