Dev Workspace Controller Loop with Identical Endpoint Names on DevWorkspace

[eye0fra]

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/data

Che version

7.93@latest

Steps to reproduce

1. Create two workspaces with endpoints having the same name.
2. Start both workspaces.
3. 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

[AObuchow]

@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]

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]

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.