TypeError reading 'forEach'

[jrbe228]

Describe the bug
I'm unable to create modules from the Helm chart for Argo Workflows. Trying a popular chart like Argo was a debugging step after seeing the same error from various charts in private repos.

To Reproduce
Steps to reproduce the behavior:

1. In CyclopsUI, go to 'Templates'
2. Click on 'Add template reference'
3. Enter the following:

Repository URL:  https://github.com/argoproj/argo-helm
Path:  charts/argo-workflows

4. Attempt to create a module from this template. See error.

Expected behavior
No errors. Template options displayed for Argo Workflows.

Screenshots
Resulting error:

TypeError: Cannot read properties of null (reading 'forEach')
Check if Cyclops backend is available on: http://cyclops-ctrl.cyclops:8080

Desktop (please complete the following information):

• OS: Windows 10
• Browser: Edge
• Version: 129.0.2792.79
• CyclopsUI version: v0.13.1
• Kubernetes distro: K3s installed with Rancher Desktop

Additional Context
On the bright side, the new private templates feature works as expected.

[petar-cvit]

Hey @jrbe228, thanks for raising this!

Cyclops renders UIs based on the helm chart schema in values.schema.json. You are seeing this issue on argo workflows chart because those charts do not contain the mentioned file.

There are tools that will allow you to generate the schema from your helm charts -> https://github.com/dadav/helm-schema
Cerbos and Grafana K6 use it, and we find it straightforward and simple to use. It will read your values.yaml and generate values.schema.json based on it. You can then push the schema json along with your chart, and you should be able to use your UIs.

Let us know if the issue persists after you add the values.schema.json in case we need to dive deeper.

Nonetheless, we will update the error message so it is easier to determine the cause of the error.

[petar-cvit]

@jrbe228, we added a short section to our docs on how to add a helm schema here.

We fixed the error you got, and Cyclops will now allow you to install Helm charts that do not contain the schema.

Also, we added a new warning banner when a template without a schema is used. It links to Helm docs about schema files and our newly added docs on schema generation. It should help future users mitigate the issue you had. This banner will be included from version v0.14.1

[jrbe228]

@petar-cvit
Thank you for the quick response! I should have feedback later this month.

@ghorvathansys
Here is one issue which may be resolved now. I need to re-test after returning from Europe.

[jrbe228]

We fixed the error you got.

Confirmed on my side. Now TypeError... is replaced by warning banner in your screenshot.

Cyclops will now allow you to install Helm charts that do not contain the schema.

This is a great feature! Quick sanity testing by deploying any public repo and with the default Helm values. Working for me with ArgoWF.

There is one more related feature critical for our use cases. When I deploy the ArgoWF Helm release from CyclopsUI's module page, everything works. The module is displayed:

However when I deploy the ArgoWF Helm release without using CyclopsUI, using simple command line instead:
helm repo add argo https://argoproj.github.io/argo-helm
helm install my-release argo/argo-workflows

Nothing is displayed in the CyclopsUI dashboard. Do I need some annotation for the release to be recognized? My apologies if this feature is already explained in the docs.

This feature is valuable for our compatibility with legacy systems. We have many existing pipelines which deploy Helm releases. During deployment, the pipelines inject Helm data from internal company servers. So it's difficult to convert this process to a Cyclops format quickly. We hope to continue using the legacy pipelines for Helm release deployment. Then use Cyclops for lifecycle management once the release is deployed.

[petar-cvit]

Hey @jrbe228,

Cyclops currently shows only modules, which are a Cyclops CRD, that reference a Helm chart and values to be used with the chart. It doesn't show existing Helm releases and their resources in the cluster.

I see two possible solutions for managing Helm releases through Cyclops:

1. Implement the same support for Helm releases as we have for Cyclops modules
2. Show all existing Helm releases and support easy migration from an existing Helm release to a Cyclops Module. The migration would be done through the UI or the cli and would retain all existing values and resources

I am more in favor of the second option since we wanted to implement something like this a while back, but I would love to hear what you think.

Let me know which option sounds best for your case!

[jrbe228]

Either option would be an improvement! Hopefully we can get input from the community also. I am admittedly biased towards convenience for our use cases. To give more context from our side, we see apps progressing as follows:

• Initial development in a local container
• Intermediate development on transient Kubernetes releases, managed via Cyclops
• Advanced (staging / pre-production) development on persistent Kubernetes releases, managed via ArgoCD

[petar-cvit]

@jrbe228 I implemented a first draft of what the Helm chart management would look like and attached a screen recording.
We are considering adding a new tab on the sidebar with all the Helm releases detected in the cluster. For each release, you could see its name and namespace and its chart.

When you select one release, you can check the resources deployed from it. From there, you could edit the release directly and apply updated resources or migrate the helm chart to a Cyclops module with a couple of clicks, giving you a more robust solution through our Module CRD.

Cyclops will also pick up all newly installed helm releases.

cyclops-helm-management.mp4

Regarding the input from the community, you can join our discord and start a thread there. Let me know if something like this would help your use case!

[jrbe228]

Thread started on the Cyclops Discord channel.

My first impression is the new tab looks very useful.

• Migration to Cyclops Module is an option, but no longer a requirement for visibility.
• I guess advanced features like "rollback" can be accessed after migration to Modules. These are less relevant for our use cases with short lifecycles.
• Having a "Delete" option for releases would be convenient. But ok if migration is required first.
• I'm thinking how we would expose critical info from specific resources, such as a Service external IP.

[petar-cvit]

I guess advanced features like "rollback" can be accessed after migration to Modules

@jrbe228 my thoughts as well. We could implement editing releases directly, but you can migrate to modules if you need more capabilities.

We can add the delete release option, no problem 👍

Also, we can add external IPs to the Service view or any other field you think might be useful. In the long run, we are also thinking of implementing a dynamic view of the resources so anybody can configure how their resources are visualized or do it through plugins. For now, you can suggest any fields you would like to see in the UI, and we can add them.

[jrbe228]

At the moment, Service external IP is the only critical info to add. Ports are already summarized nicely:

I see Cyclops already has Auth and RBAC on the roadmap. We would benefit from these features in the long term. However the platform is usable without them, assuming we trust our Devs to be responsible 😂

[petar-cvit]

@jrbe228, yeah, RBAC is in the works! There is already an open PR for it we are still working on - #361

We added an external IPs section to the service, which gets all the IPs (and hostnames) from .status.loadBalancer.ingress of the service, along with IPs from .spec.externalIPs.

I will create a release candidate version with external IPs and Helm release management, which you can play around with. I will notify you once the rc is built and how to install it.

I would love to hear if it would help your use case and if there is anything else you would like to see included 😄