lburgazzoli opened a new issue, #3501: URL: https://github.com/apache/camel-k/issues/3501
### Context I did some experiments with [Crossplane](https://crossplane.io) which allows to orchestrate resources across cloud providers by creating custom resources, as example wit the following CRs: ```yaml apiVersion: s3.aws.crossplane.io/v1beta1 kind: Bucket metadata: name: foo-my-bucket spec: forProvider: acl: private locationConstraint: eu-south-1 writeConnectionSecretToRef: name: my-s3 namespace: default ``` ```yaml apiVersion: sqs.aws.crossplane.io/v1beta1 kind: Queue metadata: name: foo-my-sqs spec: forProvider: region: eu-south-1 writeConnectionSecretToRef: name: my-sqs namespace: default ``` Will result in an SQS queue and S3 bucket being created on AWS and the nice thing is that the status sub resource of those resources, reports information about the resource, as example, the status for the queue defined above is: ```yaml status: atProvider: arn: arn:aws:sqs:eu-south-1:xxx:foo-my-sqs url: https://sqs.eu-south-1.amazonaws.com/xxx/foo-my-sqs ``` Additional information may be projected to the secret defined by the `writeConnectionSecretToRef` property. ### Problem With https://github.com/apache/camel-k/issues/2625, we want to rename `KameletBinding` to `Binding` as a binding is a generic concept that goes beyond kamelets, however the underlying machinery could still be leveraging a kamelet to perform the actual wiring but the issue is that as today we have to introduce ad hoc support for any new resource we want to support which is unmaintainable in the long run. ### Proposed solution Crossplane has a concept of [composite resources](https://crossplane.io/docs/v1.9/concepts/composition.html) which allows to compose a number of [managed resources](https://crossplane.io/docs/v1.9/concepts/managed-resources.html) so that you can build your own APIs without introducing any new controller/operator. One part of the composition is about to _bind_ a field of the newly crafted API to the underling managed resource and a similar approach can be used to be able to dynamically configure a kamelet from an arbitrary CR As example, assuming we write a binding to wire the resources created in the example above: ```yaml apiVersion: camel.apache.com/v2 kind: Binding metadata: name: sqs-to-s3 spec: source: ref: apiVersion: sqs.aws.crossplane.io/v1beta1 kind: Queue name: my-queue sink: ref: apiVersion: s3.aws.crossplane.io/v1beta1 kind: Bucket name: my-bucket ``` We can define a new resource (find a better name): ```yaml apiVersion: camel.apache.com/v2 kind: KameletResourceBinding metadata: name: crossplane-sqs spec: selectors: - apiVersion: sqs.aws.crossplane.io/v1beta1 kind: Queue kamelets: - apiVersion: camel.apache.org/v2 kind: Kamelet name: aws-sqs-source - apiVersion: camel.apache.org/v2 kind: Kamelet name: aws-sqs-sink propertiesRef: - name: "queueNameOrArn" fromFieldPath: status.atProvider.arn - name: "region" fromFieldPath: spec.forProvider.region - name: "accessKey" fromSecretKeyRef: nameRef: spec.forProviderwriteConnectionSecretToRef key: foo ``` When camel-k reconciles the binding: - it looks up for any KameletResourceBinding matching the configured resources - it extracts the relevant information from the resources - it generates the route and secrets according NOTE: secrets management is still to be investigated. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
