Closed mproffitt closed 3 weeks ago
I tested the change by building the function myself and for sure it looks like I mis-understood how the PatchDesired
target works although it did get to the point of telling me I was wrong which was a definite improvement
Hello, I've added more examples about the PatchDesired
target and can this help you?
This actually makes a lot more sense now, thank you.
Closing as working as expected
What happened?
I currently have a composition whereby
function-patch-and-transform
creates a DB Cluster. I then pass this to an instantiation offunction-kcl
withtarget: PatchDesired
to further patch the cluster with more dynamic properties before handing it back to be created.This then results in the following condition on the XR:
It would appear that this is related to the following revert commit but in reality I think both sides of the diff were wrong: https://github.com/crossplane-contrib/function-kcl/commit/1faa3149779b2a6d2a9ff1f3a61c68063196563d
Reading through this, the call
resource.Name(d.GetName())
retrieves themetadata.name
from the unstructured object and converts that toresouce.Name
but this relies onmetadata.name
being set, and matching exactly the resource name in desired-composed.This is invalid as the resource name often has no reference to
metadata.name
which may, or may not be setA better behaviour was almost there on the left hand side of the diff which relied on the annotation, and if not found, fell back to GVK+Name.
A closer matching would potentially look something like this, allowing the fallback to
metadata.name
if theAnnotationKeyCompositionResourceName
is not set.This, (I think) would allow the desired resource to be targeted as follows:
A better option might be to have
getName
return an error if the annotation is not found rather than falling back tounstructured.Unstructured.GetName()
, this is how functionpatch-and-transform
appears to handle itHow can we reproduce it?
What environment did it happen in?
Function version: 0.9.0
localstack