-
Notifications
You must be signed in to change notification settings - Fork 244
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
Fix: ServiceBinding resources are not deployed with odo deploy #6029
Conversation
✅ Deploy Preview for odo-docusaurus-preview canceled.
|
The change is small, but complexifies the logic of the code:
I think that making some refactoring around the functions |
@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 |
@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). |
It seems to be working fine so far. Creating SB before Deployment has not been a problem so far. |
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 |
Yes, I was thinking that too. |
50dc2e0
to
919c53d
Compare
Signed-off-by: Parthvi Vala <pvala@redhat.com>
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.
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 { |
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.
Why only for dev mode? Don't we want to use the library for odo deploy
?
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.
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.
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.
OK.
I can see some tests failing about odo logs, probably not related, I'll restart the tests to be sure
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.
No, they're failing locally as well. I am debugging them.
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) |
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.
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 ?
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.
Yes you are right, you could set the owneerref when you're creating them
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 |
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. |
Kudos, SonarCloud Quality Gate passed!
|
/lgtm |
/approve /override ci/prow/unit-and-validate-test |
@feloy: Overrode contexts on behalf of feloy: ci/prow/unit-and-validate-test, ci/prow/v4.10-integration-e2e In response to this:
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. |
[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 |
…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>
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 deploy
#5883odo deploy
#5883odo deploy
.Note: Test case for
odo dev
without SBO is pending.