redhat-developer/odo

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

@sspeiche as per discussion in this issue #2463 . ServiceRequestBinding requires the service binding operator to be installed on the cluster and we can do the binding without using the ServiceRequestBinding CRD as well.

@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