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
added
documentation
|
@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 |
|
A few initial observations.
Note that 2) and 3) are somewhat related to this issue and this issue. |
|
@jrbe228, thanks for the update! Regarding points 2 and 3, we could scope Cyclops to a single namespace through an environment variable. We already have similar logic to scope Modules reconciler to updates from a specific namespace. I'm keen to add a separate env variable from the one controlling the reconcile, something like I agree with the point that the service account has too many permissions in our install yaml. We purposely made it that way so anything can be deployed through Cyclops, but once we implement the scoping of Helm releases, you can limit permissions to only a single namespace :) We will include Helm release management in the next release ( |
|
@petar-cvit - looking forward to testing v0.15.0+ next week! Regarding limited install permissions, could you update the docs with specifics on what K8s SA config should work for a single namespace? I see the |
|
Sure thing, @jrbe228. Will update the docs with a new page for the namespace scope, including env variables and permissions. Since you will be using Cyclops for Helm releases, I was thinking about adding an environment variable that would disable the Module reconciler so you can't accidentally deploy a new app |
|
I think you can leave the Module reconciler running. Deploying a new app is actually useful in either of these namespaces - |
Thanks for the feedback. We won't implement it for now
Still tweaking some things that were queried on cluster scope, and we will get back to you with Cyclops configuration and Roles/Service accounts for single namespace setup ASAP |
|
Hey @jrbe228, we released v0.15.2 with all the necessary changes for Cyclops to work namespaced scoped. We updated our helm chart so you can configure the Role, Role Binding, and all the Cyclops controller env variables to scope it to a single namespace. There is also a new page in our docs on how to limit Cyclops to a namespace here. TL;DR You can generate all the resources for a single namespace with the following command helm template cyclops oci://registry-1.docker.io/cyclopsui/cyclops-chart \
--namespace <your-namespace> \
--include-crds \
--set global.singleNamespaceScope.enabled=true \
--set global.singleNamespaceScope.namespace=<your-namespace>Let me know if permissions configured like this are ok with you and if Cyclops is working as expected on your end 😄 |
|
My initial reaction - the core capabilities work. I can install to the I did notice one issue (likely caused by my config) with resource discovery. Helm releases show no resources when I deploy in narrow-namespace mode. I will let you know if I find out more info.
|
|
@jrbe228 thanks for the feedback! For the resource discovery on releases, Cyclops lists all of the resources with the following label values:
Check if your Helm chart adds those labels. We might make the selector labels configurable so that they are not the only ones used to find resources. I see the release name contains testpod. Does it contain only a single Pod? If yes, Cyclops currently fetches resources only from these GVRs, and it does not fetch pods as a single resource, but only as part of Deployments/StatefulSets/DaemonSets. You can also check if your resources (Deployments, Services...) are deployed in the correct namespace. When Cyclops is namespaced scoped, it fetches stuff only from the specified namespace. Let us know if any of these fix your problem, and we can patch it up on our end |
|
Bad example 😄 Isolated Pods would indeed be ignored by Cyclops. Moving on to an actual Helm release in the cluster, this Service format is a little different than Cyclops is expecting: We could probably add labels on our side. I'm just wondering what makes sense in general. Would other Cyclops users be likely to have the same annotation Completely separate question. |
Would this be a blocker for you, or can you use Deployments or something else? Regarding labels, we decided to query based on the
This isn't documented (sorry about that, we will add it to the docs), but you can just set the repo to |
|
No need for isolated pod discovery. That was an irrelevant example. Everything we need Cyclops to manage is composed of Deployment / Service / etc. About missing the standard labels, it looks like our charts need them added. Will try that soon. Great to know about the TemplateAuthRule regex feature! |
|
It seems we have an unintentional feature 😄 The label |
|
Unrelated to other items on this issue...
Initially I tried to supply a local Windows file path, which gave the above error. Maybe only Unix file paths are supported? Or maybe it should be a Git repo URL. Also I tried to copy / paste values directly into the text field. These values did not seem to be loaded. |
|
@jrbe228, thanks for the feedback on the docs. We will remove the warning! If you want to load a YAML file into the form, you need to provide a URL to a YAML file. For example, if you have a file on GitHub that you would like to use, you can provide a URL to the raw version of it (e.g. https://raw.githubusercontent.com/cyclops-ui/templates/refs/heads/main/demo/values.yaml). You currently can't import values from local files. We talked about removing this feature altogether since it is not that widely used and comes from a time before we introduced templates as a concept. We found some issues with this feature, and it adds a lot of complexity to the values flow. One issue is that even though your Cyclops instance can access a private repo, this feature cannot fetch your values from that same repo. You can also encounter problems when the template and the values mismatch, so I would not recommend using this feature. If you would like to use this feature, let us know, and we will try to revamp it. If not, we will likely remove it in the next version. |
|
Copy/pasting raw text to the values importer could be nice for quick testing (but not super useful in general). Copy/paste would avoid the private repo limitation and the local file limitation. Lack of private repo support would generally block us from using the YAML import feature. Most of our repos are private / internal. Generally each Helm chart has many Values files for users to select. Each Values.yaml has defaults for the specific cluster or specific use case:
So I am considering how to handle these defaults. We can't set them as chart defaults, since they only work for specific use cases. Perhaps the best option is setting up 1 Cyclops template for 1 values.yaml file. Surprisingly the Helm schema generator does not seem to preserve defaults, unless there is some option flag I missed. Here is the resulting module creation in Cyclops, after generating a values-schema.json from the above screenshot Values file:
In summary I don't know how to supply all these defaults in a Cyclops module, unless I manually edit the values-schema.json. |
@jrbe228 I agree. We will then leave the feature so you can paste your YAML config, but we will remove the option to fetch it since it would be confusing if it couldn't resolve a URL to a private repo.
Yeah, sounds good. You could have separate branches for your different use cases that each have their own
Just to be clear, all the values that come filled out when you select a template come from the
The schema gen tool will preserve the defaults, but Cyclops does not take them into account. I will look into that so you can have that default in values.schema.json instead of only values.yaml. |
|
|
@jrbe228, we released 
I did some digging on the default values in the helm schema, and it seems that helm does not respect those - helm/helm#8218 Because of that, we will not support them to be consistent with Helm and not to introduce confusion for other users. If you see some other way to solve this that would require our help, let me know 😄 |
|
Nice! The copy / paste feature should work for our simpler use cases. It implicitly supports concatenating multiple values files, which is fairly common. I assume multiple values files was not supported by the legacy "loading from file" feature. About defaults in the helm schema, we might try to find a creative way to handle that. Maybe with enumeration in the json schema.. or some other approach. But it's less urgent thanks to the copy / paste feature. |
|
One thing I noticed on the install page -
It seems there is a consistent 0.1 difference between docs and latest release version -
|
|
Thanks @jrbe228, I just bumped it. We will figure out a way to bump this automatically so it's not lagging behind |
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: