[SURE-8794] Deploying ClusterGroup from GitRepo results in loop #2859
Comments
p-se
added a commit
to p-se/fleet
that referenced
this issue
Oct 31, 2024
Prevents fleet from crashing due to resources exceeding etcd's configured size limit. Deduplicate messages should only be necessary for edge cases which are not officially supported by fleet but result in ever increasing message sizes. This is due to the messages being copied from one resource to another and back again. Every resource adds its status to the message. This only happens if a cluster group is deployed by a GitRepo, which results in a bundle containing a cluster group. This bundle can only become ready if the cluster group is ready, but if the cluster group points to the cluster of the bundle, this cannot ever happen. The user is expected to fix this situation but deduplicating the messages prevents the message from growing up to the point where etcd's limit is reached and fleet crashes. Deduplicating the messages also has the effect of not changing the status of resources frequently, which results in less controllers being triggered.
p-se
added a commit
to p-se/fleet
that referenced
this issue
Oct 31, 2024
Prevents fleet from crashing due to resources exceeding etcd's configured size limit. Deduplicate messages should only be necessary for edge cases which are not officially supported by fleet but result in ever increasing message sizes. This is due to the messages being copied from one resource to another and back again. Every resource adds its status to the message. This only happens if a cluster group is deployed by a GitRepo, which results in a bundle containing a cluster group. This bundle can only become ready if the cluster group is ready, but if the cluster group points to the cluster of the bundle that deployed the cluster group, this cannot ever happen. The user is expected to fix this situation but deduplicating the messages prevents the message from growing up to the point where etcd's limit is reached and fleet crashes. Deduplicating the messages also has the effect of not changing the status of resources frequently, which results in less controllers being triggered.
p-se
added a commit
to p-se/fleet
that referenced
this issue
Oct 31, 2024
Prevents fleet from crashing due to resources exceeding etcd's configured size limit. Deduplicate messages should only be necessary for edge cases which are not officially supported by fleet but result in ever increasing message sizes. This is due to the messages being copied from one resource to another and back again. Every resource adds its status to the message. This only happens if a cluster group is deployed by a GitRepo, which results in a bundle containing a cluster group. This bundle can only become ready if the cluster group is ready, but if the cluster group points to the cluster of the bundle that deployed the cluster group, this cannot ever happen. The user is expected to fix this situation but deduplicating the messages prevents the message from growing up to the point where etcd's limit is reached and fleet crashes. Deduplicating the messages also has the effect of not changing the status of resources frequently, which results in less controllers being triggered.
p-se
added a commit
to p-se/fleet
that referenced
this issue
Nov 5, 2024
Prevents fleet from crashing due to resources exceeding etcd's configured size limit. Deduplicate messages should only be necessary for edge cases which are not officially supported by fleet but result in ever increasing message sizes. This is due to the messages being copied from one resource to another and back again. Every resource adds its status to the message. This only happens if a cluster group is deployed by a GitRepo, which results in a bundle containing a cluster group. This bundle can only become ready if the cluster group is ready, but if the cluster group points to the cluster of the bundle that deployed the cluster group, this cannot ever happen. The user is expected to fix this situation but deduplicating the messages prevents the message from growing up to the point where etcd's limit is reached and fleet crashes. Deduplicating the messages also has the effect of not changing the status of resources frequently, which results in less controllers being triggered.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Deploying a ClusterGroup from a GitRepo which also contains accompanying other GitRepo resources that use those newly created ClusterGroups result in a loop.
This loop triggers ClusterGroups and appends a message to it that endlessly grows, until the limit of etcd is hit. In which case Fleet is supposedly blocked.
The issue can be reproduced by adding this GitRepo resource to the cluster. The issue was reproducible on the latest Fleet development version at the time and did not require a Rancher installation to reproduce. The cluster was prepared using
dev/setup-multi-cluster.The text was updated successfully, but these errors were encountered: