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

This will be forward ported

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

[nfuden]

/kick Consul settings specify automatic detection of TLS services, but the rootCA reso

[jbohanon]

nit: caller should be responsible for logging the error.

Fine with leaving it here but could we use contextutils.LoggerFrom to get the logger?

[jbohanon]

Suggested change

	errMessage = "too many app=gloo deployments, cannot decide which to target"
	errMessage = "too many deployments labeled gloo=gloo; cannot decide which to target"

[jbohanon]

Comments will be addressed in forward ports

[jbohanon]

nit:

Suggested change

	// Initialize the custom deployment name that is overwritten later on
	// Initialize the custom deployment name that is overwritten later on in the `CheckResources` function