odo link to link devfile components with each other

[dharmit]

/kind user-story

User Story

As a user I want to link a devfile component with another devfile component so that I can develop and deploy and a multi-component microservices application on k8s/OCP.

Acceptance Criteria

• odo push should create a Secret on the cluster for devfile components covered by odo link should store link information in devfile #4208.
• odo link <component-name>, when executed from a devfile component directory, should link the component with another
• It should prevent self-linking of component

Links

• Related issue: Support link command for devfile #2920, self linking of the component should not be there using odo link #1052 (for avoiding self-linking)

/area devfilev2
/area link

[openshift-ci-robot]

@dharmit: The label(s) area/link cannot be applied, because the repository doesn't have them

In response to this:

/kind user-story

User Story

As a user I want to link a devfile component with another devfile component so that I can develop and deploy and a multi-component microservices application on k8s/OCP.

Acceptance Criteria

• odo link <component-name>, when executed from a devfile component directory, should link the component with another
• It should prevent self-linking of component

Links

• Related issue: Support link command for devfile #2920, self linking of the component should not be there using odo link #1052 (for avoiding self-linking)

/area devfilev2
/area link

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[dharmit]

Adding needs info to understand how much we need this in this sprint and also to research if we can use Service Binding Operator to link components. I remember reading in their README that we can but I need to read/understand beyond that.

/triage need-information

[openshift-ci-robot]

@dharmit: The label(s) triage/need-information cannot be applied, because the repository doesn't have them

In response to this:

Adding needs info to understand how much we need this in this sprint and also to research if we can use Service Binding Operator to link components. I remember reading in their README that we can but I need to read/understand beyond that.

/triage need-information

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[dharmit]

/triage needs-information

[girishramnani]

also consider the idea of linking a devfile component with an s2i component?

[dharmit]

also consider the idea of linking a devfile component with an s2i component?

If an end-user comes with this request, we can consider adding the support. But since we plan to move away from s2i components, adding this feature doesn't help add much value presently.

[dharmit]

When we link one s2i component to another, we inject the data from the secret created at the time of pushing the component. For example, when we link component A with component B (odo link compB), component B's secret is injected into component A.

As far as Devfile components are concerned, I don't see us creating a secret for a component like we do for s2i components. Is this a conscious decision in any way? @kadel @girishramnani

So for the scope of this issue, we will have to:

1. Modify odo push to create secrets for the component.
2. Use this secret to link the Deployments using the Patch methodology that we used for s2i components.
3. When a component's port configuration is changed, underlying secrets should be altered accordingly.
4. [TBD] - if user changes the port configuration of linked component, should odo be smart enough to modify the link(s) made to this component?
5. Tests
6. Documentation

[girishramnani]

ideally shouldn’t we create secrets @dharmit

[dharmit]

I tried to link two components without creating a secret for any of them. But that didn't work. I've opened an issue on the SBO repo to understand if doing this is possible using SBO. redhat-developer/service-binding-operator#722

[dharmit]

While waiting to get more clarity on how/whether to use SBO to do this, I'm going to start working on the first acceptance criteria of this issue - odo push should create a Secret on the cluster for devfile components. It's something that doesn't depend on whether we decide to use SBO or not.

[openshift-bot]

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

[dharmit]

/lifecycle frozen

[kadel]

With correct annotations on odo created Deployments we should be able to create a ServiceBinding between two odo components https://github.com/redhat-developer/service-binding-operator/blob/master/docs/User_Guide.md#binding-metadata-in-annotations

[kadel]

• odo push should create a Secret on the cluster for devfile components

Why it should create a Secret? Secret presence is not required for binding. The secret will be created by SBO.

[kadel]

each Service generated for odo devfile component should have annotations like this:

  annotations:
    service.binding/backend_ip: path={.spec.clusterIP}
    service.binding/backend_port: path={.spec.ports},elementType=sliceOfMaps,sourceKey=name,sourceValue=port

backend in this example is name of the odo component. It should match what is already in app.kubernetes.io/name label.

than the odo link command should create link between frontend and backend component

cd frontend
odo link backend

The resulting ServiceBinding should look like this

apiVersion: binding.operators.coreos.com/v1alpha1
kind: ServiceBinding
metadata:
  name: java-maven
spec:
  application:
    group: apps
    name: frontend
    resource: deployments
    version: v1
  bindAsFiles: false
  detectBindingResources: true
  services:
    - group: ""
      kind: Service
      name: backend
      version: v1

This will expose env variables in frontend compoentn

  SERVICE_BACKEND_IP: 10.217.4.62
  SERVICE_BACKEND_PORT_PORT-8080: 8080

Note:
PORT is twice there because in the example service port has name port-8080.

  ports:
  - name: port-8080
    port: 8080
    protocol: TCP
    targetPort: 8080

If port name is for example http the env variable will be SERVICE_BACKEND_PORT_HTTP: 8080
But it looks like odo currently autogenerates port names using PORT_<number> pattern. This is an issue that should be addressed separately #4737

[mik-dass]

each Service generated for odo devfile component should have annotations like this:

Currently the devfile library generator doesn't allow to specify annotations while generating the service object https://github.com/devfile/library/blob/2aa02fa8648870c543dea5e45185a7333fcd35c3/pkg/devfile/generator/generators.go#L149. We will need to manually add it to the generated service object or make the required changes to the devfile library.

[kadel]

Currently the devfile library generator doesn't allow to specify annotations while generating the service object https://github.com/devfile/library/blob/2aa02fa8648870c543dea5e45185a7333fcd35c3/pkg/devfile/generator/generators.go#L149. We will need to manually add it to the generated service object or make the required changes to the devfile library.

The best approach might be to update devfile library to include the service annotations automatically

[mik-dass]

Currently the devfile library generator doesn't allow to specify annotations while generating the service object https://github.com/devfile/library/blob/2aa02fa8648870c543dea5e45185a7333fcd35c3/pkg/devfile/generator/generators.go#L149. We will need to manually add it to the generated service object or make the required changes to the devfile library.

We can specify the annotations with the current library version used by odo using the method

https://github.com/devfile/library/blob/bd6996094a73701919f96c9f3071623cfd27ddc3/pkg/devfile/generator/generators.go#L41.

The selectorLabels in ServiceParams are the labels used in the ServiceSpec of the generated service.