[1.14] cli: Infer gloo deploy name

[davidjumani]

Description

Infer the gloo deployment name in cases where the deployment name is not the default gloo. The gloo deployment is identified by the gloo=gloo label.

Forward port of solo-io#9719

Context

solo-io#9163

Interesting decisions

Rather than adding another flag for the gloo deployment name which can soon ballon into a flag for the name of each deployment, I've decided to identify the deployment via the labels.

Testing steps

The following commands depend on the gloo deployment name :

• glooctl check

$ kg get deploy
NAME             READY   UP-TO-DATE   AVAILABLE   AGE
discovery        1/1     1            1           5h33m
gateway-proxy    1/1     1            1           5h33m
gloo-deploy-v2   1/1     1            1           9m9s

$ ./_output/glooctl-darwin-amd64 check
Checking deployments... OK
Checking pods... OK
Checking upstreams... OK
Checking upstream groups... OK
Checking auth configs... OK
Checking rate limit configs... OK
Checking VirtualHostOptions... OK
Checking RouteOptions... OK
Checking secrets... OK
Checking virtual services... OK
Checking gateways... OK
Checking proxies... OK
No problems detected.
Skipping Gloo Instance check -- Gloo Federation not detected

• glooctl get proxy

$ ./_output/glooctl-darwin-amd64 get proxy
+---------------+-----------+---------------+----------+
|     PROXY     | LISTENERS | VIRTUAL HOSTS |  STATUS  |
+---------------+-----------+---------------+----------+
| gateway-proxy | :::8080   | 1             | Accepted |
+---------------+-----------+---------------+----------+

• glooctl proxy served-config

$ ./_output/glooctl-darwin-amd64 proxy served-config

#role: gloo-system~gateway-proxy

#clusters
connectTimeout: 5s
edsClusterConfig:
  edsConfig:
    ads: {}
    resourceApiVersion: V3
....................

• glooctl get upstream -o wide

$ ./_output/glooctl-darwin-amd64 -o wide get upstream 

+-------------------------------+------------+----------+------------------------------+
|           UPSTREAM            |    TYPE    |  STATUS  |           DETAILS            |
+-------------------------------+------------+----------+------------------------------+
| default-kubernetes-443        | Kubernetes | Accepted | svc name:      kubernetes    |
|                               |            |          | svc namespace: default       |
|                               |            |          | port:          443           |
|                               |            |          |                              |
| gloo-system-gateway-proxy-443 | Kubernetes | Accepted | svc name:      gateway-proxy |
|                               |            |          | svc namespace: gloo-system   |
|                               |            |          | port:          443           |
.............

Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works

[solo-changelog-bot]

Issues linked to changelog:
solo-io#9163

[solo-changelog-bot]

Issues linked to changelog:
solo-io#9163
solo-io#9644

[bewebi]

One nit around naming
Since this is a forward-port and it was previously approved I do not consider it a blocker

[bewebi]

Why is this customGlooDeploymentName rather than glooDeploymentName?
afaict the deployment name is not necessarily a custom one

[nfuden]

it may be standard it may not be 🤷

[davidjumani]

Just to avoid confusion with the constant GlooDeploymentName and also indicate that the deployment name can be custom and has been handled in such a scenario