-
Notifications
You must be signed in to change notification settings - Fork 782
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TypeError reading 'forEach' #615
Comments
Hey @jrbe228, thanks for raising this! Cyclops renders UIs based on the helm chart schema in There are tools that will allow you to generate the schema from your helm charts -> https://github.com/dadav/helm-schema Let us know if the issue persists after you add the Nonetheless, we will update the error message so it is easier to determine the cause of the error. |
@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 |
@petar-cvit @ghorvathansys |
Confirmed on my side. Now
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: 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. |
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:
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! |
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:
|
@jrbe228 I implemented a first draft of what the Helm chart management would look like and attached a screen recording. 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.mp4Regarding 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! |
Thread started on the Cyclops Discord channel. My first impression is the new tab looks very useful.
|
@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. |
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 😂 |
@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 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 😄 |
Hey @jrbe228, as promised, we made a release candidate v0.15.0-rc.3 🔥 You can install it with the following command:
With this rc, you should be able to edit the values of your releases through the UI and delete releases. The UI will render if your installed helm charts contain the values.schema.json, if not, you will get the same warning we mentioned above. You can also find external IPs sections on your services :) Currently, the rc fetches your releases from secrets, which is Helm's default behavior. If you are storing your releases through some other Helm driver, let me know, and we can support it. Also, not to break your K8s API, for the rc version, we limit which kinds are fetched when you check release details (image below). Here you can find a list of resource kinds that are displayed. Let me know if you encounter any issues so we can add this to the next main release |
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:
Expected behavior
No errors. Template options displayed for Argo Workflows.
Screenshots
Resulting error:
Desktop (please complete the following information):
Additional Context
On the bright side, the new private templates feature works as expected.
The text was updated successfully, but these errors were encountered: