Link via ServiceBindingRequest
sspeiche opened this issue · 10 comments
Description
As a developer, I would like to be able to easily inject my source component with the config/secrets/envvars needed to invoke a backing application, so I can focus on may application code instead of configuring application connections.
Acceptance criteria
- User can issue link command and then push changes, when pushed it will be determined that the components are compatible for
ServiceRequestBinding
and perform the function. - User can list linked components
- User can unlink, or remove link.
User Stories
- Support linking devfile component and operator service (#2920)
- Support unlinking devfile component and operator service (#3563)
Note
This original epic was split into 2 pieces. #4590 is aligned with Milestone 2.2
@girishramnani yep, should be smart enough if installed and if annotations/olm-manifests
Why should we check if it is installed?
Why should we check if it is installed?
It would be a bad experience to attempt to do the binding and it never works, we should give feedback that binding is not enabled and give a pointer to how to enable
It would be a bad experience to attempt to do the binding and it never works, we should give feedback that binding is not enabled and give a pointer to how to enable
Chiming in since I'm working on #2920. If I understand correctly, you're suggesting what's summarized in #2920 (comment):
the discussed workflow was
to check if service binding operator is present on the cluster, if so use the
ServiceBindingRequest
as that allows the dev-console visualisation capabilities of that link.if the operator is not present then we use the logic present in the operator ( I discussed with service binding team and they mentioned that linking can happen without the operator too ).
but preference has to be given to operator and custom logic needs to only be used as a fall back.
@sspeiche At the moment, we're working as per above workflow. Prioritizing on using Service Binding Operator to connect a component with an operator backed service.
@dharmit sounds like #2930 is the implementation of this Epic, how best to link/associate them together?
- to check if service binding operator is present on the cluster, if so use the ServiceBindingRequest as that allows the dev-console visualisation capabilities of that link.
To be clear ServiceBindingRequest isn't used just for visualization in console, it actually performs the bind and then the console displays it. The console will display based on an annotation-only app.openshift.io/connects-to
, see label/annotation conventions
@dharmit sounds like #2930 is the implementation of this Epic,
Yes, it's pretty much the implementation of this Epic. ATM, it's focussing only on linking using the operator. Other items mentioned in this epic aren't a part of it. Of course, we will cover the remaining items later.
how best to link/associate them together?
Do you mean to link this Epic with that issue? I can modify the user story there to include this Epic as a "Related Issue" or a "Feature Request".
- to check if service binding operator is present on the cluster, if so use the ServiceBindingRequest as that allows the dev-console visualisation capabilities of that link.
To be clear ServiceBindingRequest isn't used just for visualization in console, it actually performs the bind and then the console displays it. The console will display based on an annotation-only
app.openshift.io/connects-to
, see label/annotation conventions
Sure, thanks for pointing that out. I wasn't aware of the console using the annotation but my understanding of an SBR was just as you've mentioned - "it actually performs the binding and console then displays it".
Issues go stale after 90d of inactivity.
Mark the issue as fresh by commenting /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen
.
If this issue is safe to close now please do so with /close
.
/lifecycle stale
/lifecycle frozen
We have completed all ACs on this epic. Hence closing