proposal: add Service Binding proposal (#1445) #1864
Conversation
| Conversely, the drawback of implementing the second approach is that more work is needed as Camel-k would have to retrieve and inject the binding information. | ||
| The advantage would be that Camel-k retains full control of the ``Integration``'s `Deployment/Cron/Knative` resource and we can delay the startup until the binding information is available. | ||
|
|
||
| For these reasons, it seems that the second approach is preferred in the context of Camel-k. |
There was a problem hiding this comment.
assuming the camel-k operator is installed at global scope, using this approach would require the camel-k operator to have basically have access to any resource in any namespaces ?
There was a problem hiding this comment.
Thanks for reviewing! It would require the camel-k operator to have read access to the ServiceBinding and it's corresponding Secret. It would also need to have rights to create a ServiceBinding
There was a problem hiding this comment.
does the camel-k operator really need to access the secret ? I mean, the operator should add the service binding secret among the list of the secrets the integration needs, nothing more right ?
There was a problem hiding this comment.
no it doesn't, I added it for convenience to create property mappings like {DB_PORT} instead of {secret:name/DB_PORT}. Doesn't camel-k already have rights to read Secrets ?
Nevertheless I think we can achieve this by adding the logic in camel-k-runtime via a customizer and avoid camel-k reading the Secret.
Ideally though, I think we would want to add some prefix to the property to avoid clashes like {binding:name/DB_PORT} where the user could elegantly choose the name
There was a problem hiding this comment.
yes, you can tell camel-k to mount a secret and make its content available as properties
There was a problem hiding this comment.
Ideally though, I think we would want to add some prefix to the property to avoid clashes like
{binding:name/DB_PORT}where the user could elegantly choose the name
I'm not very sure about this one as the main goal is to be able to auto configure components without the user intervention, on quarkus one of the option that has been taken into account is to have a binding aware config source that is in charge to translate binding parameters to the related quarkus property and I think we should do something similar for components.
If users want to directly reference binding parameters, they should use the same syntax as for secrets {secret:$name/$property} as it is already namespaced.
There was a problem hiding this comment.
the main goal is to be able to auto configure components without the user intervention
The Camel Dream 👍
on quarkus one of the option that has been taken into account is to have a binding aware config source that is in charge to translate binding parameters to the related quarkus property
This sounds promising, do you have a Camel or a Quarkus example I could look at ? I wasn't aware this was possible
There was a problem hiding this comment.
The reference issue is here: quarkusio/quarkus#13617
As side note, for some components we may benefit directly from the work done in Quarkus as example, if the jdbc set-up is auto-magically done by a Quarkus extension, then we can consume it as we do as today without having anything to change (same could happen for kafka, infinispan, jms, etc.)
There was a problem hiding this comment.
That's definitely something we want to leverage 👍 I'll start hacking on this
Proposal for #1445
Thanks !
Release Note