-
Notifications
You must be signed in to change notification settings - Fork 223
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
Adding github repo - Request entity too large: limit is 3145728 #1650
Comments
Please add a link to the public github repo here so we can reproduce your problem. |
|
Thanks. This repo has huge You probably want to move the files relevant for Fleet to a sub-directory. |
I have the same issue after upgrade of rancher 2.6.8 to 2.7.5 and fleet just uninstalled the app from all downstream and from the local cluster! This is really critical... There is not much / just yaml files in our git repo! Any idea for a workaround and ETA for a fix? |
Hmm, it's probably not Git or Fleet but Kubernetes (resp. etcd). Googling around reveals e.g. |
Hm - but why do we see this in Rancher 2.7.5 and did not see this in Rancher 2.6.8? What has been changed in fleet between these two versions that would bring us to this problem? |
I don't think Fleet's the culprit here 😉 |
Fleet does an uninstall after the upgrade of Rancher from 2.6.8 to 2.7.5. So something must have changed in fleet and maybe it is a design issue in fleet.. we really need to find a way to get more debug info. |
🤔 Well that's a good question we went from Fleet 0.3.11 to [0.7.0] |
In my case it really seems that the root cause of the problem is that targetCustomizations did not work for repo and version.. and now that works. In combination with the large rancher-monitoring helm chart (4MB extracted) this seems to cause some limits to be hit.. So this causes a problem (rancher-monitoring-crd chart - but same problem exists with rancher-monitoring chart even worse):
This does not cause a problem:
|
|
That's correct.
That looks like a separate issue. I found out some resources were redeployed when upgrading from 2.6.8 to 2.7.5. The problem with the monitoring chart is that old resources are removed, but the new |
For each The empty resources upgrade might be related to something that has changed in the way fleet stores the helm manifest, but this needs more investigation. |
Resources are disappearing because a helm upgrade with empty resources is done. This is happening on Rancher upgrades for The problem is that the checksum is different as it is now using the right helm version from the The problem with the Examples:
|
We might add an OCI repo as an alternative storage in the future, or extend the bundle/contents to use multiple k8s resources to work around the limits. |
Closing this (see previous comment for a rationale). |
I ran into this problem as having two versions of the kube-prometheus-stack chart are now enough to trigger this. It seems like this is likely to be a frequent issue and the only solution is to split the bundle into multiple objects, one resource per chart version. |
I have the same issue while trying to install the groundcover chart. this is because Bundle contains non templated helm chart, so it's too big to store in etcd. is there any way to store only the templated resources instead of the whole chart (including comments, documentations and everything) |
Hi, it seems we just started seeing this problem with a bundle exceeding 3M with ~100 kustomize overlays. Is there any documentation/way we can test this (or a timeline for release)? |
SURE-6732
Is there an existing issue for this?
Current Behavior
Unable to add a public github repository to Continuous Delivery.
Error:
Expected Behavior
Add github repo.
Steps To Reproduce
Environment
Logs
No response
Anything else?
related: #205
The text was updated successfully, but these errors were encountered: