-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Native bindings #92
Comments
This is a concept I've been torn by in the past. The implementation is not hard, but to what end? A bare secret is unlikely to contain the metadata necessary to actually consume a service unless it was created with that intent in mind. The In order to provide the best user experience, our goal is for service providers to implement the provisioned service duck type and not say that users referencing a Secret directly is good enough.
Not sure what Route you're talking about (Knative?), but the Ingress resource supports virtual hosts with multiple hostnames and backend services, so I'm not sure how a ServiceBinding could make sense of it without already knowing what it's looking for. I'm in favor of allowing implementations to understand service references beyond the provisioned service duck type, and likewise for applications, but I'm unsettled on adding that to the spec. |
Ya - I guess it's a balance in terms of which part of the spec we favour adoption: allowing Secrets to be referenced directly doesn't provide motivation for service providers to adopt the spec (they can say "hey, I am already exposing the information via a Secret, leave me alone" 😄 ), but, it does allow spec adoption for I think there are vastly more |
We can see some of the side effects of thinking of arbitrary Secrets as binding material here. #96 (comment) I fully agree that we need to be realistic about interop with the existing world, but we should avoid encouraging behavior that will lead to confusion or downstream violations of the spec (like a projected volume not including a |
I think the concept of the duck type can apply here: if a Secret conforms to the spec's view of a bindable Secret, it can be used a spec Secret. In other words, if it has things like |
Arthur to create a PR and continue discussions there |
@arthurdm After thinking about the "native binding" I wrote this. Let me know if the extension described below captures your proposal. Let me know if you want me to send this as a PR.
Edit 1: Change annotation from "method" to "source" |
Probably the annotation could be:
|
is the service:
apiVersion: v1
kind: Secret If they are redundant, we should drop the annotation, if they are not we should explain how they are different. |
Why limit this to Custom Projections? The source of the service secret is orthogonal to how it is projected into an application. |
Yes, the annotation is redundant. I am fine with dropping it. |
Yes, there is no need to restrict this into Custom Projection. But this feature should be still an extension for the sake of portability, right? |
I have changed the extention proposal without using Custom Projection.
|
hey @baijum - sorry for the delay in responding to this. I like the latest proposal a lot better 👍 I definitely agree this is orthogonal to projection - this is about the "other" side, the provisioned service just having a single Secret. The projected app should see no differences. An extension sounds like the right way to go, since we already have annotations / x-descriptors as extensions. Basically the options for a service provider would be: If you wanted to make a PR with your latest post, that would be awesome @baijum! I appreciate that. My suggestion is to call it something like |
Direct Secret Reference extension allows Service Binding resource with the service directly pointing to a secret resource. This address the "Native Bindings" issue servicebinding#92 Signed-off-by: Baiju Muthukadan <baiju.m.mail@gmail.com>
Direct Secret Reference extension allows Service Binding resource with the service directly pointing to a secret resource. This address the "Native Bindings" issue servicebinding#92 Signed-off-by: Baiju Muthukadan <baiju.m.mail@gmail.com>
Direct Secret Reference extension allows Service Binding resource with the service directly pointing to a secret resource. This address the "Native Bindings" issue servicebinding#92 Signed-off-by: Baiju Muthukadan <baiju.m.mail@gmail.com> Co-authored-by: Scott Andrews <scott@andrews.me>
Direct Secret Reference extension allows Service Binding resource with the service directly pointing to a secret resource. This address the "Native Bindings" issue servicebinding#92 Signed-off-by: Baiju Muthukadan <baiju.m.mail@gmail.com> Co-authored-by: Scott Andrews <scott@andrews.me> Signed-off-by: Baiju Muthukadan <baiju.m.mail@gmail.com>
Direct Secret Reference extension allows Service Binding resource with the service directly pointing to a secret resource. This address the "Native Bindings" issue servicebinding#92 Co-authored-by: Scott Andrews <scott@andrews.me> Signed-off-by: Baiju Muthukadan <baiju.m.mail@gmail.com>
Closing as completed |
One scenario that comes up a lot are services that have their bindings as a k8s Secret, but don't have a duck typed CR nor the extension annotations.
This issue proposes that we allow
ServiceBinding.spec.service
to point to a regular k8s Secret and behave as if it was defined via a duck type. This would enableServiceBinding
authors to connect to various existing services without the need to wrap it with other CRs (such as theProvisionedService
concept).Taking this further, and inspired by Service Binding Operator's detection support, we could even allow for Ingress / Route resources to be natively bindable - for example, if a microservice just needs to know the URL to connect to.
The text was updated successfully, but these errors were encountered: