Repository navigation
Dev Workspace Controller Loop with Identical Endpoint Names on DevWorkspace #23231
Description
Describe the bug
If I start two workspaces containing an endpoint with the same name, the dev workspace controller enters a loop. As a result, both namespaces do not start and remain stuck on "Preparing Service".
sample devfile
schemaVersion: 2.3.0
metadata:
name: endpoints-issue
components:
- name: tools
container:
image: quay.io/devfile/universal-developer-image:ubi8-latest
memoryRequest: 1G
memoryLimit: 4G
cpuRequest: '1'
cpuLimit: '2'
- name: data
volume:
size: 256Mi
- name: postgresql
container:
image: quay.io/fedora/postgresql-12:latest
cpuLimit: "1"
cpuRequest: 50m
memoryLimit: 512Mi
memoryRequest: 64Mi
endpoints:
- exposure: internal
targetPort: 5432
name: postgresql
protocol: tcp
attributes:
discoverable: true
env:
- name: POSTGRESQL_USER
value: user
- name: POSTGRESQL_PASSWORD
value: pass
- name: POSTGRESQL_ROOT_PASSWORD
value: root
- name: POSTGRESQL_DATABASE
value: db
volumeMounts:
- name: data
path: /var/lib/pgsql/dataChe version
7.93@latest
Steps to reproduce
- Create two workspaces with endpoints having the same name.
- Start both workspaces.
- Observe that the dev workspace controller goes into a loop and both namespaces remain stuck on "Preparing Service".
Expected behavior
Both workspaces should start without any issues
Runtime
OpenShift
Screenshots
Installation method
OperatorHub
Environment
other (please specify in additional context)
Eclipse Che Logs
No response
Additional context
Environment:
DevSpaces Version: 3.16.1
DevWorkspaces Operator Version: 0.30.2
Activity
AObuchow commentedon Nov 4, 2024
@eye0fra Thank you for reporting this. For what its worth, this is an internally known DWO issue that's currently only documented as a TODO.
I'm not sure if there's any effective way for us to solve this: discoverable endpoints are intended to have services with a static, predefined name so that you can predict what the service will be called. If we add some level of randomization to the service's name, then it will no longer have a static name.
When starting up a workspace, we might be able to check if another workspace defines a service with the same name and fail the workspace if so, to alert the user that they need to use a different discoverable endpoint name?
Additionally, it should be documented that different devfiles used by the same user cannot define discoverable endpoints with the same name.
eye0fra commentedon Nov 4, 2024
Hi @AObuchow ,
I agree that notifying the user is the best approach for now. This way, they can make the necessary edits to the DW/devfile accordingly.
che-bot commentedon Nov 22, 2025
Issues go stale after
180days of inactivity.lifecycle/staleissues rot after an additional7days of inactivity and eventually close.Mark the issue as fresh with
/remove-lifecycle stalein a new comment.If this issue is safe to close now please do so.
Moderators: Add
lifecycle/frozenlabel to avoid stale mode.dkwon17 commentedon Dec 2, 2025
After discussion with @akurinnoy we decided to merge devfile/devworkspace-operator#1521 after we have implemented load tests that stress the DWO webhook deployment.