Closed oblogic7 closed 3 months ago
@oblogic7 Thanks for the report. We are not using this resource at the moment. Let me see if i have some time to test this.
After more digging, I believe it is related to this issue. I responded there with my findings.
I think this may be solved with a newer version of upjet that has this change.
Ok, good find. One thing you might check is that the supplied information in the resource you are giving is actually correct. Upjet actually renders hcl manifests but it might get some different information back when created. If this information is not the same as what you are supplying (but still yields the same result) i could also imagine a reconciliation loop.
You can either run this provider locally and check the tmp dirs it creates for the manifests it renders or you can try to import a TeamRepository using terraform/opentofu and inspect the state. https://registry.terraform.io/providers/integrations/github/latest/docs/resources/team_repository#import
I don't think that is the case. The loop happens when the reconciler attempts to update the status field. This happens when observation.ResourceUpToDate
is true, so the comparison between desired state and current state has already happened and validated that there are no changes.
@oblogic7 I updated to the latest upjet and crossplane runtime. It is released in v0.5.0 https://marketplace.upbound.io/providers/coopnorge/provider-github/v0.5.0
Can you check if this by change resolves your issue?
stale -> closing
The TeamRepository resources in my cluster appear to be constantly reconciling. As soon as one is finished another is reconciled. This is causing 5000 Github API requests to be exhausted within about 15 minutes with a total of 5 resources. Polling interval and max-reconciliation-rate do not have any impact on this behavior. I'm still looking into this, but haven't been able to identify why the resources are being reconciled so frequently.