You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When configuring an XRD with a conversion webhook and CA Bundle injection via CertManager, the resulting CRD reconciliation enters an infinite patch loop between Crossplane and CertManager.
The loop behaves as follows:
Crossplane creates the CRD representing either the XR or Claim. No CA Bundle is present in the spec.
CertManager notices the CRD is marked for CA Bundle injection and patches the CRD with the proper CA Bundle.
Crossplane reconciles the updated CRD and removes the CA Bundle.
Go to step 2.
This results in:
An infinite spam of reconciliations for the affected CRD.
A conversion webhook which is hard to reach, as you must get lucky and hope your request connects when the CRD has the CA Bundle present.
How could Crossplane help solve your problem?
Two Three approaches come to mind.
Hard-Coded Approach
Add hard-coded logic in Crossplane's Claim CRD and CompositeResource CRD reconcilers that is specific to CertManager. This logic would check for a CA Bundle in the existing CRD and copy it over before applying the spec derived from the XRD.
Generic Approach
Extend the XRD API to allow users to specify paths that are externally managed (e.g., by CertManger). For each path, the CRD reconciler would attempt to copy the value from existing CRD before applying the CRD derived from the XRD.
Using Patch Applicator
We could replace the usage of NewAPIUpdatingApplicator with NewAPIPatchingApplicator for the CRD reconcilers. I tested this and it solves the issue, but may have negative side effects.
The text was updated successfully, but these errors were encountered:
@dalton-hill-0 WRT using NewAPIPatchingApplicator, would using server-side apply to apply the CRDs work? I think eventually we'd like to remove our applicators and just use either SSA or get-mutate-update.
@dalton-hill-0 WRT using NewAPIPatchingApplicator, would using server-side apply to apply the CRDs work? I think eventually we'd like to remove our applicators and just use either SSA or get-mutate-update.
@negz
I believe this should work. I will throw something together and let you know how it goes.
I opened a draft PR. This currently implements SSA for the XR CRDs. I tested this locally and it fixes the CertManager issue mentioned in this thread. If this is the desired approach, I can implement the same for claims.
What problem are you facing?
When configuring an XRD with a conversion webhook and CA Bundle injection via CertManager, the resulting CRD reconciliation enters an infinite patch loop between Crossplane and CertManager.
The loop behaves as follows:
This results in:
How could Crossplane help solve your problem?
TwoThree approaches come to mind.Hard-Coded Approach
Add hard-coded logic in Crossplane's Claim CRD and CompositeResource CRD reconcilers that is specific to CertManager. This logic would check for a CA Bundle in the existing CRD and copy it over before applying the spec derived from the XRD.
Generic Approach
Extend the XRD API to allow users to specify paths that are externally managed (e.g., by CertManger). For each path, the CRD reconciler would attempt to copy the value from existing CRD before applying the CRD derived from the XRD.
Using Patch Applicator
We could replace the usage of
NewAPIUpdatingApplicator
withNewAPIPatchingApplicator
for the CRD reconcilers. I tested this and it solves the issue, but may have negative side effects.The text was updated successfully, but these errors were encountered: