Add labels and annotations to workload get output

[heyjcollins]

Example use cases:

This is part of a broader effort to enhance workload get

I can see what conventions were applied
I can see if live view or debug are enabled
I can see other properties that may not be surfaced in the main output

Given I've created a workload on my target cluster
When I inspect the workload with workload get
Then I can see the labels and annotations attached to the running workload, so that I can better understand the workload.

Requirements

Labels and Annotations headers should only be displayed when there are labels/annotations associated with the workload.

Proposed Output

❯ tanzu apps workload get e
# e: Ready
---
lastTransitionTime: "2022-01-29T08:07:18Z"
message: ""
reason: Ready
status: "True"
type: Ready

Pods
NAME                                  STATE       AGE
e-00007-deployment-7f77cb6474-rbtq4   Running     7d17h
e-build-3-build-pod                   Succeeded   7d17h
e-config-writer-9vqql-pod             Succeeded   7d17h
e-config-writer-mk79m-pod             Succeeded   7d21h
e-config-writer-q5bfq-pod             Succeeded   7d17h
e-config-writer-w7mrg-pod             Succeeded   7d17h
e-config-writer-zswvb-pod             Succeeded   7d21h 

Knative Services
NAME   READY   URL
e      Ready   http://e.default.apps.35.247.106.11.nip.io

Labels
app=e-00007
app.kubernetes.io/component=run
apps.tanzu.vmware.com/workload-type=web
carto.run/workload-name=e
conventions.apps.tanzu.vmware.com/framework=spring-boot
pod-template-hash=7f77cb6474
serving.knative.dev/configuration=e
serving.knative.dev/configurationGeneration=7
serving.knative.dev/configurationUID=c1719abc-7e0d-4521-8537-a89d0fb0f6df
serving.knative.dev/revision=e-00007
serving.knative.dev/revisionUID=4cbe8cae-8672-4b2f-ad72-137a2e40a6cd
serving.knative.dev/service=e
serving.knative.dev/serviceUID=abda67d0-8b1f-408a-bf98-f834b5d8d268
tanzu.app.live.view=true
tanzu.app.live.view.application.flavours=spring-boot
tanzu.app.live.view.application.name=demo

Annotations
apps.tanzu.vmware.com/live-update: true
autoscaling.knative.dev/maxScale: 1
autoscaling.knative.dev/minScale: 1
boot.spring.io/actuator: http://:8080/actuator
boot.spring.io/version: 2.5.8
conventions.apps.tanzu.vmware.com/applied-conventions:
  appliveview-sample/app-live-view-connector
  appliveview-sample/app-live-view-appflavours
  appliveview-sample/app-live-view-systemproperties
  developer-conventions/live-update-convention
  developer-conventions/add-source-image-label
  spring-boot-convention/spring-boot
  spring-boot-convention/spring-boot-graceful-shutdown
  spring-boot-convention/spring-boot-web
  spring-boot-convention/spring-boot-actuator
developer.apps.tanzu.vmware.com/image-source-digest:
  gcr.io/pivotal-knative/jc-apps:latest@sha256:3ba565457e5b5c64f5956bcb7ef9080fb3d4083f0a7c5826b48832507623c177
developer.conventions/target-containers: workload
serving.knative.dev/creator: system:serviceaccount:default:default

Note: Over time, as we surface more information in GET, and error messages improve labels/annotations may end up being more troubleshooting/debug type information, and may make more sense as a verbose or flagged optional output.

[heyjcollins]

Comment originally submitted by @scothis:

@heyjcollins the labels and annotations you listed are clearly from a pod, but which Pod? There are seven pods shown. One of which is running via Knative. That pod will scale down and go away taking the labels/annotations with it. It's also quite possible that multiple Knative pods will run simultaneously from the same or different revisions.

Not to sound too much like a broken record, but we should also make sure this design works with a build cluster when the runtime components are in a different cluster.

[heyjcollins]

closing this out as won't implement.
users can run tanzu apps workload get appName --export to view the labels and annotations associated with the workload.