fix: Mark composite as unready if resources are skipped #137
Conversation
Signed-off-by: Maximilian Blatt <[email protected]>
MisterMX
force-pushed
the
fix/skipped-composite-unready
branch
from
22987e3
to
988a317
Compare
| if skipped > 0 { | ||
| rsp.GetDesired().GetComposite().Ready = fnv1beta1.Ready_READY_FALSE | ||
| } |
There was a problem hiding this comment.
Unfortunately I don't think this'll work. Functions can't directly specify the readiness of the XR, they're supposed to influence it by specifying the readiness of composed resources.
Obviously that makes this tricky, given Crossplane wouldn't even know the composed resource exists in this case. 🤔
There was a problem hiding this comment.
Yes, tests turned out, that it is not working as expected since the ready state of the composite is hardcoded in crossplane to be determined by the ready state of the composed resources.
We have implemented a workaround that sets an arbitrary composed resource to unready until a set of dependent resources is available. Its more like a hack than an actual solution but it seems to be the only way to prevent this issue at the moment.
@negz are there any plans to change this behaviour in the implementation of the function renderer of Crossplane? It is very confusing that the ready field exists but is not recognized at all.
|
Closing since it does not actually solve the problem due to Crossplane ignoring the ready property for composite resources. We solved this problem in a custom function implementation by keeping an arbitrary resource explicitly as unready until all other resources exist. Then the regular readiness checks takes over. |
|
This should now work, but we'll need to bump the function-sdk-go dependency once we bump it to crossplane/crossplane#6021 |
|
Ah no, actually this will just be ignored, there was no schema change! 🎉 |
This small fix marks the desired composite as unready in the response if one of the resource templates is skipped due to a missing required patch path.
Related to #12.
Fixes #152