-
Notifications
You must be signed in to change notification settings - Fork 88
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
Use endpoint-specific service for discoverable endpoints #1903
Conversation
Fix eclipse-che/che#23061 Signed-off-by: Andrew Obuchowicz <[email protected]>
Signed-off-by: Andrew Obuchowicz <[email protected]>
Signed-off-by: Andrew Obuchowicz <[email protected]>
f28ebe4
to
914c14c
Compare
@dkwon17 this PR has now been rebased onto the main branch |
FWIW: I confirmed with @eye0fra that the che-operator image built from this PR fixes the issue described in eclipse-che/che#23061 |
/retest-required |
@@ -474,12 +476,38 @@ func getCommonService(objs *solvers.RoutingObjects, dwId string) *corev1.Service | |||
return nil | |||
} | |||
|
|||
func exposeAllEndpoints(cheCluster *chev2.CheCluster, routing *dwo.DevWorkspaceRouting, objs *solvers.RoutingObjects, ingressExpose func(*EndpointInfo), endpointStrategy EndpointStrategy) *corev1.ConfigMap { | |||
func getServiceForEndpoint(objs *solvers.RoutingObjects, endpoint dwo.Endpoint) *corev1.Service { |
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.
func getServiceForEndpoint(objs *solvers.RoutingObjects, endpoint dwo.Endpoint) *corev1.Service { | |
func getEndpointService(objs *solvers.RoutingObjects, endpoint dwo.Endpoint) *corev1.Service { |
WDYT?
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.
+1 good call :)
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.
Done
wsRouteConfig := gateway.CreateEmptyTraefikConfig() | ||
|
||
commonService := getCommonService(objs, routing.Spec.DevWorkspaceId) | ||
if commonService == nil { | ||
return nil | ||
return nil, fmt.Errorf("could not find the common service for workspace '%s'", routing.Spec.DevWorkspaceId) |
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.
Can we order functions in the file like so?
exposeAllEndpoints
determineEndpointService
getEndpointService
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.
I assume you mean just moving the functions around in the che_routing.go
file right? If so, yes! Though I think it's worth also moving getCommonService
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, thank you
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.
Done, though I might have gotten your order wrong (I was confused by determineEndpointService
). Let me know if you want me to re-order things.
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.
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.
Could we update the function names?
getServiceForEndpoint
and getEndpointService
sound a bit too similar IMO, how about
getServiceForEndpoint
to getEndpointService
getEndpointSerive
to getService
?
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.
getServiceForEndpoint and getEndpointService sound a bit too similar IMO,
I agree, what do you think about the renames in df6fd02?
getServiceForEndpoint
->getEndpointService
getEndpointService
->determineEndpointService
(I think this makes it a bit more clear that we're getting the appropriate service to use for an endpoint)
Otherwise, I'll just change getEndpointService
-> getService
as you initially suggested :)
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.
getServiceForEndpoint -> getEndpointService
getEndpointService -> determineEndpointService (I think this makes it a bit more clear that we're getting the appropriate service to use for an endpoint)
Ok, lets do that
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.
Sounds good :) if you're +1 for this PR, I'll squash my fixup commit and it'll be good to merge
/retest-required |
@AObuchow |
@tolusha Thank you for bringing this to my attention. I've been going crazy trying to figure out why this is happening (I was able to reproduce this issue as well on minikube). So far, it seems like the health endpoint is returning a 502, as I see the following in the ingress-nginx-controller logs:
Similarly, in the DWO logs:
Oddly enough, this issue seems to not occur if you use the UDI. For example, creating a workspace with the following URL works for me: So I'm led to believe that the health check doesn't work on certain non-udi images when Che is deployed on minikube? The image used in my reproducer devfile was At some points in my testing, I also had errors like the following in the ingress-nginx-controller logs:
But using the "Create New if Existing" option in the dashboard resolved it?... which is confusing as I compared the devworkspace, devworkspacetemplate, devworkspacerouting and ingresses created and everything seemed the same. However, for the workspace with the above error, only the code-redirect-1 ingress could be created (as the error describes it couldn't use the host & path for the code-redirect-2). |
My above theory as to what was going wrong was incorrect. I've now gotten my minikube cluster into a state where devfiles using the UDI (that were working just moments ago) are now giving the incorrect ingress configuration error:
This is occuring while using the upstream image of Che Operator. |
After terminating the |
@tolusha I'm still confused as to what's going on, so I opened eclipse-che/che#23179. When you have a moment, please test using the above devfile - thank you :) |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: AObuchow, dkwon17, tolusha The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Signed-off-by: Andrew Obuchowicz <[email protected]>
Build 3.18 :: operator-bundle_3.x/3657: Console, Changes, Git Data |
Build 3.18 :: sync-to-downstream_3.x/7802: Console, Changes, Git Data |
Build 3.18 :: push-latest-container-to-quay_3.x/4974: Console, Changes, Git Data |
Build 3.18 :: sync-to-downstream_3.x/7802: Build container: devspaces-operator-bundle synced; /DS_CI/get-sources-rhpkg-container-build_3.x/7809 triggered; /job/DS_CI/job/dsc_3.x triggered; |
Build 3.18 :: operator-bundle_3.x/3657: Upstream sync done; /DS_CI/sync-to-downstream_3.x/7802 triggered |
Build 3.18 :: copyIIBsToQuay/2835: Console, Changes, Git Data |
Build 3.18 :: dsc_3.x/2017: Console, Changes, Git Data |
Build 3.18 :: operator-bundle_3.x/3658: Console, Changes, Git Data |
Build 3.18 :: sync-to-downstream_3.x/7804: Console, Changes, Git Data |
Build 3.18 :: push-latest-container-to-quay_3.x/4976: Console, Changes, Git Data |
Build 3.18 :: sync-to-downstream_3.x/7804: Build container: devspaces-operator-bundle synced; /DS_CI/get-sources-rhpkg-container-build_3.x/7811 triggered; /job/DS_CI/job/dsc_3.x triggered; |
Build 3.18 :: operator-bundle_3.x/3658: Upstream sync done; /DS_CI/sync-to-downstream_3.x/7804 triggered |
Build 3.18 :: copyIIBsToQuay/2836: Console, Changes, Git Data |
Build 3.18 :: dsc_3.x/2018: Console, Changes, Git Data |
Build 3.18 :: dsc_3.x/2018: 3.18.0-CI |
Build 3.18 :: operator-bundle_3.x/3659: Console, Changes, Git Data |
Build 3.18 :: sync-to-downstream_3.x/7806: Console, Changes, Git Data |
Build 3.18 :: push-latest-container-to-quay_3.x/4978: Console, Changes, Git Data |
Build 3.18 :: sync-to-downstream_3.x/7806: Build container: devspaces-operator-bundle synced; /DS_CI/get-sources-rhpkg-container-build_3.x/7813 triggered; /job/DS_CI/job/dsc_3.x triggered; |
Build 3.18 :: operator-bundle_3.x/3659: Upstream sync done; /DS_CI/sync-to-downstream_3.x/7806 triggered |
Build 3.18 :: copyIIBsToQuay/2837: Console, Changes, Git Data |
Build 3.18 :: dsc_3.x/2019: Console, Changes, Git Data |
Build 3.18 :: dsc_3.x/2019: 3.18.0-CI |
Build 3.18 :: copyIIBsToQuay/2837: 3.18 |
What does this PR do?
When using the
discoverable
attribute on a devfile endpoint, a service is created for that specific endpoint that's associated with the route/ingress. However, the current behaviour of the Che Router always associates an endpoint with the workspace's common service, rather than any endpoint-specific service.This PR fixes this behaviour, by ensuring the correct service is provided for each endpoint's route/ingress.
Screenshot/screencast of this PR
n/a
What issues does this PR fix or reference?
Fixes eclipse-che/che#23061
How to test this PR?
./build/scripts/olm/test-catalog-from-sources.sh
./build/scripts/minikube-tests/test-operator-from-sources.sh
quay.io/aobuchow/che-operator:endpoint-service
.pip-install-requirements
thenrun-app
devfile tasks from the CheCode UI. When the endpoint notification pops up, click "Open in New Tab".Hello World!
For comparison, here's a comment displaying the behaviour without the changes from this PR applied.
PR Checklist
As the author of this Pull Request I made sure that:
What issues does this PR fix or reference
andHow to test this PR
completedReviewers
Reviewers, please comment how you tested the PR when approving it.