-
Notifications
You must be signed in to change notification settings - Fork 243
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
Add odo push to link/unlink tests #3837
Add odo push to link/unlink tests #3837
Conversation
This is being done for two reasons: 1) CI is likely slow to link/unlink as observed in #3834 2) link/unlink require "odo push" for underlying deployment
@@ -433,11 +433,13 @@ spec: | |||
|
|||
stdOut := helper.CmdShouldPass("odo", "link", "EtcdCluster/example") | |||
Expect(stdOut).To(ContainSubstring("Successfully created link between component")) | |||
helper.CmdShouldPass("odo", "push") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From the logs https://prow.ci.openshift.org/view/gs/origin-ci-test/logs/periodic-ci-openshift-odo-master-v4.2-integration-e2e-periodic/1298409952288706560#1:build-log.txt%3A1119 I didn't see it failing over here. Things are breaking with the lines https://github.com/openshift/odo/pull/3837/files#diff-49f09fb5341717455c0421b3c592e685R449 . So I am not sure this will fix the exact issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right. But adding odo push
at the place where you're suggesting it would be just a hack to make sure that we introduce some timeout between the two calls. Adding it where I have proposed in the PR right now makes sure that we're following the flow that a user would when using odo link
/odo unlink
commands and it still gives us the timeout we need to avoid the race condition from arising.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TBH I don't understand why we are bandaging it with odo push
when its not necessary. I would say lets not complicate the test scenario, consider a simple example:
> odo link EtcdCluster/example
> odo unlink EtcdCluster/example
> odo link EtcdCluster/example //This is failing
> odo push
Maybe your current changes will hide the issue but it won't fix the real issue. In future I am pretty sure somebody will hit the issue with the same scenario. Also frankly speaking as a end user I won't rely much on .odo/env/env.yaml
for services state failure.
@@ -433,11 +433,13 @@ spec: | |||
|
|||
stdOut := helper.CmdShouldPass("odo", "link", "EtcdCluster/example") | |||
Expect(stdOut).To(ContainSubstring("Successfully created link between component")) | |||
helper.CmdShouldPass("odo", "push") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TBH I don't understand why we are bandaging it with odo push
when its not necessary. I would say lets not complicate the test scenario, consider a simple example:
> odo link EtcdCluster/example
> odo unlink EtcdCluster/example
> odo link EtcdCluster/example //This is failing
> odo push
Maybe your current changes will hide the issue but it won't fix the real issue. In future I am pretty sure somebody will hit the issue with the same scenario. Also frankly speaking as a end user I won't rely much on .odo/env/env.yaml
for services state failure.
I already explained why we're adding this in #3834 (comment).
The real issue has been pointed to by @amitkrout in #3834 (comment). It's a race condition showing up on CI. Maybe you can fix that and I'll close this PR in that case.
We're relying on this file for information about the link. Not for the state of the service. |
Don't really understand why
|
The race condition i want to describe here is For command odo link EtcdCluster/example i have not much idea what process it runs behind the scene but as a user i would expect the next command odo unlink EtcdCluster/example should not fail due to some pending status of the previous command. May be when link or unlink command complete but it still wait some process to complete under the hood. @prietyc123 Last time i was using the the complete spec, instead you can scope out few things from there and focus the failure steps. For example you can please try these simple scenario locally.
|
It creates a Service Bbinding Request. "Service Binding Request" (SBR) is an API provided by Service Binding Operator (SBO). Due to certain limitations, we had to introduce
On the cluster side, $ odo link EtcdCluster/example
✓ Successfully created link between component "node-todo" and service "EtcdCluster/example"
To apply the link, please use `odo push`
$ odo unlink EtcdCluster/example
✓ Successfully unlinked component "node-todo" from service "EtcdCluster/example"
To apply the changes, please use `odo push` |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: amitkrout 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 |
Thanks for detailed information. Looks good to me. /lgtm |
/retest Please review the full test history for this PR and help us cut down flakes. |
1 similar comment
/retest Please review the full test history for this PR and help us cut down flakes. |
Codecov Report
@@ Coverage Diff @@
## master #3837 +/- ##
=======================================
Coverage 44.22% 44.22%
=======================================
Files 139 139
Lines 13420 13420
=======================================
Hits 5935 5935
Misses 6903 6903
Partials 582 582 Continue to review full report at Codecov.
|
/retest |
/retest Please review the full test history for this PR and help us cut down flakes. |
What type of PR is this?
I don't know. It's pretty sure not a bug! This PR is mainly opened to fix something that's working just fine on developer/QE systems but failing in CI.
What does does this PR do / why we need it:
This is being done for two reasons:
Consecutive service link/unlink doesn't work properly on CI #3834
Which issue(s) this PR fixes:
Fixes #3834
PR acceptance criteria:
Unit test
Integration test
Documentation
I have read the test guidelines
How to test changes / Special notes to the reviewer: