-
Notifications
You must be signed in to change notification settings - Fork 912
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
Wrong state of XR #4757
Comments
What do you mean by "wrong"? that the XR is still not ready? |
If you create ProviderConfig resources in a Composite you can override the healthchecks so that the state of the ProviderConfig is ignored:
which should allow the Composite to show as Ready = True. |
@phisco - should we add the Ready condition to ProviderConfig and always set it to True so we can avoid this issue? It seems like if we can create it from a Composition it should follow the same API as everything else. |
@bobh66 is right you need to add this:
https://github.com/upbound/configuration-caas/blob/main/apis/aws/eks/composition.yaml#L349-L350 cross ref: crossplane/crossplane-runtime#418 @phisco in RC-1.14 we have new condition - to show that XR is waiting for ProviderConfig ex. |
@haarchri that solved the problem, thank you |
What happened?
Wrong state of XR
How can we reproduce it?
In order to spin up a new EKS cluster on already existing networking infrastructure(AWS VPC) we prepared test Composite and XRD(see attachment)
eks-composition.yaml.txt
eks-definition.yaml.txt
eks-claim.yaml.txt
After we apply XRC, everything gets created but state of the XR is stated wrong
State of all managed resources included into Composition is ready
I assume it happens because state of the Kubernetes providerConfig we use to update
aws-auth
config map of the new EKS cluster doesn't represent anythingState of the XR
What environment did it happen in?
The text was updated successfully, but these errors were encountered: