(This is used to request new product features)

Describe the feature request
Improve unit tests for addons/pkg/utils and addons/pinniped/post-deploy.

Describe alternatives you've considered

Affected product area (please put an X in all that apply)

[ ] APIs
[x] Addons
[ ] CLI
[ ] Docs
[ ] Installation
[ ] Plugin
[ ] Security
[ ] Test and Release
[ ] User Experience

Additional context

Describe the feature request

This is one in a series of proposed components that cover common interactions/needs in the CLI to save plugin authors from having to duplicate efforts.

Use of shared components should contribute to the consistency of interactions and interfaces across the plugins such that the Tanzu CLI feels more unified.

This feature request is intended to capture a rough idea and to be the start of an open discussion and with the implementation being a result of discussion.

The overall goal is, as much as possible, to have a library of shared components for common interactions/routines.

timestamp format component

Might there be a common mechanism to be used by all plugins when timestamps need to be displayed in output?

The styleguide calls for ISO 8601 standard for date and time

• compact
• consistent width
• app/server's timezone

See the Time Format section of the style guide

Describe alternatives you've considered

Affected product area (please put an X in all that apply)

[ ] APIs
[ ] Addons
[x] CLI
[ ] Docs
[ ] Installation
[x] Plugin
[ ] Security
[ ] Test and Release
[x] User Experience

Additional context

Cluster plugin is in need of CLI tests

Collated Context

Context from 2021-01-29 17:49:09
User: timothysc
This is mostly testing the porcelain.

Describe the feature request
Add support to the core cli that enables extension discovery, deployment, and life cycle management.

An extension plugin could act as the client-side interaction for our new Carvel-based APIs.

The TCE repository hosts a POC of this experience that is driven by naive metadata we host. However, this plugin could easily be mutated overtime to take on the new Carvel APIs and eventually become the way we interact client-side with packages.

Affected product area (please put an X in all that apply)

• APIs
• Addons
• CLI
• Docs
• Installation
• Plugin
• Security
• Test and Release
• User Experience

Additional context

Describe the feature request
What should tanzu version output? currently it is the version of TKG, but Tanzu is more than just TKG

Affected product area (please put an X in all that apply)

[ ] APIs
[x] CLI
[ ] Docs
[ ] Installation
[ ] Plugin
[ ] Security
[x] Test and Release
[ ] User Experience

Additional context

Collated Context

Context from 2021-02-05 17:19:00
User: frapposelli
Distilled feedback for Tanzu versioning in general, this is the result of long conversations with customers and field.

• In general, having 1:1 mapping between Kubernetes version and Product version is a good thing but not strictly required
• Having minor versions of Tanzu mapping to minor versions of Kubernetes (e.g. Tanzu 1.3.0 maps to Kubernetes 1.20.0, Tanzu 1.4.0 maps to Kubernetes 1.21.0) is extremely desirable
• Completely disjointed versioning between Tanzu and Kubernetes versions (e.g. Tanzu 0.0.1 maps to Kubernetes 1.20.0) is extremely discouraged.

Context from 2021-02-22 20:22:52
User: jorgemoralespou
I would probably do the opposite that @frapposelli suggests. I would definitely have the short version as the default, as that's the binary we're going to be pulling down and have the plugins version as an extended list with tanzu version --all (or similar) but have less fields shown (no description and no repository).
I would expect the plugin list to provide the long verbose list with details.

A user looking for versions would use the version command. A user looking for plugins details would use the plugin command.

Context from 2021-03-12 17:27:37
User: timothysc
+1 to @jorgemoralespou to both

$ tanzu version
$ tanzu version --all

Context from 2021-05-26 18:04:13
User: vuil

Distilled feedback for Tanzu versioning in general, this is the result of long conversations with customers and field.

• In general, having 1:1 mapping between Kubernetes version and Product version is a good thing but not strictly required
• Having minor versions of Tanzu mapping to minor versions of Kubernetes (e.g. Tanzu 1.3.0 maps to Kubernetes 1.20.0, Tanzu 1.4.0 maps to Kubernetes 1.21.0) is extremely desirable
• Completely disjointed versioning between Tanzu and Kubernetes versions (e.g. Tanzu 0.0.1 maps to Kubernetes 1.20.0) is extremely discouraged.

Given that a version of the CLI was shipped with "tanzu version" returning v1.3.0,
do we have plans to deviate from this convention for Dakar and other releases?

I recall there were also some discussion about some kind of edition information as part of the version output. That would give the freedom to evolve the tanzu cli version independently while still having a good indication of which release edition it was for.

(This is used to request new product features)

Describe the feature request
Use base manifests from https://github.com/kubernetes/cloud-provider-vsphere/tree/release-1.18/manifests/controller-manager instead of CAPV

Affected product area (please put an X in all that apply)

[ ] APIs
[*] Addons
[ ] CLI
[ ] Docs
[ ] Installation
[ ] Plugin
[ ] Security
[ ] Test and Release
[ ] User Experience

Additional context

We should provide a getting-started style step-by-step walkthrough day 0 of the developer experience:

• Create a repo
• Create a new API+Feature
• Create a CLI plugin
• Create a second feature via the CLI plugin
• Hack on the API functionality
• Deploy for dev
• Test locally
• Package, push to your repository

List of scenarios that have any relation to Carvel Packaging, status and links to their tracking.
This list is currently not prioritized/ordered in any specific way.

Carvel's Package MVP API tracking issue

Use cases

• #434

• #433

• #432

• #431

• #430

• #429

• #428

• #427

• #426

• #425

• #424

• #423

• #422

• #421

• #420

• #419

• #418

• #417

• #416

• #415

• #414

• #413

• #412

• #411

• #410

• #409

• #408

• #407

• #406

• #405

• #404

• #403

• #402

• #401

• #394

• #1700

Describe the feature request

Following on capability discovery package pkg/v1/discovery, a Capability CRD and controller needs to be created for cluster discovery using custom resources.

The CRD spec should take in query types supported by the discovery package and store results in the status after reconciliation.

Describe alternatives you've considered

Affected product area (please put an X in all that apply)

• APIs
• Addons
• CLI
• Docs
• Installation
• Plugin
• Security
• Test and Release
• User Experience

Additional context

Should implement (wrap) a common logger for the platform

Collated Context

Context from 2021-02-19 23:33:57
User: heyjcollins
does this mean that when a user submits tanzu [command] -v or tanzu [command] --verbose, they'll get ALL the back and forth between client and server dumped into the output?

Context from 2021-02-19 23:34:23
User: heyjcollins
can we use -v or --verbose to trigger that please?

Context from 2021-03-23 14:31:11
User: pbarker
K8s is moving to all structured logging https://github.com/kubernetes/kubernetes/pull/100320/files

Bug Report

Deployed a dev workload cluster on vSphere - 1 control plane, 1 worker node.
Scaled worker nodes from 1 to 3. Success!
Scaled control plane nodes from 1 to 3. Failure!

What I observed was as follows:

• Second control plane node is successfully cloned, powered on and receives an IP address successfully via DHCP.
• Original control plane node seems to lose its network information (both VM IP and VIP for K8s API server) - observed in in vSphere client UI
• K8s API server no longer reachable via kubectl commands
• CPU Usage on original control plane node/VM triggers vSphere alarm (4.774GHz Used)

Switched to management cluster to look at some logs:

% kubectl logs capi-kubeadm-control-plane-controller-manager-5596569b-q6rxz -n capi-kubeadm-control-plane-system manager
I0705 08:24:34.446929       1 controller.go:355] controllers/KubeadmControlPlane "msg"="Scaling up control plane" "cluster"="workload" "kubeadmControlPlane"="workload-control-plane" "namespace"="default" "Desired"=3 "Existing"=1
I0705 08:24:34.923501       1 controller.go:244] controllers/KubeadmControlPlane "msg"="Reconcile KubeadmControlPlane" "cluster"="workload" "kubeadmControlPlane"="workload-control-plane" "namespace"="default"
I0705 08:24:35.396995       1 controller.go:355] controllers/KubeadmControlPlane "msg"="Scaling up control plane" "cluster"="workload" "kubeadmControlPlane"="workload-control-plane" "namespace"="default" "Desired"=3 "Existing"=2
I0705 08:24:35.399412       1 scale.go:206] controllers/KubeadmControlPlane "msg"="Waiting for control plane to pass preflight checks" "cluster"="workload" "kubeadmControlPlane"="workload-control-plane" "namespace"="default" "failures"="[machine workload-control-plane-gpgp6 does not have APIServerPodHealthy condition, machine workload-control-plane-gpgp6 does not have ControllerManagerPodHealthy condition, machine workload-control-plane-gpgp6 does not have SchedulerPodHealthy condition, machine workload-control-plane-gpgp6 does not have EtcdPodHealthy condition, machine workload-control-plane-gpgp6 does not have EtcdMemberHealthy condition]"
.
.
.
I0705 08:26:26.708159       1 controller.go:244] controllers/KubeadmControlPlane "msg"="Reconcile KubeadmControlPlane" "cluster"="workload" "kubeadmControlPlane"="workload-control-plane" "namespace"="default"
I0705 08:27:27.066038       1 controller.go:355] controllers/KubeadmControlPlane "msg"="Scaling up control plane" "cluster"="workload" "kubeadmControlPlane"="workload-control-plane" "namespace"="default" "Desired"=3 "Existing"=2
I0705 08:27:27.066330       1 scale.go:206] controllers/KubeadmControlPlane "msg"="Waiting for control plane to pass preflight checks" "cluster"="workload" "kubeadmControlPlane"="workload-control-plane" "namespace"="default" "failures"="[machine workload-control-plane-kvj7j reports APIServerPodHealthy condition is unknown (Failed to get the node which is hosting this component), machine workload-control-plane-kvj7j reports ControllerManagerPodHealthy condition is unknown (Failed to get the node which is hosting this component), machine workload-control-plane-kvj7j reports SchedulerPodHealthy condition is unknown (Failed to get the node which is hosting this component), machine workload-control-plane-kvj7j reports EtcdPodHealthy condition is unknown (Failed to get the node which is hosting this component), machine workload-control-plane-kvj7j reports EtcdMemberHealthy condition is unknown (Failed to get the node which is hosting the etcd member), machine workload-control-plane-gpgp6 reports APIServerPodHealthy condition is unknown (Failed to get the node which is hosting this component), machine workload-control-plane-gpgp6 reports ControllerManagerPodHealthy condition is unknown (Failed to get the node which is hosting this component), machine workload-control-plane-gpgp6 reports SchedulerPodHealthy condition is unknown (Failed to get the node which is hosting this component), machine workload-control-plane-gpgp6 reports EtcdPodHealthy condition is unknown (Failed to get the node which is hosting this component), machine workload-control-plane-gpgp6 reports EtcdMemberHealthy condition is unknown (Failed to get the node which is hosting the etcd member)]"
I0705 08:27:42.486017       1 controller.go:244] controllers/KubeadmControlPlane "msg"="Reconcile KubeadmControlPlane" "cluster"="vcsa06-octoc" "kubeadmControlPlane"="vcsa06-octoc-control-plane" "namespace"="tkg-system"
I0705 08:27:57.078706       1 controller.go:182] controllers/KubeadmControlPlane "msg"="Could not connect to workload cluster to fetch status" "cluster"="workload" "kubeadmControlPlane"="workload-control-plane" "namespace"="default" "err"="failed to create remote cluster client: default/workload: Get https://10.27.51.243:6443/api?timeout=30s: context deadline exceeded"
I0705 08:27:57.117486       1 controller.go:244] controllers/KubeadmControlPlane "msg"="Reconcile KubeadmControlPlane" "cluster"="workload" "kubeadmControlPlane"="workload-control-plane" "namespace"="default"
I0705 08:28:57.168628       1 controller.go:182] controllers/KubeadmControlPlane "msg"="Could not connect to workload cluster to fetch status" "cluster"="workload" "kubeadmControlPlane"="workload-control-plane" "namespace"="default" "err"="failed to create remote cluster client: default/workload: Get https://10.27.51.243:6443/api?timeout=30s: context deadline exceeded"
E0705 08:28:57.187424       1 controller.go:257] controller-runtime/controller "msg"="Reconciler error" "error"="cannot get remote client to workload cluster: default/workload: Get https://10.27.51.243:6443/api?timeout=30s: context deadline exceeded (Client.Timeout exceeded while awaiting headers)" "controller"="kubeadmcontrolplane" "name"="workload-control-plane" "namespace"="default"
I0705 08:28:57.188000       1 controller.go:244] controllers/KubeadmControlPlane "msg"="Reconcile KubeadmControlPlane" "cluster"="workload" "kubeadmControlPlane"="workload-control-plane" "namespace"="default"
I0705 08:29:57.225857       1 controller.go:182] controllers/KubeadmControlPlane "msg"="Could not connect to workload cluster to fetch status" "cluster"="workload" "kubeadmControlPlane"="workload-control-plane" "namespace"="default" "err"="failed to create remote cluster client: default/workload: Get https://10.27.51.243:6443/api?timeout=30s: context deadline exceeded (Client.Timeout exceeded while awaiting headers)"
E0705 08:29:57.227366       1 controller.go:257] controller-runtime/controller "msg"="Reconciler error" "error"="cannot get remote client to workload cluster: default/workload: Get https://10.27.51.243:6443/api?timeout=30s: context deadline exceeded" "controller"="kubeadmcontrolplane" "name"="workload-control-plane" "namespace"="default"
I0705 08:29:57.227913       1 controller.go:244] controllers/KubeadmControlPlane "msg"="Reconcile KubeadmControlPlane" "cluster"="workload" "kubeadmControlPlane"="workload-control-plane" "namespace"="default"
I0705 08:30:52.225222       1 controller.go:244] controllers/KubeadmControlPlane "msg"="Reconcile KubeadmControlPlane" "cluster"="vcsa06-octoc" "kubeadmControlPlane"="vcsa06-octoc-control-plane" "namespace"="tkg-system"
I0705 08:30:57.267482       1 controller.go:182] controllers/KubeadmControlPlane "msg"="Could not connect to workload cluster to fetch status" "cluster"="workload" "kubeadmControlPlane"="workload-control-plane" "namespace"="default" "err"="failed to create remote cluster client: default/workload: Get https://10.27.51.243:6443/api?timeout=30s: context deadline exceeded"
E0705 08:30:57.268704       1 controller.go:257] controller-runtime/controller "msg"="Reconciler error" "error"="cannot get remote client to workload cluster: default/workload: Get https://10.27.51.243:6443/api?timeout=30s: net/http: request canceled (Client.Timeout exceeded while awaiting headers)" "controller"="kubeadmcontrolplane" "name"="workload-control-plane" "namespace"="default"
I0705 08:30:57.269114       1 controller.go:244] controllers/KubeadmControlPlane "msg"="Reconcile KubeadmControlPlane" "cluster"="workload" "kubeadmControlPlane"="workload-control-plane" "namespace"="default"

% kubectl logs capi-kubeadm-control-plane-controller-manager-5596569b-q6rxz -n capi-kubeadm-control-plane-system manager
I0705 08:21:35.975933       1 controller.go:244] controllers/KubeadmControlPlane "msg"="Reconcile KubeadmControlPlane" "cluster"="vcsa06-octoc" "kubeadmControlPlane"="vcsa06-octoc-control-plane" "namespace"="tkg-system"
I0705 08:24:33.802071       1 controller.go:244] controllers/KubeadmControlPlane "msg"="Reconcile KubeadmControlPlane" "cluster"="workload" "kubeadmControlPlane"="workload-control-plane" "namespace"="default"
I0705 08:24:34.446929       1 controller.go:355] controllers/KubeadmControlPlane "msg"="Scaling up control plane" "cluster"="workload" "kubeadmControlPlane"="workload-control-plane" "namespace"="default" "Desired"=3 "Existing"=1
I0705 08:24:34.923501       1 controller.go:244] controllers/KubeadmControlPlane "msg"="Reconcile KubeadmControlPlane" "cluster"="workload" "kubeadmControlPlane"="workload-control-plane" "namespace"="default"
I0705 08:24:35.396995       1 controller.go:355] controllers/KubeadmControlPlane "msg"="Scaling up control plane" "cluster"="workload" "kubeadmControlPlane"="workload-control-plane" "namespace"="default" "Desired"=3 "Existing"=2
I0705 08:24:35.399412       1 scale.go:206] controllers/KubeadmControlPlane "msg"="Waiting for control plane to pass preflight checks" "cluster"="workload" "kubeadmControlPlane"="workload-control-plane" "namespace"="default" "failures"="[machine workload-control-plane-gpgp6 does not have APIServerPodHealthy condition, machine workload-control-plane-gpgp6 does not have ControllerManagerPodHealthy condition, machine workload-control-plane-gpgp6 does not have SchedulerPodHealthy condition, machine workload-control-plane-gpgp6 does not have EtcdPodHealthy condition, machine workload-control-plane-gpgp6 does not have EtcdMemberHealthy condition]"
.
.
.
I0705 08:26:26.708159       1 controller.go:244] controllers/KubeadmControlPlane "msg"="Reconcile KubeadmControlPlane" "cluster"="workload" "kubeadmControlPlane"="workload-control-plane" "namespace"="default"
I0705 08:27:27.066038       1 controller.go:355] controllers/KubeadmControlPlane "msg"="Scaling up control plane" "cluster"="workload" "kubeadmControlPlane"="workload-control-plane" "namespace"="default" "Desired"=3 "Existing"=2
I0705 08:27:27.066330       1 scale.go:206] controllers/KubeadmControlPlane "msg"="Waiting for control plane to pass preflight checks" "cluster"="workload" "kubeadmControlPlane"="workload-control-plane" "namespace"="default" "failures"="[machine workload-control-plane-kvj7j reports APIServerPodHealthy condition is unknown (Failed to get the node which is hosting this component), machine workload-control-plane-kvj7j reports ControllerManagerPodHealthy condition is unknown (Failed to get the node which is hosting this component), machine workload-control-plane-kvj7j reports SchedulerPodHealthy condition is unknown (Failed to get the node which is hosting this component), machine workload-control-plane-kvj7j reports EtcdPodHealthy condition is unknown (Failed to get the node which is hosting this component), machine workload-control-plane-kvj7j reports EtcdMemberHealthy condition is unknown (Failed to get the node which is hosting the etcd member), machine workload-control-plane-gpgp6 reports APIServerPodHealthy condition is unknown (Failed to get the node which is hosting this component), machine workload-control-plane-gpgp6 reports ControllerManagerPodHealthy condition is unknown (Failed to get the node which is hosting this component), machine workload-control-plane-gpgp6 reports SchedulerPodHealthy condition is unknown (Failed to get the node which is hosting this component), machine workload-control-plane-gpgp6 reports EtcdPodHealthy condition is unknown (Failed to get the node which is hosting this component), machine workload-control-plane-gpgp6 reports EtcdMemberHealthy condition is unknown (Failed to get the node which is hosting the etcd member)]"
I0705 08:27:42.486017       1 controller.go:244] controllers/KubeadmControlPlane "msg"="Reconcile KubeadmControlPlane" "cluster"="vcsa06-octoc" "kubeadmControlPlane"="vcsa06-octoc-control-plane" "namespace"="tkg-system"
I0705 08:27:57.078706       1 controller.go:182] controllers/KubeadmControlPlane "msg"="Could not connect to workload cluster to fetch status" "cluster"="workload" "kubeadmControlPlane"="workload-control-plane" "namespace"="default" "err"="failed to create remote cluster client: default/workload: Get https://10.27.51.243:6443/api?timeout=30s: context deadline exceeded"
I0705 08:27:57.117486       1 controller.go:244] controllers/KubeadmControlPlane "msg"="Reconcile KubeadmControlPlane" "cluster"="workload" "kubeadmControlPlane"="workload-control-plane" "namespace"="default"
I0705 08:28:57.168628       1 controller.go:182] controllers/KubeadmControlPlane "msg"="Could not connect to workload cluster to fetch status" "cluster"="workload" "kubeadmControlPlane"="workload-control-plane" "namespace"="default" "err"="failed to create remote cluster client: default/workload: Get https://10.27.51.243:6443/api?timeout=30s: context deadline exceeded"
E0705 08:28:57.187424       1 controller.go:257] controller-runtime/controller "msg"="Reconciler error" "error"="cannot get remote client to workload cluster: default/workload: Get https://10.27.51.243:6443/api?timeout=30s: context deadline exceeded (Client.Timeout exceeded while awaiting headers)" "controller"="kubeadmcontrolplane" "name"="workload-control-plane" "namespace"="default"

To try and regain access to the cluster, I reset (via the vSphere client) the original control plane node/VM. This allowed the node to regain its networking configuration and I could once again access the API server after it rebooted and I waited a few minutes.

However the control plane is still not reconciled:

% kubectl get nodes -o wide
NAME                            STATUS     ROLES                  AGE     VERSION            INTERNAL-IP   EXTERNAL-IP   OS-IMAGE                 KERNEL-VERSION   CONTAINER-RUNTIME
workload-control-plane-gpgp6    NotReady   <none>                 38m     v1.20.4+vmware.1   10.27.51.25   10.27.51.25   VMware Photon OS/Linux   4.19.174-5.ph3   containerd://1.4.3
workload-control-plane-kvj7j    Ready      control-plane,master   2d20h   v1.20.4+vmware.1   10.27.51.61   10.27.51.61   VMware Photon OS/Linux   4.19.174-5.ph3   containerd://1.4.3
workload-md-0-984748884-g5884   Ready      <none>                 2d20h   v1.20.4+vmware.1   10.27.51.63   10.27.51.63   VMware Photon OS/Linux   4.19.174-5.ph3   containerd://1.4.3
workload-md-0-984748884-jtg7q   Ready      <none>                 2d20h   v1.20.4+vmware.1   10.27.51.64   10.27.51.64   VMware Photon OS/Linux   4.19.174-5.ph3   containerd://1.4.3
workload-md-0-984748884-pvlnq   Ready      <none>                 2d20h   v1.20.4+vmware.1   10.27.51.62   10.27.51.62   VMware Photon OS/Linux   4.19.174-5.ph3   containerd://1.4.3

And the kubelet status on the new node seems to have an issue with the CSI driver, but I cannot tell if this is the root cause:

% ssh [email protected]
Last login: Mon Jul  5 08:44:34 2021 from 10.30.3.96
 08:52:54 up 27 min,  0 users,  load average: 0.30, 0.34, 0.19
tdnf update info not available yet!
capv@workload-control-plane-gpgp6 [ ~ ]$ sudo su -
root@workload-control-plane-gpgp6 [ ~ ]# systemctl status kubelet
● kubelet.service - kubelet: The Kubernetes Node Agent
   Loaded: loaded (/lib/systemd/system/kubelet.service; enabled; vendor preset: enabled)
  Drop-In: /usr/lib/systemd/system/kubelet.service.d
           └─10-kubeadm.conf
   Active: active (running) since Mon 2021-07-05 08:28:52 UTC; 24min ago
     Docs: https://kubernetes.io/docs/home/
 Main PID: 2941 (kubelet)
    Tasks: 16 (limit: 4714)
   Memory: 46.1M
   CGroup: /system.slice/kubelet.service
           └─2941 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubelet/config.yaml --cloud-provider=external --container-runtime=remote --container-runtime-endpoint=/var/run/containerd/containerd.sock --tls-ciphe
r-suites=TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 --pod-infra-container-image=projects.registry.vmware.com/tkg/paus
e:3.2

Jul 05 08:50:26 workload-control-plane-gpgp6 kubelet[2941]: I0705 08:50:26.152310    2941 passthrough.go:48] ccResolverWrapper: sending update to cc: {[{/var/lib/kubelet/plugins_registry/csi.vsphere.vmware.com-reg.sock  <nil> 0 <nil>}] <nil> <nil>}
Jul 05 08:50:26 workload-control-plane-gpgp6 kubelet[2941]: I0705 08:50:26.152321    2941 clientconn.go:948] ClientConn switching balancer to "pick_first"
Jul 05 08:50:26 workload-control-plane-gpgp6 kubelet[2941]: I0705 08:50:26.153041    2941 csi_plugin.go:100] kubernetes.io/csi: Trying to validate a new CSI Driver with name: csi.vsphere.vmware.com endpoint: /var/lib/kubelet/plugins/csi.vsphere.vmware.com/csi.sock versions: 1.0.0
Jul 05 08:50:26 workload-control-plane-gpgp6 kubelet[2941]: I0705 08:50:26.153070    2941 csi_plugin.go:113] kubernetes.io/csi: Register new plugin with name: csi.vsphere.vmware.com at endpoint: /var/lib/kubelet/plugins/csi.vsphere.vmware.com/csi.sock
Jul 05 08:50:26 workload-control-plane-gpgp6 kubelet[2941]: I0705 08:50:26.153104    2941 clientconn.go:106] parsed scheme: ""
Jul 05 08:50:26 workload-control-plane-gpgp6 kubelet[2941]: I0705 08:50:26.153113    2941 clientconn.go:106] scheme "" not registered, fallback to default scheme
Jul 05 08:50:26 workload-control-plane-gpgp6 kubelet[2941]: I0705 08:50:26.153146    2941 passthrough.go:48] ccResolverWrapper: sending update to cc: {[{/var/lib/kubelet/plugins/csi.vsphere.vmware.com/csi.sock  <nil> 0 <nil>}] <nil> <nil>}
Jul 05 08:50:26 workload-control-plane-gpgp6 kubelet[2941]: I0705 08:50:26.153154    2941 clientconn.go:948] ClientConn switching balancer to "pick_first"
Jul 05 08:50:26 workload-control-plane-gpgp6 kubelet[2941]: I0705 08:50:26.153185    2941 clientconn.go:897] blockingPicker: the picked transport is not ready, loop back to repick
Jul 05 08:50:31 workload-control-plane-gpgp6 kubelet[2941]: E0705 08:50:31.970708    2941 nodeinfomanager.go:574] Invalid attach limit value 0 cannot be added to CSINode object for "csi.vsphere.vmware.com"

I have managed to repeat this scenario twice with 2 different TKG clusters on vSphere.

Expected Behavior

That the control plane would scale seamlessly.

Steps to Reproduce the Bug

1. Deploy a single control plane dev workload cluster
2. Attempt to scale the control plane to 3 nodes

Environment Details

• TCE version

v0.5.0

• tanzu version

version: v1.3.0
buildDate: 2021-06-03
sha: b261a8b

• kubectl version

Client Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.1", GitCommit:"c4d752765b3bbac2237bf87cf0b1c2e307844666", GitTreeState:"clean", BuildDate:"2020-12-18T12:09:25Z", GoVersion:"go1.15.5", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.4+vmware.1", GitCommit:"d475bbd9e7cd66c6db7069cb447766daada65e3b", GitTreeState:"clean", BuildDate:"2021-02-22T22:15:46Z", GoVersion:"go1.15.8", Compiler:"gc", Platform:"linux/amd64"}

• Operating System (client):
  macOS Big Sur version 11.4

We should add docs that cover developer documentation, such as how to develop, test and release addons.

Repo should have a changelog

Collated Context

Context from 2021-01-22 22:38:20
User: pbarker
this can be done with go-releaser

Context from 2021-01-29 17:40:51
User: timothysc
TODO: Add TCE Label

To enable PRs from forks, workflows have to be configured to run on forks, but in a way where no secrets are passed from the main repository. The following tasks are being tracked.

• Lock down actions to run without passing secrets to fork repos
• Verify that release-* workflows does not work as a result
• Refactor workflows so that only unprivileged steps are run
• Move steps requiring repo secrets to run in the context of the main repo, trigger on workflow_run event instead

Collated Context

Context from 2021-06-23 18:57:05
User: vuil
keep passing fork secrets DISABLED is fine.
I reenabled write access so CI pipelines can post updates to the PR conversation to unblock existing PRs. Will address this when we retest these pipelines in the new org (some actions behave differently when the main repo is public vs private).
Assigning this to myself.

Context from 2021-06-23 21:31:05
User: vuil
Turns out we needs to pass secrets as well. (I just enabled it).
It should not be necessary once the repo is public, so this is something we should address at the vmware-tanzu repo instead.

Describe the feature request

This is one in a series of proposed components that cover common interactions/needs in the CLI to save plugin authors from having to duplicate efforts.

Use of shared components should contribute to the consistency of interactions and interfaces across the plugins such that the Tanzu CLI feels more unified.

This feature request is intended to capture a rough idea and to be the start of an open discussion and with the implementation being a result of discussion.

The overall goal is, as much as possible, to have a library of shared components for common interactions/routines.

Command context component

Might there be a common mechanism that could be used by all plugins to read/check/set context (ie what cluster, namespace, workspace, etc) is currently targeted?

• used by plugins to CRUD the current context
  This could be used by plugins to CRUD the current context.

Describe alternatives you've considered

Affected product area (please put an X in all that apply)

[ ] APIs
[ ] Addons
[x] CLI
[ ] Docs
[ ] Installation
[x] Plugin
[ ] Security
[ ] Test and Release
[x] User Experience

Additional context

Define requirements for CLI test coverage and how do we enforce that?

This goes into how we test Tanzu as a whole. Do we use the SDK tests? should the SDK tests be exported and also executable from the CLI? What is the coverage amount expected?

Collated Context

Context from 2021-03-02 18:36:42
User: pbarker
We should engage the test team on this

Provide a switch command for login that allows you to reuse an existing server without providing a new token

Describe the feature request

With the Tanzu CLIs scope increasing to cover app-dev and app-operator concerns in addition to platform operator concerns, the current command groups (system, manage, and run) are sub-optimal.

For example, in a relatively near future, the manage command group would contain a heterogeneous set of commands, some focused on platform management, some application management.

Additionally, there will likely be many app-focused commands which may fall into both the manage or run group depending on what action is being taken.

We're proposing a change to the group names...

as follows: Platform, Apps, System, and Installed plugin commands.

Describe alternatives you've considered

Affected product area (please put an X in all that apply)

[ ] APIs
[ ] Addons
[X] CLI
[X] Docs
[ ] Installation
[X] Plugin
[ ] Security
[ ] Test and Release
[X] User Experience

Additional context

Collated Context

Context from 2021-03-26 16:43:25
User: ashtynlynne
This kind of reminds me of some questions we had on the TMC UI when we started supporting the App Developer persona (dev console integration). We tried to figure out if there's a good way to logically group the left navigation items based on App Developer vs Platform Operator vs etc. You could sync up with Alister (UX) about their thoughts - we found there was actually a lot of overlap with some items that don't fit cleanly into one persona or the other I think?

Context from 2021-05-13 21:18:36
User: heyjcollins
Any chance this change could be pulled in. We're getting ready to implement the first dev app-ops focused commands and would like to put them into the new grouping structure proposed here.
@danfein

Seems like it exists for kubebuilder and does not serve any purpose currently. Investigate what go get github.com/vmware-tanzu/tanzu-frameowkr should do.

cc @pbarker

Collated Context

Context from 2021-01-22 21:47:39
User: timothysc
The question is: what is the common expectation of what go get of this repo should produce? I would expect it to produce the CLI

Describe the feature request
On first run of tanzu CLI you get an Initializing message and it the initialization process might take up to some minutes, as it pulls down plugins from remote repositories. Since a user might not know what's going on, it would be ideal to provide better feedback to the user.

Describe alternatives you've considered
Provide a message like Initializing. Core plugins are being downloaded (this might take some time)

Affected product area (please put an X in all that apply)

[ ] APIs
[ ] Addons
[* ] CLI
[ ] Docs
[ ] Installation
[ ] Plugin
[ ] Security
[ ] Test and Release
[*] User Experience

Additional context

(This is used to request new product features)

Describe the feature request
Currently, when cluster is deployed with core addons there isnt a status/condition in the cluster to look at for successful installation of these addons. Adding cluster conditions is useful for tanzu cli to scrap the status, wait for all addons installation to be completed and error out if any addons fail to be deployed

Describe alternatives you've considered
Look at App CR status directly. This is cumbersome and for core addons, status should be in cluster object

Affected product area (please put an X in all that apply)

[ ] APIs
[x] Addons
[ ] CLI
[ ] Docs
[ ] Installation
[ ] Plugin
[ ] Security
[ ] Test and Release
[ ] User Experience

Additional context

Collated Context

Context from 2021-03-02 15:58:00
User: vijaykatam
As part of this change, we will need to ensure to do some scale testing to analyze memory requirements and potential leaks for the pod.

Describe the feature request

Currently, the process for installing the CLI is a little cumbersome. Consumers can work around this, but that's not ideal.

It would be better to distribute the core of the CLI through package managers (including support for things like homebrew, rpm, and deb).

Especially when combined with #2, this seems to allow for a much smoother user experience: install the CLI, login to a cluster, everything auto-magically appears.

Describe alternatives you've considered

One alternative would be to have a standard install.sh-style pattern that all consumers can rely on.

Affected product area (please put an X in all that apply)

• APIs
• Addons
• CLI
• Docs
• Installation
• Plugin
• Security
• Test and Release
• User Experience

Additional context

Bug description

When deploying a CAPD management cluster through TCE, I encountered the following error message in my logs "Failed to start CEIP telemetry job on management cluster".

Affected product area (please put an X in all that apply)

• APIs
• Addons
• CLI
• Docs
• Installation
• Plugin
• Security
• Test and Release
• User Experience

Expected behavior

As a user, I would not expect to see error messages in my logs when creating a management cluster.

Steps to reproduce the bug

1. Run tanzu management-cluster create --ui
2. Select Docker
3. Deploy with default settings

Version (include the SHA if the version is not obvious)

TCE v0.6.0-rc1

Environment where the bug was observed (cloud, OS, etc)

CAPD

Relevant Debug Output (Logs, manifests, etc)

✘ [0630 09:30:40.57152]: init.go:292] Failed to start CEIP telemetry job on management cluster: failed to parse telemetry spec yaml: open pkg/manifest/telemetry/config-docker.yaml: file does not exist
‼ [0630 09:30:40.57156]: init.go:294] To have this cluster participate in VMware CEIP:
‼ [0630 09:30:40.57178]: init.go:295] tanzu management-cluster ceip-participation set true

Starting in the next cycle we will need to tie in imgpkg as the primary build artifact that ties together the components which are part of the hub.

This will cascade into TCE consumption.

cc @pbarker @cppforlife @joshrosso

Collated Context

Context from 2021-03-13 19:34:07
User: pbarker
I'm working on some integrations with Tanzu for the performance team, I'm looking at imgpkg for the release, but I've run into an issue:

If I want to put the CLI plugin in the imgpkg, it is OS specific.

There are a couple paths here:
a. Have an imgpkg per host OS arch type
b. Put all arch builds in the imgpkg
c. Have conditional dependencies for imgpkg
d. Include Go in the imgpkg and build from source adhoc on the host OS
e. Not include the CLI binaries and simply have them sourced elsewhere (may be challenging for airgapping)

Option A seems the most sane, but also comes with a fair amount of overhead

Curious about thoughts!

Context from 2021-03-18 17:54:59
User: cppforlife
this issue is probably relevant as well: carvel-dev/imgpkg#93

Our Dockerfile should support multi-arch, aligned with TCE

Collated Context

Context from 2021-01-22 21:44:26
User: timothysc
@dvonthenen - what target platforms do we want to support for TCE?

Context from 2021-01-28 16:25:53
User: dvonthenen
Having some discussions around this... will follow up with a reply shortly

Context from 2021-02-05 17:26:08
User: dvonthenen
For TCE, we would need to support for the following:
windows amd64
linux amd64
darwin amd64

cc: @joshrosso

Review the design of the login plugin

Collated Context

Context from 2021-01-29 17:51:04
User: timothysc
At minimum we should have a plan in place.

Context from 2021-02-17 15:28:45
User: mattmoyer
Some issues to consider in this design:

• How do we bootstrap trust into a management cluster where I don't have the self-signed CA bundle yet? This is very similar to the boostrapping problem in kubeadm join, and I think we could use a similar approach to kubeadm

• How do we express "login to SaaS" and "login to TKG" in the least confusing way? Can we unify the "login to SaaS" flow across multiple CSP-based services (TMC + TSM)?

I'm sure there are a bunch more things to consider, this is just some rough notes after discussions yesterday.

What does it mean for components to rely on the same git tag for versioning?
@zjs mentioned an example where we need to rev a minor of component A and component B has only been bumping at a patch level.

Collated Context

Context from 2021-01-29 17:42:40
User: timothysc
TODO: Documentation on release mgmt.

Context from 2021-02-03 07:28:01
User: vuil
Not sure about all components, but in a recent discussion with @pbarker @iancoffey @figo , at least for plugins, for certain more significant releases, it may make sense for all plugins' version to be the same as the git tag for said release. That said, in between these releases, should there be a need to rev a specific plugin, we can employ semver suffixes judiciously

v1.2.3 -> v1.2.3-xyz.1 -> v1.2.3-xyz.2 ....-> until the next major/minor/patch bump. (like v1.2.4, v1.3.0 etc)

IOW each plugin can still have their own independent update schedule provided it adheres to the prescribed versioning conventions.

Bug description

The output of tanzu management-cluster kubeconfig get ${MGMT_CLUSTER_NAME} --admin includes the text "Credentials of workload cluster".

Affected product area (please put an X in all that apply)

• APIs
• Addons
• CLI
• Docs
• Installation
• Plugin
• Security
• Test and Release
• User Experience

Expected behavior

When getting the credentials for a management cluster, I'd expect the output to say management cluster. (Alternatively, the output could just always say "cluster", without "management" or "workload".)

Steps to reproduce the bug

1. Create a management cluster
2. Run tanzu management-cluster kubeconfig get ${MGMT_CLUSTER_NAME} --admin

Version (include the SHA if the version is not obvious)

TCE v0.6.0-rc1

Environment where the bug was observed (cloud, OS, etc)

CAPD

Relevant Debug Output (Logs, manifests, etc)

~/tce/tce-linux-amd64-v0.6.0-rc.1$ tanzu management-cluster kubeconfig get ${MGMT_CLUSTER_NAME} --admin
Credentials of workload cluster 'tkg-mgmt-docker-20210630092340' have been saved 
You can now access the cluster by running 'kubectl config use-context tkg-mgmt-docker-20210630092340-admin@tkg-mgmt-docker-20210630092340'

Describe the feature request
We have a need for different tiers of plugins. A first class plugin should have a highly consistent interface and be well integrated into the portfolio. 3rd party plugins would allow any user to add to the CLI without this need but wouldn't be installed by default.

Describe alternatives you've considered

Affected product area (please put an X in all that apply)

[ ] APIs
[x] CLI
[ ] Docs
[ ] Installation
[x] Plugin
[ ] Security
[ ] Test and Release
[ ] User Experience

Additional context

Bug description

Due to the calling of "init logic" in the RootCommand, if tanzu init is called the initialization logic will be called in the root command and then subsequently called in the init command.

Affected product area (please put an X in all that apply)

[ ] APIs
[ ] Addons
[ x ] CLI
[ ] Docs
[ ] Installation
[ ] Plugin
[ ] Security
[ ] Test and Release
[ x ] User Experience

Expected behavior

Initialization logic is only called once.

Steps to reproduce the bug

Add log statements into EnsureDistro, verify it is called twice.

Make all in root should invoke addons build

Collated Context

Context from 2021-01-29 17:39:08
User: timothysc
Once we have some release engineering folks I'd love for TCE to take ownership of stuff like this

Where should the admin plugins for the CLI live?

We need a process to sign the CLI

Bug description

When I load the Tanzu Community Edition installer, the following text is displayed:

For more details see the getting started guide. TODO: needs doc link

Affected product area (please put an X in all that apply)

• APIs
• Addons
• CLI
• Docs
• Installation
• Plugin
• Security
• Test and Release
• User Experience

Expected behavior

A link to the user guide is displayed.

Steps to reproduce the bug

Run tanzu management-cluster create --ui

Version (include the SHA if the version is not obvious)

TCE v0.6.0-rc1

Environment where the bug was observed (cloud, OS, etc)

N/A

Relevant Debug Output (Logs, manifests, etc)

Looks like the file in need of update is branding.constants.ts.

Describe the feature request

Today, plugin authors must vendor vmware-tanzu/tanzu-framework in order to make a compliant plugin. Namely, to use the PluginDescriptor as seen in this TCE plugin.

As part of importing this package, a plugin will be bound to multiple Kubernetes-related dependencies in core. This means, should a plugin author require a different version of client-go, they may run into serious issues or need to do serious workarounds to make it work.

Is there a model where vendoring of tanzu-framework could introduce minimal transitive dependencies to a plugin-project?

Describe alternatives you've considered

Alternatively, tanzu-framework could take a stance where plugin developer must be bound to the same Kubernetes-related dependencies as the plugins found in this repository.

Affected product area (please put an X in all that apply)

• APIs
• Addons
• CLI
• Docs
• Installation
• Plugin
• Security
• Test and Release
• User Experience

Additional context

Describe the feature request

The TCE getting started guide has the user run tanzu management-cluster get to print a bunch of information about the management cluster, and then copy & paste the management cluster name.

It'd be nice if the management-cluster plugin provided a flag for JSON output (like other plugins do) so that the user could do something a like export MGMT_CLUSTER_NAME=$(tanzu management-cluster get -o jsonpath={…}).

Describe alternatives you've considered

None — and there may be better ways to solve this!

Affected product area (please put an X in all that apply)

• APIs
• Addons
• CLI
• Docs
• Installation
• Plugin
• Security
• Test and Release
• User Experience

Additional context

Describe the feature request
Addons manager should wait for cluster-api, kapp-controller and tkr CRD's before starting to watch the resources.

Affected product area (please put an X in all that apply)

[ ] APIs
[x] Addons
[ ] CLI
[ ] Docs
[ ] Installation
[ ] Plugin
[ ] Security
[ ] Test and Release
[ ] User Experience

Additional context
By waiting, we prevent crash loop in management cluster initialization.

Should enable macos and windows CI to ensure cross platform compatibility.

Collated Comments

Context from 2021-01-15 17:47:49
User: timothysc
The main artifact we want to use is the imgpkg.

+needs signing.

We will likely need a couple of folks here.

Context from 2021-01-29 17:37:08
User: vuil
We are validating windows CLI builds, there are a couple of issues found. Once we address them in the next few days we should be able to turn on the windows CI runners.

Context from 2021-06-21 17:23:02
User: iancoffey
Is there any update here?

Describe the feature request
We should standardize what os architectures are supported for the CLI and larger project.

Collated Context

Context from 2021-02-05 17:24:12
User: mattmoyer
Another issue that might come into play here is dependence on native system libraries. This might happen, for example, if we integrate the session storage in the tanzu login command with system keychain on macOS. As far as I know, all the good ways to do this use CGO and prevent cross-compilation.

It shouldn't be a huge problem, but it might mean that if we want to ship macOS ARM binaries, we need an ARM macOS build machine.

Context from 2021-02-05 17:31:44
User: zjs

As far as I know, all the good ways to do this use CGO and prevent cross-compilation.

For tag builds, we can leverage the VMware build infrastructure. That should provide good coverage of architectures/platforms for natively compiled builds.

Context from 2021-02-26 13:14:42
User: iancoffey
I will start with proposing we implement this matrix, and gain feedback:

Bug description
When the user runs the tanzu login command in git-bash in Windows, it does not allow the user to make a selection

Affected product area (please put an X in all that apply)

[ ] APIs
[ ] Addons
[X] CLI
[ ] Docs
[ ] Installation
[X] Plugin
[ ] Security
[ ] Test and Release
[ ] User Experience

Expected behavior
The user should be allowed to use the arrow keys to navigate over different choices that are available when a user enters tanzu login

Steps to reproduce the bug

1. Open git-bash
2. Install the tanzu plugin
3. Run tanzu login

Version (include the SHA if the version is not obvious)
version: v1.3.0-rc.3

Environment where the bug was observed (cloud, OS, etc)
Windows 10

Relevant Debug Output (Logs, manifests, etc)

Further investigation

• We use a library called survey in Tanzu CLI to create an interface such as the one being used by the tanzu login plugin - https://github.com/AlecAivazis/survey
• There is a known issue in survey with it not working properly with git-bash - AlecAivazis/survey#148
• The workaround for this is to run alias tanzu='winpty -Xallow-non-tty tanzu' in git-bash before starting to use tanzu commands.

The ask here is to investigate if we can modify the functions being used to create the interface so we don't need to run the alias command before using tanzu plugins.

Note: This issue was seen only in git-bash and not in the command prompt.

What is the future of the SDK for Tanzu? Currently, it consists of controller dev, Feature dev, and capability development.

What should it evolve into in the future?

Describe the feature request
Need accessibility testing for the CLI

Describe alternatives you've considered

Affected product area (please put an X in all that apply)

[ ] APIs
[x] CLI
[ ] Docs
[ ] Installation
[ ] Plugin
[ ] Security
[ ] Test and Release
[ ] User Experience

Additional context

Collated Context

Context from 2021-01-29 17:11:15
User: pbarker
Bangalore team is currently working on this

Describe the feature request

We have a variety of ways to extend Tanzu. Currently, these work in independent ways. You can add a management package to the management cluster. You can add a plugin to the Tanzu CLI.

The independence between these things is important, and provides flexibility. It's good that these separate extensibility points exist.

However, it will be common that someone wanting to extend the management cluster will also want to introduce a corresponding CLI plugin. When the management package is installed, it would be useful to make that corresponding CLI plugin available to all users of a management cluster.

To address this, we can introduce an API on the management cluster (i.e., a new framework management package) that allows others (including other management packages) to register CLI plugins.

When the Tanzu CLI connects to the management cluster, it can use this API to determine if there are any additional plugins which should be installed, and proceed appropriately. (Exact UX needs to be defined.)

This architecture has added benefits.

For example, it may help with the situation where a user is working with multiple heterogeneous management clusters. Having the management cluster report what plugins are registered can allow the CLI to tailor its behavior to the cluster it's being used with.

This can also provide value in the case of environments with restricted connectivity. By maintaining this information within each management cluster, users of that management cluster can be instructed to get the plugin from the same container registry as the management package was retrieved from.

The main outputs of this work will include:

1. A core management package which defines and implements this new API
2. A core CLI plugin which acts as a client for this API
3. Tooling to help CLI plugin authors define the custom resource to register their plugin with a management cluster
4. Tooling to help management package authors leverage (3)

Key considerations will include:

1. User experience (including around associating discovery with the login/context-switching workflow)
2. Ensuring that the available set of plugins can be tailored to the endpoint (e.g., management cluster) being used, without leading to conflicts (e.g., if two endpoints expect different versions of a plugin)
3. Security (e.g., a signing pattern to ensure that the plugin we're downloading is what we expect as well as some client-side controls, such as allow-listing registrie.)

Describe alternatives you've considered

An alternative is to have a venv-like pattern. However, this would be much more cumbersome for new users.

Affected product area (please put an X in all that apply)

• APIs
• CLI
• Docs
• Installation
• Packages
• Plugin
• Security
• Test and Release
• User Experience

Additional context

Describe the feature request

This is one in a series of proposed components that cover common interactions/needs in the CLI to save plugin authors from having to duplicate efforts.

Use of shared components should contribute to the consistency of interactions and interfaces across the plugins such that the Tanzu CLI feels more unified.

This feature request is intended to capture a rough idea and to be the start of an open discussion and with the implementation being a result of discussion.

The overall goal is, as much as possible, to have a library of shared components for common interactions/routines.

Command error/warning component

Might there be a common mechanism that could be used by all plugins to output warnings and errors?

The styleguide calls for specific treatment of Error and Warning output both with regards to content and color:

• See Red = warning, danger portion of the Color section of the style guide

Describe alternatives you've considered

Affected product area (please put an X in all that apply)

[ ] APIs
[ ] Addons
[x] CLI
[ ] Docs
[ ] Installation
[x] Plugin
[ ] Security
[ ] Test and Release
[x] User Experience

Additional context

What is surfaced in the CLI by default? Is it just the package repository list your cluster has installed which determines edition?

(This is used to request new product features)
Add a TTY checker for the CLI to disable the use of color, symbols, animation, and emojis when TTY not present or when env var TERM=dumb is set.

Add a checker for the CLI to disable the use of color when the NO_COLOR env var is set to true.

Describe the feature request

Making machine-reading easier by simplifying the outputs when we can detect non-TTY action or when explicitly requested by the user.

Describe alternatives you've considered

Affected product area (please put an X in all that apply)

[ ] APIs
[ ] Addons
[x] CLI
[ ] Docs
[ ] Installation
[ ] Plugin
[ ] Security
[ ] Test and Release
[ ] User Experience

Additional context

Bug description

The following tanzu command prints Error: accepts 1 arg(s), received 0 and the help content, but also Error: exit status 1 at the end. Seems there is no need to print Error: exit status 1. I also noticed when tanzu management-cluster create ... prints the help context when its execution failed.

$ tanzu cluster kubeconfig get
Error: accepts 1 arg(s), received 0
Get kubeconfig of a cluster and merge the context into the default kubeconfig file

Usage:
  tanzu cluster kubeconfig get CLUSTER_NAME [flags]

Examples:
  
    # Get workload cluster kubeconfig
    tanzu cluster kubeconfig get CLUSTER_NAME    # Get workload cluster admin kubeconfig
    tanzu cluster kubeconfig get CLUSTER_NAME --adminFlags:
      --admin                Get admin kubeconfig of the workload cluster
      --export-file string   File path to export a standalone kubeconfig for workload cluster
  -h, --help                 help for get
  -n, --namespace string     The namespace where the workload cluster was created. Assumes 'default' if not specified.Global Flags:
        --log-file string   Log file path
  -v, --verbose int32     Number for the log level verbosity(0-9)

Error: exit status 1
✖  exit status 1

For example, 'kubectl get' doesn't print the exit status.

$ kubectl get 
You must specify the type of resource to get. Use "kubectl api-resources" for a complete list of supported resources.

error: Required resource not specified.
Use "kubectl explain <resource>" for a detailed description of that resource (e.g. kubectl explain pods).
See 'kubectl get -h' for help and examples

Affected product area (please put an X in all that apply)

[ ] APIs
[ ] Addons
[X] CLI
[ ] Docs
[ ] Installation
[ ] Plugin
[ ] Security
[ ] Test and Release
[ ] User Experience

Expected behavior

Steps to reproduce the bug

Version (include the SHA if the version is not obvious)

$ tanzu version
version: v1.3.0-rc.2
buildDate: 2021-02-26
sha: bc3e781-dirty

Environment where the bug was observed (cloud, OS, etc)

Relevant Debug Output (Logs, manifests, etc)

Collated Context

Context from 2021-03-10 07:23:20
User: jessehu
Here is the log when tanzu management-cluster create ... failed and it prints the usage content after the detail error msg. It's not expected to print the usage content in this command failure case.

[2021-03-09T16:53:50.149Z] Success waiting on all providers.
[2021-03-09T16:53:50.149Z] Start creating management cluster...
[2021-03-09T16:53:50.149Z] 
[2021-03-09T16:53:50.149Z] 
[2021-03-09T16:53:50.149Z] Failure while deploying management cluster, Here are some steps to investigate the cause:
[2021-03-09T16:53:50.149Z] 
[2021-03-09T16:53:50.149Z] Debug:
[2021-03-09T16:53:50.149Z]     kubectl get po,deploy,cluster,kubeadmcontrolplane,machine,machinedeployment -A --kubeconfig /home/capv/.kube-tkg/tmp/config_L5etLzc8
[2021-03-09T16:53:50.149Z]     kubectl logs deployment.apps/<deployment-name> -n <deployment-namespace> manager --kubeconfig /home/capv/.kube-tkg/tmp/config_L5etLzc8
[2021-03-09T16:53:50.149Z] 
[2021-03-09T16:53:50.149Z] To clean up the resources created by the management cluster:
[2021-03-09T16:53:50.149Z] 	  tanzu management-cluster delete
[2021-03-09T16:53:50.149Z] Error: unable to set up management cluster: unable to wait for cluster and get the cluster kubeconfig: error waiting for cluster to be provisioned (this may take a few minutes): cluster creation failed, reason:'VMProvisionFailed @ Machine/tkgextensions-bee09a7c0b33-control-plane-xmh5k', message:'1 of 2 completed'

[2021-03-09T16:53:50.149Z] Usage:
[2021-03-09T16:53:50.149Z]   tanzu management-cluster create [flags]
[2021-03-09T16:53:50.149Z] 
[2021-03-09T16:53:50.149Z] Examples:
[2021-03-09T16:53:50.149Z]   
[2021-03-09T16:53:50.149Z]     # Create a management cluster on AWS infrastructure, initializing it with
[2021-03-09T16:53:50.149Z]     # components required to create workload clusters through it on the same infrastructure
[2021-03-09T16:53:50.149Z]     # by bootstrapping through a self-provisioned bootstrap cluster.
[2021-03-09T16:53:50.149Z]     tanzu management-cluster create --file ~/clusterconfigs/aws-mc-1.yaml
[2021-03-09T16:53:50.149Z]     # Launch an interactive UI to configure the settings necessary to create a
[2021-03-09T16:53:50.149Z]     # management cluster
[2021-03-09T16:53:50.149Z]     tanzu management-cluster create --ui
[2021-03-09T16:53:50.149Z]     # Create a management cluster on vSphere infrastructure by using an existing
[2021-03-09T16:53:50.149Z]     # bootstrapper cluster. The current kube context should point to that
[2021-03-09T16:53:50.149Z]     # of the existing bootstrap cluster.
[2021-03-09T16:53:50.149Z]     tanzu management-cluster create --use-existing-bootstrap-cluster --file vsphere-mc-1.yaml
[2021-03-09T16:53:50.149Z] 
[2021-03-09T16:53:50.149Z] Flags:
[2021-03-09T16:53:50.149Z]   -b, --bind string                      Specify the IP and port to bind the Kickstart UI against (e.g. 127.0.0.1:8080). (default "127.0.0.1:8080")
[2021-03-09T16:53:50.149Z]       --browser string                   Specify the browser to open the Kickstart UI on. Use 'none' for no browser. Defaults to OS default browser. Supported: ['chrome', 'firefox', 'safari', 'ie', 'edge', 'none']
[2021-03-09T16:53:50.149Z]   -f, --file string                      Configuration file from which to create a management cluster
[2021-03-09T16:53:50.149Z]   -h, --help                             help for create
[2021-03-09T16:53:50.149Z]   -t, --timeout duration                 Time duration to wait for an operation before timeout. Timeout duration in hours(h)/minutes(m)/seconds(s) units or as some combination of them (e.g. 2h, 30m, 2h30m10s) (default 30m0s)
[2021-03-09T16:53:50.149Z]   -u, --ui                               Launch interactive management cluster provisioning UI
[2021-03-09T16:53:50.149Z]   -e, --use-existing-bootstrap-cluster   Use an existing bootstrap cluster to deploy the management cluster
[2021-03-09T16:53:50.149Z]   -y, --yes                              Create management cluster without asking for confirmation
[2021-03-09T16:53:50.149Z] 
[2021-03-09T16:53:50.149Z] Global Flags:
[2021-03-09T16:53:50.149Z]         --log-file string   Log file path
[2021-03-09T16:53:50.149Z]   -v, --verbose int32     Number for the log level verbosity(0-9)
[2021-03-09T16:53:50.150Z] 
[2021-03-09T16:53:50.150Z] Error: exit status 1
[2021-03-09T16:53:50.150Z] ✖  exit status 1 

Describe the feature request

It's great that the UI shows CLI command equivalents. When the command just takes a file as input, I wish it'd also show the contents of the file (even if it's just a heredoc echo or something). I can go cat the file and understand the contents, but I think the goal of including this in the UI is to sort of help me learn the CLI experience by osmosis and just having an opaque filename there doesn't really help.

Describe alternatives you've considered

I haven't considered alternatives.

Affected product area (please put an X in all that apply)

• APIs
• Addons
• CLI
• Docs
• Installation
• Plugin
• Security
• Test and Release
• User Experience

Additional context

It seems like the file often includes a lot of default/empty fields. Bonus points for helping the user understand which fields were actually set based on their selections and which pieces are just boilerplate.

Ideally each plugin should be a go module

Collated Comments

I was using TCE v0.6.0 and trying out AWS Standalone Cluster creation using the Kickstart UI. While filling in the fields, most fields had suggestions / drop downs with valid values and there was validation being done too I think. Except for the SSH Key name field (in the first step) though. It seemed like SSH key name field was a free flow text field without suggestions and random names for example ok let me pass to the next step with no validation errors. I wasn't sure what to provide in the SSH key name field until I read this link from a team mate - https://docs.vmware.com/en/VMware-Tanzu-Kubernetes-Grid/1.0/vmware-tanzu-kubernetes-grid-10/GUID-install-tkg-aws.html#register-ssh . I think it's good to do some validations so that users get early feedback? Or is this already being done and it's just not available in TCE v0.6.0 yet?