Skip to content
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

Fix: ServiceBinding resources are not deployed with odo deploy #6029

Merged
merged 3 commits into from
Aug 24, 2022

Conversation

valaparthvi
Copy link
Contributor

@valaparthvi valaparthvi commented Aug 17, 2022

Signed-off-by: Parthvi Vala pvala@redhat.com

What type of PR is this:
/kind bug

What does this PR do / why we need it:
ServiceBinding resources are now allowed to be deployed on the cluster with odo deploy.

Which issue(s) this PR fixes:

Fixes #5883

PR acceptance criteria:

  • Unit test

  • Integration test

  • Documentation

How to test changes / Special notes to the reviewer:
1.

odo init --devfile go --name my-go-app --starter go-starter
  1. Copy the contents of the devfile.yaml as mentioned in ServiceBinding resources are not deployed with odo deploy #5883
  2. Deploy the bindable kind instance as mentioned in ServiceBinding resources are not deployed with odo deploy #5883
  3. Run odo deploy.
PODMAN_CMD=echo odo deploy

Note: Test case for odo dev without SBO is pending.

@netlify
Copy link

netlify bot commented Aug 17, 2022

Deploy Preview for odo-docusaurus-preview canceled.

Name Link
🔨 Latest commit 8fdafc5
🔍 Latest deploy log https://app.netlify.com/sites/odo-docusaurus-preview/deploys/63063c974ce490000aecc929

@openshift-ci openshift-ci bot added the kind/bug Categorizes issue or PR as related to a bug. label Aug 17, 2022
@openshift-ci openshift-ci bot requested review from dharmit and feloy August 17, 2022 12:01
@odo-robot
Copy link

odo-robot bot commented Aug 17, 2022

Unit Tests on commit a66b4ea finished successfully.
View logs: TXT HTML

@odo-robot
Copy link

odo-robot bot commented Aug 17, 2022

Validate Tests on commit a66b4ea finished successfully.
View logs: TXT HTML

@odo-robot
Copy link

odo-robot bot commented Aug 17, 2022

Kubernetes Tests on commit a66b4ea finished successfully.
View logs: TXT HTML

@odo-robot
Copy link

odo-robot bot commented Aug 17, 2022

OpenShift Tests on commit a66b4ea finished successfully.
View logs: TXT HTML

@odo-robot
Copy link

odo-robot bot commented Aug 17, 2022

Windows Tests (OCP) on commit ee0dae9 finished with errors.
View logs: TXT HTML

@feloy
Copy link
Contributor

feloy commented Aug 18, 2022

The change is small, but complexifies the logic of the code:

  • For odo dev, we are using PushLinks to create the bindings with or without operators
  • For odo deploy, we are directly applying the servicebinding resource

I think that making some refactoring around the functions PushLinks, pushDevfileKubernetesComponents, PushKubernetesResources and PushKubernetesResource would be helpful, so the code would be usable for odo dev and odo deploy in a nice way.

@valaparthvi
Copy link
Contributor Author

@feloy There were a few complications with the refactoring when SBO is not installed. Since we're using library, it is required that the deployment in question be present before creating the secret. Because of this, we'll create the link after the component deployment is created if SBO is not present, otherwise it'll be created normally like any other K8s component.

With odo deploy, we don't really need to deal with the Without SBO scenario.

@feloy
Copy link
Contributor

feloy commented Aug 23, 2022

@feloy There were a few complications with the refactoring when SBO is not installed. Since we're using library, it is required that the deployment in question be present before creating the secret. Because of this, we'll create the link after the component deployment is created if SBO is not present, otherwise it'll be created normally like any other K8s component.

With odo deploy, we don't really need to deal with the Without SBO scenario.

@valaparthvi Did you try by creating all Kubernetes resources (servicebindings and all other resources) after the deployment?

@valaparthvi
Copy link
Contributor Author

@feloy There were a few complications with the refactoring when SBO is not installed. Since we're using library, it is required that the deployment in question be present before creating the secret. Because of this, we'll create the link after the component deployment is created if SBO is not present, otherwise it'll be created normally like any other K8s component.
With odo deploy, we don't really need to deal with the Without SBO scenario.

@valaparthvi Did you try by creating all Kubernetes resources (servicebindings and all other resources) after the deployment?

Theoretically, I think that would work, but then we also talked about creating all the resources beforehand to avoid restarting the pod and speeding up the process. So I didn't go that way.

@feloy
Copy link
Contributor

feloy commented Aug 23, 2022

@feloy There were a few complications with the refactoring when SBO is not installed. Since we're using library, it is required that the deployment in question be present before creating the secret. Because of this, we'll create the link after the component deployment is created if SBO is not present, otherwise it'll be created normally like any other K8s component.
With odo deploy, we don't really need to deal with the Without SBO scenario.

@valaparthvi Did you try by creating all Kubernetes resources (servicebindings and all other resources) after the deployment?

Theoretically, I think that would work, but then we also talked about creating all the resources beforehand to avoid restarting the pod and speeding up the process. So I didn't go that way.

Thinking again about this, it's a matter of milliseconds. We would create Deployment and SBs very quickly, we are not 100% sure in which order they will be handled by controllers on the cluster.

And creating the SB before the Deployment can raise an error for the SBO because the Deployment does not exist when the SB is created, and I'm not sure how the error is recovered (either quickly or not).

@valaparthvi
Copy link
Contributor Author

And creating the SB before the Deployment can raise an error for the SBO because the Deployment does not exist when the SB is created, and I'm not sure how the error is recovered (either quickly or not).

It seems to be working fine so far. Creating SB before Deployment has not been a problem so far.

@valaparthvi
Copy link
Contributor Author

Thinking again about this, it's a matter of milliseconds. We would create Deployment and SBs very quickly, we are not 100% sure in which order they will be handled by controllers on the cluster.

Alright, let's go with creating K8s resources are the core deployment is created, it seems logical.

@feloy
Copy link
Contributor

feloy commented Aug 23, 2022

Thinking again about this, it's a matter of milliseconds. We would create Deployment and SBs very quickly, we are not 100% sure in which order they will be handled by controllers on the cluster.

Alright, let's go with creating K8s resources are the core deployment is created, it seems logical.

I'm trying to explore this direction, as it seems the most generic one, so we don't have to handle specific cases at high levels, and we can "hide" the fact that we are using the SBO library at the lowest possible level (in the kclient package).

@valaparthvi
Copy link
Contributor Author

Thinking again about this, it's a matter of milliseconds. We would create Deployment and SBs very quickly, we are not 100% sure in which order they will be handled by controllers on the cluster.

Alright, let's go with creating K8s resources are the core deployment is created, it seems logical.

I'm trying to explore this direction, as it seems the most generic one, so we don't have to handle specific cases at high levels, and we can "hide" the fact that we are using the SBO library at the lowest possible level (in the kclient package).

I find it difficult to imagine handling this case in the kclient package.

@feloy
Copy link
Contributor

feloy commented Aug 23, 2022

Thinking again about this, it's a matter of milliseconds. We would create Deployment and SBs very quickly, we are not 100% sure in which order they will be handled by controllers on the cluster.

Alright, let's go with creating K8s resources are the core deployment is created, it seems logical.

I'm trying to explore this direction, as it seems the most generic one, so we don't have to handle specific cases at high levels, and we can "hide" the fact that we are using the SBO library at the lowest possible level (in the kclient package).

I find it difficult to imagine handling this case in the kclient package.

Or in the pkg/service package?

@valaparthvi
Copy link
Contributor Author

Thinking again about this, it's a matter of milliseconds. We would create Deployment and SBs very quickly, we are not 100% sure in which order they will be handled by controllers on the cluster.

Alright, let's go with creating K8s resources are the core deployment is created, it seems logical.

I'm trying to explore this direction, as it seems the most generic one, so we don't have to handle specific cases at high levels, and we can "hide" the fact that we are using the SBO library at the lowest possible level (in the kclient package).

I find it difficult to imagine handling this case in the kclient package.

Or in the pkg/service package?

Yes, I was thinking that too.

@valaparthvi valaparthvi force-pushed the sb-bug branch 3 times, most recently from 50dc2e0 to 919c53d Compare August 24, 2022 12:51
Signed-off-by: Parthvi Vala <pvala@redhat.com>
Copy link
Contributor

@feloy feloy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

One question though

if err != nil {
return false, err
// If the component is of Kind: ServiceBinding, trying to run in Dev mode and SBO is not installed, run it without operator.
if isLinkResource(u.GetKind()) && mode == odolabels.ComponentDevMode && !sboSupported {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why only for dev mode? Don't we want to use the library for odo deploy?

Copy link
Contributor Author

@valaparthvi valaparthvi Aug 24, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With odo deploy, I would expect user to know that they're supposed to install ServiceBindingOperator if they intend to use ServiceBinding, just like they would with any other Operator CRD.
Thinking about it this way, I think it makes sense to only check for odo dev, but if we want to provide consistency, having the same behavior for odo deploy makes sense.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK.

I can see some tests failing about odo logs, probably not related, I'll restart the tests to be sure

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, they're failing locally as well. I am debugging them.

@feloy feloy closed this Aug 24, 2022
@feloy feloy reopened this Aug 24, 2022
@valaparthvi
Copy link
Contributor Author

The failures are real, I'm debugging them right now.

@@ -132,6 +127,12 @@ func (a Adapter) Push(parameters adapters.PushParameters, componentStatus *watch
return fmt.Errorf("unable to create or update component: %w", err)
}

// Create all the K8s components defined in the devfile
k8sComponents, err := a.pushDevfileKubernetesComponents(labels, odolabels.ComponentDevMode)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that we're creating these resources after the core deployment, I think it also make senses to update the owner reference before they're created. WDYT @feloy ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes you are right, you could set the owneerref when you're creating them

@valaparthvi
Copy link
Contributor Author

OpenShift test failure is probably flake or it failed because of resource crunch. The test passes locally.

odo delete command tests
/go/odo_1/tests/integration/cmd_delete_test.go:13
  when deleting a component containing preStop event that is deployed with DEV [BeforeEach]
  /go/odo_1/tests/integration/cmd_delete_test.go:257
    should contain preStop events list
    /go/odo_1/tests/integration/cmd_delete_test.go:270
...
...
...
  Timed out after 180.001s.
  Expected
      <string>:   __
       /  \__     Developing using the nodejs Devfile
       \__/  \    Namespace: cmd-delete-test270afe
       /  \__/    odo version: v3.0.0-beta3
       \__/
      
      ↪ Deploying to the cluster in developer mode
       •  Waiting for Kubernetes resources  ...
       âš   Pod is Pending
       âš   0/3 nodes are available: 3 Insufficient memory.
       âš   0/3 nodes are available: 3 Insufficient memory.
       âš   0/3 nodes are available: 3 Insufficient memory.
      
  to contain substring
      <string>: Press Ctrl+c to exit

@feloy
Copy link
Contributor

feloy commented Aug 24, 2022

Insufficient memory

This error is probably due to old pods from old tests running on the cluster. Could you connect to the Openshift cluster and check if there are old tests namespaces ? I have also seen tests pods in the default namespace this week, not sure where they were coming from.

@feloy feloy closed this Aug 24, 2022
@feloy feloy reopened this Aug 24, 2022
@sonarqubecloud
Copy link

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 3 Code Smells

No Coverage information No Coverage information
0.3% 0.3% Duplication

@feloy
Copy link
Contributor

feloy commented Aug 24, 2022

/lgtm
The code looks good
I'll try to make more tests before to approve

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. Required by Prow. label Aug 24, 2022
@feloy
Copy link
Contributor

feloy commented Aug 24, 2022

/approve

/override ci/prow/unit-and-validate-test
/override ci/prow/v4.10-integration-e2e
Infra errors
Tests pass on IBM Cloud

@openshift-ci
Copy link

openshift-ci bot commented Aug 24, 2022

@feloy: Overrode contexts on behalf of feloy: ci/prow/unit-and-validate-test, ci/prow/v4.10-integration-e2e

In response to this:

/approve

/override ci/prow/unit-and-validate-test
/override ci/prow/v4.10-integration-e2e
Infra errors
Tests pass on IBM Cloud

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.

@openshift-ci
Copy link

openshift-ci bot commented Aug 24, 2022

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: feloy

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. Required by Prow. label Aug 24, 2022
@openshift-merge-robot openshift-merge-robot merged commit 6d82a57 into redhat-developer:main Aug 24, 2022
cdrage pushed a commit to cdrage/odo that referenced this pull request Aug 31, 2022
…t-developer#6029)

* Fix: ServiceBinding resources are not deployed with odo deploy

Signed-off-by: Parthvi Vala <pvala@redhat.com>

* Fix test failures

* Add owner reference before object creation

Signed-off-by: Parthvi Vala <pvala@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. Required by Prow. kind/bug Categorizes issue or PR as related to a bug. lgtm Indicates that a PR is ready to be merged. Required by Prow.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

ServiceBinding resources are not deployed with odo deploy
3 participants