-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Che-Operator/DWO - NPE if provisioning two public endpoints on k8s #21078
Comments
@nils-mosbach thank you for reporting this issue. Can you share the devfile your are using to create the workspace? cc @tolusha @skabashnyuk @metlos labelling this as |
@l0rd I've tried to create a simple example that causes the issue in our case. https://github.com/nils-mosbach/devfile.io-demo-che-21078 It seems that Che-Operator crashes if the devfile contains a second public endpoint. This one works: devfile.works.yaml We're on next channel due to a required change in the devworkspace operator, so if we should try out something, please let me know. By the way: I'm currently looking at your work on che-code. Incredible! That's actually something a lot of our developers have been waiting for. :) Thanks! |
cc @benoitf |
Renaming this since it happens consistently if |
@nils-mosbach looking at the controller logs, you appear to be hitting an embarrassing bug on my part (devfile/devworkspace-operator#766). One issue we recently found is that next images aren't being correctly rolled out when DWO is installed via Operator. Could you manually rolling out a new DWO deployment via
or by deleting the |
Created DWO issue for |
That's good news. Upgraded devworkspace-controller to latest Currently Anyway: I really like where this is going. Startup time, devfile 2 api and the whole architecture shift. Nice! :) |
I'm glad it's resolved for you, this is the sort of bug I never want to ship!
Ah apologies, I think I really confused myself in explaining this 😄. The bug you were hitting actually does not impact the DevWorkspace Operator directly, and instead impacts other operators that use DWO as a library (the Che Operator in this case). The way Che creates ingresses and services for a DevWorkspace is by running an instance of DWO's DevWorkspaceRouting reconciler and plugging in its own implementation of how ingresses/services are defined (in code, defined here, where DWO v0.12.3 already includes this fix as a cherry-pick, and the fix is also used in Che (where it fixes the bug you were hitting) since eclipse-che/che-operator#1306. I'm only now noting the date you created this issue and had assumed it was new -- this bug was present in Che |
No worries, happens to the best of us :). Haven’t seen the cherry pick. Runs like s charm now, thanks a lot. |
Describe the bug
Che Operator keeps crashing while deploying new devworkspaces that contain public ports.
It seems that this is caused by handling DevWorkspaceRoutings.
We have a workspace that contains ~5 docker images for applications like a database that's used for development. Two ports are made public.
Sometimes after a couple of minutes and multiple operator restarts the workspace starts. Happens on 7.42 and next branch.
Che version
next (development version)
Steps to reproduce
Create a new devworkspace that has multiple ports made public.
Expected behavior
Workspace should start.
Runtime
Kubernetes (vanilla)
Screenshots
No response
Installation method
chectl/latest
Environment
Linux
Eclipse Che Logs
Additional context
No response
The text was updated successfully, but these errors were encountered: