Kube.ts: ClusterIssuer Detection

[gnoejuan]

Describe the bug

https://github.com/che-incubator/chectl/blob/14fd73f22ca7cdef6503a64306f11c727d2e997d/src/api/kube.ts#L1869

It looks like kube.ts doesn't account for other versions.

I cannot confirm right now, I'm currently chasing a different issue, but here is my current clusterissuer

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    email: user@email.com
    server: https://acme-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      # Secret resource that will be used to store the account's private key.
      name: letsencrypt-prod-key
    solvers:
    - dns01:
        cloudflare:
          email: user@email.com
          apiKeySecretRef:
            name: cloudflare-api-token-secret
            key: api-token
      selector: {}

In the task list, a self-signed certificate is queued.

Che version

• [ x ] latest
• nightly
• other: please specify

Steps to reproduce

Expected behavior

Runtime

• [ x ] kubernetes (include output of kubectl version)
• Openshift (include output of oc version)
• minikube (include output of minikube version and kubectl version)
• minishift (include output of minishift version and oc version)
• docker-desktop + K8S (include output of docker version and kubectl version)
• other: (please specify)

Screenshots

Installation method

• [ x ] chectl
  • provide a full command that was used to deploy Eclipse Che (including the output)

chectl server:deploy --che-operator-cr-yaml='/media/charlesrod/KINGSTON/kubernetes/k8s/che/che-cluster.yaml' -a operator -p k8s -b che-che.charlesrod.me

 * provide an output of `chectl version` command

chectl/7.22.0 linux-x64 node-v10.23.0

• OperatorHub
• I don't know

Environment

• my computer
  • Windows
  • [ x ] Linux
  • macOS
• Cloud
  • Amazon
  • Azure
  • GCE
  • [ x ] other (please specify): k3os
• other: please specify

Eclipse Che Logs

Additional context

[tolusha]

@gnoejuan
I got it.

[mmorhun]

Reported problem is fixed. Now, Che will pick up cluster issuer from cert-manager namespace if there is only one. If there are two or more, then client/org.eclipse.che=true label should be added to the cluster issuer that is desired to be used by Che. If none is present, then Che will create own one (as it was before).
Sadly, but I didn't have infrastructure to test the PR with Let's Encrypt cluster issuer, so it might have another problem later. Please report a new issue if something goes wrong and we'll try to handle that.