don't create an extra service for discoverable endpoint

Describe the bug

Currently we create 2 services for every discoverable endpoint. This is waste of resources as we don’t need it to do our job done.

devfile

metadata:
  name: wksp-buoj
projects:
  - name: example
    source:
      location: 'https://github.com/golang/example.git'
      type: git
    clonePath: src/github.com/golang/example/
components:
  - mountSources: true
    endpoints:
      - name: go-tcp
        port: 8080
        attributes:
          discoverable: 'true'
    memoryLimit: 512Mi
    type: dockerimage
    alias: go-cli
    image: 'quay.io/eclipse/che-golang-1.12:nightly'
apiVersion: 1.0.0
commands:
  - name: run outyet
    actions:
      - workdir: '${CHE_PROJECTS_ROOT}/src/github.com/golang/example/outyet'
        type: exec
        command: go get -d && go run main.go
        component: go-cli

Che version

• latest

Steps to reproduce

1. create workspace from devfile above
2. see services it created

[~] λ kc get services -n che-che
NAME                          TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)                                  AGE
go-tcp                        ClusterIP   10.106.37.118   <none>        8080/TCP                                 4m18s
server0428va3l-go-cli         ClusterIP   10.111.36.196   <none>        8080/TCP                                 4m18s
serverlzh40tkp-jwtproxy       ClusterIP   10.100.27.253   <none>        4400/TCP,4401/TCP,4402/TCP               4m18s
serverv9yts2xr-theia-idee6b   ClusterIP   10.100.110.63   <none>        3130/TCP,13133/TCP,13132/TCP,13131/TCP   4m18s

There are 2 services for 8080, first has discoverable go-tcp name, and second has generated one.

Expected behavior

We should create only one service and use it. The name of the service should be determined based on discoverable attribute.

Runtime

• minikube (include output of minikube version and kubectl version)

Screenshots

Installation method

• chectl

Environment

• my computer
  • Linux

Eclipse Che Logs

Additional context

[sparkoo]

yes, the namespace limitation is another story.

And usecase for it is exactly what you’ve mentioned, having configurable db (or similar backend<>backend component) url so I don’t have to reconfigure it everytime I start the same workspace.

Anyway, this issue is more polish one as I don’t think we’re currently hitting the limits here…

[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.