-
Notifications
You must be signed in to change notification settings - Fork 150
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: use https protocol in the 'che-incubator/che-code/insiders' editor #1810
Conversation
I would set |
@l0rd I can do that, but I thought that 7.75.0 has been released and we should not update it afterwards |
RIght. There are 2 versions of che-code, one for version |
we need to change probably we need the same changes in downstream as well: https://github.com/redhat-developer/devspaces/blob/devspaces-3-rhel-8/dependencies/che-plugin-registry/che-editors.yaml#L166 |
thanks for the clarification, updated |
@svor looks like smth. weird is happening with the |
9319594
to
5a582ad
Compare
Signed-off-by: Ilya Buziuk <[email protected]>
5a582ad
to
ae05276
Compare
Signed-off-by: Ilya Buziuk <[email protected]>
@@ -131,13 +131,14 @@ export class MetaYamlToDevfileYaml { | |||
devfileEndpoint.attributes['type'] = 'main'; | |||
} | |||
|
|||
// if it's secured, remove secure option for now but add extra s on the protocol | |||
// if it's secured, remove 'secure' option for now but change protocol to secure (https or wss) | |||
if (devfileEndpoint.attributes && devfileEndpoint.attributes.secure === true) { | |||
devfileEndpoint.secure = false; |
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 don't understand why we change secure to false when it was set to true.
I think we shouldn't change the value.
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.
@l0rd do you happen to remember why it was done that way? I recall that secure
attribute might be in general not supported by DWO
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.
cc: @amisevsk ^
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 I don't remember. My guess would be that secured
is currently ignored (it was used by che-server when it was creating routes) and to have a secured endpoint (that requires authentication) you need to set the supportURLRewrite
to true.
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.
The Devfile API docs give
Describes whether the endpoint should be secured and protected by some authentication process. This requires a protocol of https or wss.
but I think (haven't verified) that this field is either ignored in Che or is interpreted as "use https instead of http" (which isn't really appropriate, API-wise). I think the "most correct" solution would be something like
- If
secured
andsupportURLRewrite
, use gateway URL - If either is false, use plain route
- If
secured
but notsupportURLRewrite
, fail workspace with error as we can't put auth on a plain route
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.
Signed-off-by: Ilya Buziuk <[email protected]>
Codecov Report
@@ Coverage Diff @@
## main #1810 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 21 21
Lines 563 564 +1
Branches 88 88
=========================================
+ Hits 563 564 +1
|
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.
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: ibuziuk, svor 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 |
- name: code-redirect-1 | ||
targetPort: 13131 | ||
exposure: public | ||
protocol: http | ||
protocol: https | ||
attributes: | ||
discoverable: false | ||
urlRewriteSupported: false |
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 haven't had time to verify this directly and so I'm not sure it's an actual problem, but does this cause issues when running on Kubernetes? Since these endpoints have urlRewriteSupported: false
, I believe Che will support them via plain ingresses, and I'm not sure if Che is able to configure TLS there.
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.
yeah, good point, I need to check this on minikube
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.
tried to verify on minikube but it looks like Che is not supported on this arch in general:
❯ Eclipse Che Operator pod bootstrap
✔ Scheduling...[OK]
✖ Downloading images
→ Failed to download image, reason: ErrImagePull, message: rpc error: co
…
Starting
Create ValidatingWebhookConfiguration org.eclipse.che
Create MutatingWebhookConfiguration org.eclipse.che
Create CheCluster Custom Resource
Error: Command server:deploy failed with the error: Failed to download image, reason: ErrImagePull, message: rpc error: code = Unknown desc = no matching manifest for linux/arm64/v8 in the manifest list entries. See details: /Users/ibuziuk/Library/Caches/chectl/error.log. Eclipse Che logs: /var/folders/87/t16qbhjd6sn7cz51_g716sh40000gn/T/chectl-logs/1697121281363.
at newError (/Users/ibuziuk/chectl/lib/utils/utls.js:39:19)
at wrapCommandError (/Users/ibuziuk/chectl/lib/utils/command-utils.js:53:32)
at Deploy.<anonymous> (/Users/ibuziuk/chectl/lib/commands/server/deploy.js:82:65)
at Generator.throw (<anonymous>)
at rejected (/Users/ibuziuk/chectl/node_modules/tslib/tslib.js:165:69)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
Cause: Error: Failed to download image, reason: ErrImagePull, message: rpc error: code = Unknown desc = no matching manifest for linux/arm64/v8 in the manifest list entries.
at /Users/ibuziuk/chectl/lib/tasks/pod-tasks.js:149:39
at Generator.next (<anonymous>)
at fulfilled (/Users/ibuziuk/chectl/node_modules/tslib/tslib.js:164:62)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
However, Smoke Test PR check should cover the minikube verification. Adding @dmytro-ndp for PR approval
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 got Network Error when tried to start workspace of Eclipse Che Next on minikube which is using external plugin registry with URL https://pr-check-1810-che-plugin-registry.surge.sh/v3 given by @ibuziuk :
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.
@olexii4 @akurinnoy folks, it looks like in general it is not possible to reference external plugin registry from the CR since we would hit CORS on dashboard end, right?
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.
It looks like CORS requests are disabled on PR checks like https://pr-check-1810-che-plugin-registry.surge.sh/v3
@svor do you happen to know if it is expected?
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.
@ibuziuk yes, it is expected. Published content on surge.sh doesn't support CORS requests. I've checked external plugin registry with https://eclipse-che.github.io/che-plugin-registry/main/ and it works good.
@dmytro-ndp you can verify current changes by patching Che CR, here is the image that was built with current changes: quay.io/vsvydenk/che-plugin-registry:https-pr
You can deploy Che on minikube by chectl server:deploy --batch --platform minikube --che-operator-cr-patch-yaml patch.yaml
where patch.yaml
is:
apiVersion: org.eclipse.che/v2
spec:
components:
pluginRegistry:
deployment:
containers:
- image: quay.io/vsvydenk/che-plugin-registry:https-pr
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.
What does this PR do?
use https protocol in the 'che-incubator/che-code/insiders' editor
Note that it only changes protocol for
che-incubator/che-code/insiders
, not sure if we should update it for the rest of the editors (some of which look obsolete now and should probably be removed).Screenshot/screencast of this PR
What issues does this PR fix or reference?
https://issues.redhat.com/browse/CRW-4869
How to test this PR?
Tested with custom che-editor.yaml - https://github.com/ibuziuk/quarkus-api-example/blob/main/.che/che-editor.yaml
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.