Proposal: Adding fromCompositeFieldPath to connectionDetails

[mcbenjemaa]

What problem are you facing?

Difficulties to span connectionDetails

How could Crossplane help solve your problem?

[Proposal]
Sometimes you gotta fetch connectionDetails from composite resource fields.

Hence, It'd be better to add this functionality.
For instance, a fromCompositeFieldPath should be added to the connectionDetails in the Composition.

However, The combination and transformation of fields also could be helpful in this case.

[mcbenjemaa]

relates to #2551

[negz]

@mcbenjemaa Thanks for the proposal!

We already have a (poorly documented) FromFieldPath type of connection detail that reads a value from a composed resource. Could you give me a little bit more information about your use case? I'm wondering if FromFieldPath would work for you, or if you really need the value to come from an XR field.

[mcbenjemaa]

@negz I have a Helm release and I'm trying to construct a hostname from the status of my composite resource.
It would be more easier for me to get connectionDetails from the status of my composite resource.

Although, there's a workaround to get this field from connectionDetails of the release but I think it's worth to have this kind of field supported in the connectionDetails.

PS: I have submitted a PR, don't hesitate to have a look.

[negz]

It would be more easier for me to get connectionDetails from the status of my composite resource.

Can you explain why this is easier, please? I presume your status field is derived from a composed resource field, right? Could you just use that composed resource field?

[mcbenjemaa]

No, I can't use the composed resource field because I need to combine it and transform it.

this is a simple example:

    # patch status host  
    - type: CombineToComposite
      combine:
        variables:
          - fromFieldPath: "metadata.name"
          - fromFieldPath: "spec.forProvider.namespace"
        strategy: string
        string:
          fmt: "%s-client-service.%s"
      toFieldPath: status.host

then, I have the status.host published to the composite resource which is great.
that was the idea, later on the connectionDetails could just fetch it :)

I have also some other uses cases Where I would set a DNS name in the composite spec, and I want to supply it to the secret as connectionDetails.

[negz]

Thanks for the context @mcbenjemaa. That makes sense. Given that currently (iirc) a composite resource field can only be derived from a single composite resource, would you still need this functionality if we instead implemented the suggestions in #2551? That is, if you could use something like CombineToComposite to 'combine' multiple values from a composed resource into a connection detail?

My thinking is that if we proceed with this we'll want to add something like spec.connectionDetails to the Composition type to allow deriving connection details from the XR rather than a composed resource. I'm not totally opposed to that, but I wouldn't want to do it if it would solve the same problem as #2551.

[mcbenjemaa]

My thinking is that if we proceed with this we'll want to add something like spec.connectionDetails to the Composition type to allow deriving connection details from the XR rather than a composed resource. I'm not totally opposed to that, but I wouldn't want to do it if it would solve the same problem as #2551.

I agree, While I don't know to much about the design here,
I think this is gonna help in some situation.
but as I mentioned, combining fields to connectionDetails is something should be implemented. (with the attention to allow combination from both sides {From my point of view})

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.