Description of problem

While researching an issue whereby a user is required to provide --git-branch in addition to --git-tag in order for workload create/update/apply to succeed, found out user has to provide either --git-tag, --git-branch or both if they want want to provide --git-commit in order to create the workload from a specific commit.
Yet, this issue is blocked by the usage of the current version of FluxCD Source Controller (0.16) in Tanzu Application Platform

Proposed solution

1. Update the version of FluxCD
2. Remove client-side validation for mutual inclusion of (--git-branch or --git-tag) when --git-commit is provided

Additional context

• https://github.com/vmware-tanzu/tanzu-cli-apps-plugins/commit/ef67dc59ae3fc853fa0719002a0e3012c302c3f7
• fluxcd/source-controller#315
• fluxcd/source-controller#462

Issue originally submitted by @warango4

Description of problem

Workload get output includes information about the source code, but does not include a sub-path if specified. This could lead to confusion in cases where a given repository contains more than one microservice/application.

Proposed solution

Given I create an workload that specifies a sub-path in the workload.yaml or via cli flag
When I `get` details about that workload
Then I should see the sub-path in the section that includes data about the source code.

Example

If code is in a repo

$tanzu apps workload get NAME

Name:   tanzu-java-web-app: Ready
---
lastTransitionTime:  "2022-01-05T06:57:18Z"
message:             ""
reason:              Ready [waiting for value at path]
status:              "True"
type:                Ready

source:     https://github.com/odedia/todos-pcf
sub-path:   todo-ui
branch:     main

If code is in an image

source:    Image
image:     gcr.io/pivotal-knative/jc-apps:latest@sha256:3ba565457e5b5c64f5956bcb7ef9080fb3d4083f0a7c5826b48832507623c177 
sub-path:  todo-ui

Describe alternatives you've considered

A clear and concise description of any alternative solutions or features you've considered.

Additional context

Dependent on prior story to include the source information section to the workload get output.

Description of problem

The github.com/vmware-labs/reconciler-runtime/testing/factories package is deprecated and will be removed in a future release. Spiritually equivalent and much more complete options are available via libraries like dies.dev.

rtesting.Factory is deprecated and will be removed in the future. Existing usage has changed to client.Object, each of these uses will call .DeepCopyObject() before using the content. This method can be used to create a factory equivalent. dies.dev and the now deprecated factories use this pattern allowing them to be dropped into test suites along with vanilla k8s objects without needing a wrapper.

apis.Condition and related objects were removed in favor of metav1.Condition. While this is nearly a drop-in replacement there are differences. The reason field is now required, the severity field does not exist. The ConditionSets and ConditionManger remain and are updated to use metav1.Condition.

Proposed solution

Update existing tests as needed to conform to the new standard or reconciler-runtime using https://pkg.go.dev/dies.dev

Example

n/a

Describe alternatives you've considered

n/a

Additional context

n/a

Description of problem

Workload get and workload list commands acceptyaml as an --output value today.
Because yml is a valid extension for the same file-type, we should accept yml and/or yaml

Proposed solution

Given I have a workload named foo
When I run `tanzu apps workload get foo -o yml`
Then the output from the command is exactly the same as if I ran `tanzu apps workload get foo -o yaml`

Given I have created workloads on my target cluster
When I run `tanzu apps workload list -o yml`
Then the output from the command is exactly the same as if I ran `tanzu apps workload list -o yaml`

Description of problem

Add PR Template

Proposed solution

Add PR Template

Example

n/a

Describe alternatives you've considered

n/a

Additional context

n/a

Description of problem

There have been cases in tap-assist where folks lose track of which workload is from which source, or where they use the wrong repo/branch and have a hard time troubleshooting the resulting unexpected behavior.

Proposed solution

As an application developer, when I inspect a workload via workload get I would like to know what source code / image is currently used by the workload so that I can verify that the latest version has been picked up

As an application operator, when I inspect a workload via workload get I would like to know what source code / image is currently used by the workload so that I can trace back a given workload when troubleshooting or auditing

Given a workload has been deployed to my target cluster
When I inspect the workload via workload get
Then I can see what source code / image is currently used by the workload so that I can trace back a given workload when troubleshooting or auditing

Describe alternatives you've considered

tanzu apps workload get NAME --export will return that that information, but as yaml or json - but those formats are less human friendly than providing name/value pairings.

UX

If code is sourced from a git repo

$tanzu apps workload get tanzu-java-web-app -n tap-install
Name:   tanzu-java-web-app: Ready
---
lastTransitionTime:  "2022-01-05T06:57:18Z"
message:             ""
reason:              Ready [waiting for value at path]
status:              "True"
type:                Ready

Source:   https://github.com/spring-projects/spring-petclinic
Branch:   main
Tag   :   v1.1.0
Commit:   g5na5c

If code is sourced from local code

Source:        Local source code
Source-image:  Source:gcr.io/pivotal-knative/jc-apps:latest@sha256:3ba565457e5b5c64f5956bcb7ef9080fb3d4083f0a7c5826b48832507623c177
Updated:       23min 

If code is sourced from a prebuild image

Source:    Image
Image:     gcr.io/pivotal-knative/jc-apps:latest@sha256:3ba565457e5b5c64f5956bcb7ef9080fb3d4083f0a7c5826b48832507623c177 
Updated:   23min 

Updated — If possible to know, how long has it been since the last update from the source. The intent is to help folks know if their latest changes have been picked up. Talking to Wendy it sounds like this may not be easily knowable.

Additional context

Issue originally reported by @danfein

Description of problem

Add Security Document

Proposed solution

Adding Security Document

Example

n/a

Describe alternatives you've considered

n/a

Additional context

n/a

Please fill out the issue checklist below and provide ALL the requested information.

• I reviewed open and closed Github issues that may be related to my problem.
• I am reporting a bug that others will be able to reproduce.

Describe the bug

When user attempts to run workload list against a namespace that doesn't exist, the plugin returns: "No workloads found" and exits 0.

While it's true that no workloads would be found in a non-existent namespace, it hides the fact that the namespace name provided either doesn't exist (or the user doesn't have permissions to see the contents of the namespace provided).
If the user misspelled the namespace, the current response doesn't make that obvious.

When the namespace doesn't exist, the command should exit 1 with a helpful error message.
If there's a permissions issue for the namespace, that's distinguishable from the namespace not existing, the command should exit 1 with a different helpful error message.

If the plugin is unable to distinguish between the two, the command should exit 1 with a helpful error message that combines the possible issues using "or".

Expected behavior

Current:

tanzu apps workload list --namespace foo
No workloads found.

Proposed (@danfein please refine as you see fit):

tanzu apps workload list --namespace foo

Error: namespace "foo" not found
Error: exit status 1

✖  exit status 1

Proposed - user doesn't have permissions to inspect namespace contents:

tanzu apps workload list --namespace foo

Error: user "user-name" has insufficient permissions to view namespace "foo"
Error: exit status 1

✖  exit status 1

Proposed - if doesn't exist and insufficient permissions are indistinguishable:

tanzu apps workload list --namespace foo

Error: either namespace "foo" not found or user "user-name" has insufficient permissions to view namespace "foo"
Error: exit status 1

✖  exit status 1

Steps to Reproduce

tanzu apps workload list --namespace bogus-namespace

Version (Apps plugin version, Version of K8s running on cluster)

all versions

Additional context & Relevant Debug Output (Logs, etc)

Add any other context about the problem here.

Description of problem

Developers will provide the same flags/values repeatedly when iterating on their application code.
Typing or copy/pasting the flag values for every workload create/update/apply adds friction to the developer workflow.
We should make it possible for the user to specify sane defaults via envvars such that they can execute their commands with the minimum required flags

Related to #108

Proposed solution

• All supported EnvVars are documented in all discoverable doc locations
• Envvar naming convention is established, documented and discoverable
• When an envvar exists for a given flag and the flag is not explicitly provided, use the envvar value
• When an envar exists and a flag/value HAS been explicitly provided, use the flag value
• Where no env var or flag/value exists for a required flag, throw an error

Precedence order: flag/value > environment variable > config value [*1]
[1] if/when we work on #108 (enabling users to configure persistent flag values...) --- the EnvVar should take precedence over the configured value for a given flag

Command output changes:
Output from tanzu apps workload create/update/apply should remain as-is (no changes are required to support this new feature).

naming convention for the env vars:

• --flag-name ==> TANZU_APPS_[FLAG_NAME]

Describe alternatives you've considered

use only configurable values

Description of problem

github.com/vmware-tanzu/tanzu-framework is a dependency for the Apps Plugin. The current implementation of the Apps plugin stubs type PluginDescriptor. Additionally, tanzu-framework provides an info subcommand and does not require the plugin to implement it. These are the primary use cases for using tanzu-framework in the apps plugin. These two requirements are at the core of bootstrapping a plugin to the tanzu CLI. However, the tanzu-framwork dependency directly contributes to a large size binary for the apps plugin. The Apps plugin binary size in a POC is reduced by 50% or more after removing tanzu-frameowrk dependency. The binary size reduction estimate is for each OS/Arch. Also, it simplifies managing direct and transitive dependencies for the Apps plugin.

Proposed solution

Remove tanzu-framework dependency from the Apps plugin.

1. Implement p := &cobra.Command{} and map to the required fields used in PluginDescriptor{}
2. Implement a subcommand info that returns required data fields in json format. See example below

Example

tanzu apps info
{"name":"apps","description":"Applications on Kubernetes","version":"v0.0.0-dev","buildSHA":"0e1524fbf625e55a9208c714c97ad3f169494762-dirty","digest":"","group":"Build","docURL":"","completionType":0,"aliases":["app"],"installationPath":"","discovery":"","scope":"","status":""}

Describe alternatives you've considered

N/A

Additional context

N/A

Please fill out the issue checklist below and provide ALL the requested information.

• I reviewed open and closed Github issues that may be related to my problem.
• I am reporting a bug that others will be able to reproduce.

Describe the bug

While testing Apps plugin behavior with users having different RBAC permissions, I found out that when a user who does not have permission to create a workload tries to run tanzu apps workload create command, apps plugin responds with an incorrect message.

Running $ tanzu apps workload create petc --local-path . on a Kind cluster with no Cartographer/TAP/AppToolkit installed.

API Error name:tanzu apps  error:no matches for kind "Workload" in version "carto.run/v1alpha1"
Error: workload "default/petc" already exists
Error: exit status 1

✖  exit status 1

Expected behavior

Error: You don't have Cartographer/TAP/AppToolkit installed on your cluster. Please proceed to install it before using this plugin.
Error: exit status 1

✖  exit status 1

Running $ tanzu apps workload create petc-adhol --local-path . on a TAP installed cluster with Pinniped installed where user does not have the permission to create workloads.

API Error name:tanzu apps  error:workloads.carto.run "petc-adhol" is forbidden: User "[email protected]" cannot get resource "workloads" in API group "carto.run" in the namespace "default": decision made by impersonation-proxy.concierge.pinniped.dev
Error: workload "default/petc-adhol" already exists
Error: exit status 1

✖  exit status 1

Expected behavior

Error: workloads.carto.run "petc-adhol" is forbidden: User "[email protected]" cannot get resource "workloads" in API group "carto.run" in the namespace "default": decision made by impersonation-proxy.concierge.pinniped.dev
Error: exit status 1

✖  exit status 1

Version (Apps plugin version, Version of K8s running on cluster)

Apps Plugin version 0.5.1

Description of problem

As per current behaviour, when user inputs a workload through stdin, if there is no file to read from, command keeps waiting until it's interrupted by ctrl+c command. There should be a timeout added as well as a warning message.

Proposed solution

There should be a timeout added as well as a warning message.

Given stdin is empty
When  attempting to create a workload by passing the workload.yaml from stdin 
Then the command will fail fast with a warning message indicating nothing was found in stdin

Example

Current
$ tanzu apps workload create -f - -y (where stdin is empty)
command will hang...

Proposed - @danfein to provide recommendation
$ tanzu apps workload create -f - -y (where stdin is empty)
...

Additional context

• #146
• #300

Originally submitted by @warango4

Description of problem

app devs appreciate efficiency and convenience.
providing broad support for autocompleting flag values makes it possible for people to NOT remember names of items added previously by them or others.

providing autocomplete for flag values inconsistently is a bad UX and we should do all that we can to consistently deliver on the contract.

Proposed solution

apps plugin already supports autocomplete for some flag values (e.g. --namespace --- will return list of possible namespaces)

Add similar support for --env

When I've typed --env then press <TAB>, all the current env vars keys associated with my workload are auto-suggested

Description of problem

In a majority of cases an app dev or app ops person will create/update workloads using the default supply chains available on their workload cluster, but there are edge-cases whereby a special supply chain need be invoked for which an additional, optional, workload property (spec.serviceAccountName) must be set to provide the supply chain with the credentials required to for the supply chain to stamp out the resources as expected.

The apps plugin doesn't support setting this property currently.
The only means to do so is by updating workload.yaml with the spec.serviceAccountName property/value out-of-band via kubectl. This is a sub-optimal experience. It would be ideal if the user wishing to set this workload property didn't have to switch between CLIs.

The need for setting this property isn't likely to be pervasive and persistent and the current thinking is it may not qualify for support via command flag, but it's important enough to warrant supporting the property through passing in the workload.yaml itself.

Proposed solution

Given I want to set the `spec.serviceAccountName` value for my workload
When I execute `workload create/update/apply -f workload.yaml` and the spec.serviceAccountName property/value is set in my workload.yaml 
Then the workload object that's submitted by the apps plugin will included that property/value in the workload object it submits to the cluster

Given I want to set the `spec.serviceAccountName` value for my workload
When I search for instructions on how to do so via the apps plugin in published documentation 
Then I'm able to discover said instructions for updating/submitting the property/value via my workload.yaml

Example

workload.yaml snippet

---
apiVersion: carto.run/v1alpha1
kind: Workload
metadata: {}
spec:
...
  serviceAccountName: <string>
...

Describe alternatives you've considered

provide documentation instructing the user to use kubectl.

Additional context

Description of problem

There are processes/pipelines being utilized today which generate a jar/zip file artifact.

These pipelines will often pull in additional assets which aren't included in the application code itself, but which are necessary for the application function.
A subsequent next step is for the jar/zip of the app to be pushed to and run on a target environment.
Popular platforms such as Cloud Foundry support this workflow today (via the cf CLI).

The apps plugin for the Tanzu CLI does not support creating/updating/applying a workload from a local jar or zip directly.
The file must be unzipped beforehand.
Requiring the jar be unzipped is not an expected step, it creates toil without value, and decreases efficiency.

Proposed solution

Given I've got a JAR (or zipped) file containing all assets required to create a workload and I'm targeting a TAP-enabled workload cluster
When I run `tanzu apps workload create myapp -f path/to/my/myapp.jar...`
Then my workload create command exits 0 and I can validate the workload has run through the supply chain by viewing the workload details via `tanzu apps workload get...`

@danfein to provide UX here

Additional context

• cc: @matthewmcnew @jigsheth57 may have additional context/thoughts on this issue
• from @scothis:
  • It's worth mirroring the behavior of pack. https://github.com/buildpacks/pack/blob/3fc8e2220b584da76cd0227bbc211aae787e0e57/pkg/client/build.go#L596-L605

Description of problem

The workload selection criteria for ootb supply chains no longer relies solely on workload metadata.labels.
Including the label selector(s) in the output of clustersupplychain list will only provide a portion of the information a developer or operator may use to assure their workload is selected by a given supply chain.
Additionally - providing hints to app devs for how to match their workload to a given supply chain is antithetical to the overall goal of providing an app-aware platform.

Proposed solution

As such - the ask here is to remove the LABEL SELECTOR column from the list command output.

Given an application developer or operator would like to learn what supply chains are running on their target cluster
When the user run `tanzu apps clustersupplychain list`
Then they aren't confronted with potentially misleading information regarding the selection criteria for each supply chain returned in the list

Example

current output:

tanzu apps cluster-supply-chain list
NAME                      READY   AGE   LABEL SELECTOR
source-test-scan-to-url   Ready   38h   apps.tanzu.vmware.com/has-tests=true,apps.tanzu.vmware.com/workload-type=web

desired output:

tanzu apps cluster-supply-chain list
NAME                      READY   AGE   
source-test-scan-to-url   Ready   38h   

Describe alternatives you've considered

Considered deprecating the column. Decided against it because doing so for command output would set precedent for the output to be considered an interface (it is not).

Additional context

Add any other context or screenshots about the feature request here.

Description of problem

In the workload object, the params value can take any shape. The value can be a an array or object that the plugin should be able to parse into yaml. The values can be of any data type.
The current --param flag only supports key/value pairs and always treats the value as a string.

This limitation prevents us from supporting additional data types and more complex objects which end users will need to provide.

Let's support either JSON -or- YAML formatted values via a new flag: --param-yaml.

Proposed solution

Given a workload create/update/apply command
When a --param-yaml key/value is provided
Then apps plugin should be able to parse the json value and convert it into valid yaml in the workload object

--help output for the flag:

--param-yaml "key=value" pair         specify nested parameters using YAML or JSON formatted values represented as a "key=value" pair ("key-" to remove, flag may be used multiple times)

Example

Object support

Example Command:

tanzu apps workload create direct-smtp-mq-gateway --type tcp --app direct-project --git-repo https://github.com/gm2552/direct-smtp-mq-gateway.git --git-branch master --service-ref rmq=services.apps.tanzu.vmware.com/v1alpha1:ResourceClaim:rmq-1 --param-yaml ports='{"name": "smtp", "port": 1026}'

The outcome should be exactly the same if the yaml formatted string is passed in as follows:

• --param-yaml ports=$'name: smtp\nport: 1026'

should create a workload as follows:

apiVersion: carto.run/v1alpha1
kind: Workload
metadata:
  name: direct-smtp-mq-gateway
  labels:
    apps.tanzu.vmware.com/workload-type: tcp
    app.kubernetes.io/part-of: direct-project
spec:
  serviceClaims:
  - name: rmq
    ref:
      apiVersion: services.apps.tanzu.vmware.com/v1alpha1
      kind: ResourceClaim
      name: rmq-1
  source:
    git:
      url: https://github.com/gm2552/direct-smtp-mq-gateway.git
      ref:
        branch: master
  params:
  - name: ports
    value:
      port: 1026
      name: smtp

Array support

Example Command:

tanzu apps workload create direct-smtp-mq-gateway --type tcp --app direct-project --git-repo https://github.com/gm2552/direct-smtp-mq-gateway.git --git-branch master --service-ref rmq=services.apps.tanzu.vmware.com/v1alpha1:ResourceClaim:rmq-1 --param-yaml ports='[{"name": "smtp", "port": 1026},{"name": "tcp", "port": 8080}]'

The outcome should be exactly the same if the yaml formatted string is passed in as follows:

• --param-yaml ports=$'- port: 1026\n name: smtp\n- port: 8080\n name: tcp'

should create a workload as follows:

apiVersion: carto.run/v1alpha1
kind: Workload
metadata:
  name: direct-smtp-mq-gateway
  labels:
    apps.tanzu.vmware.com/workload-type: tcp
    app.kubernetes.io/part-of: direct-project
spec:
  serviceClaims:
  - name: rmq
    ref:
      apiVersion: services.apps.tanzu.vmware.com/v1alpha1
      kind: ResourceClaim
      name: rmq-1
  source:
    git:
      url: https://github.com/gm2552/direct-smtp-mq-gateway.git
      ref:
        branch: master
  params:
  - name: ports
    value:
    - port: 1026
      name: smtp
    - port: 8080
      name: tcp

Nesting support

Example Command:

tanzu apps workload create direct-smtp-mq-gateway --type tcp --app direct-project --git-repo https://github.com/gm2552/direct-smtp-mq-gateway.git --git-branch master --service-ref rmq=services.apps.tanzu.vmware.com/v1alpha1:ResourceClaim:rmq-1 --param-yaml ports='[{"deployment": {"name": "smtp", "port": 1026}}]'

The outcome should be exactly the same if the yaml formatted string is passed in as follows:

• --param-yaml ports=$'- deployment:\n name: smtp\n port: 1026'

should create a workload as follows:

apiVersion: carto.run/v1alpha1
kind: Workload
metadata:
  name: direct-smtp-mq-gateway
  labels:
    apps.tanzu.vmware.com/workload-type: tcp
    app.kubernetes.io/part-of: direct-project
spec:
  serviceClaims:
  - name: rmq
    ref:
      apiVersion: services.apps.tanzu.vmware.com/v1alpha1
      kind: ResourceClaim
      name: rmq-1
  source:
    git:
      url: https://github.com/gm2552/direct-smtp-mq-gateway.git
      ref:
        branch: master
  params:
  - name: ports
    value:
    - deployment:
        port: 1026
        name: smtp

Invalid JSON or YAML input

Apps plugin should fail with a validation error as follows

The provided value for param-yaml "<param key>" is not valid yaml/json: <message error>

CC @danfein @heyjcollins for Design and Product input

Please fill out the issue checklist below and provide ALL the requested information.

• I reviewed open and closed Github issues that may be related to my problem.
• I am reporting a bug that others will be able to reproduce.

Describe the bug

When I install the tanzu apps cli plugin, and use the tanzu apps workload get command, I want to see the URL of my deployed workload. But that doesn't happen right now.

Expected Behavior

I expect to get the workload URL when I run tanzu apps workload get

Steps to Reproduce the Bug

1. Follow the App Toolkit Package README for installing, configuring and creating Tanzu workload
2. Then run tanzu apps workload get, you'll see the below output.

Screenshots or additional information and context

---
lastTransitionTime: "2022-03-30T18:21:36Z"
message: ""
reason: Ready
status: "True"
type: Ready

Pods
NAME                                     STATUS      RESTARTS   AGE
tanzu-simple-web-app-build-1-build-pod   Succeeded   0          4d19h
tanzu-simple-web-app-build-2-build-pod   Failed      0          47h

Version (Apps plugin version, Version of K8s running on cluster)

Kubernetes version - v1.22.4

tanzu version

buildDate: 2022-03-24
sha: 6431d1d

tanzu apps version - v0.5.1

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

TCE v0.11

Cross-posted TCE Issue

vmware-tanzu/community-edition#3885

Description of problem

Remove unused codecov-action

Proposed solution

Remove unused codecov-action

Example

n/a

Describe alternatives you've considered

n/a

Additional context

n/a

Description of problem

Multiple instances were reported where a corporate firewall scrambles the SSL handshake between a dev's local machine and the external signed registry like azurecr.io. This results in apps plugin failing to push an image and an error message certificate signed by unknown authority.

Proposed solution

Currently apps plugin does not support flags to set the CACertPaths, VerifyCerts and Insecure registry options through flags and VerifyCerts defaults to true. We should add flags to support boolean VerifyCerts and Insecure options, and default to secure options, but allow the user to override it using flags if they are behind firewall and run into this issue.

For Future state, we should provide a config option (once #108 is implemented) to let user change the defaults to insecure mode as they will always hit this firewall issue, but won't have to provide flags all the time.

CC @danfein @heyjcollins for design and product input regarding flag names.

Thanks to @cpage-pivotal for bringing this to our attention.

Updates

We have decided to not implement support for overriding the following options

• insecure (will always default to false)
• verifyCerts (will always default to true)

Flags that will be added as part of this issue to support passing the following information

• username
• password
• token
• caCertsPath

Reference: https://pkg.go.dev/github.com/vmware-tanzu/[email protected]/pkg/imgpkg/registry#Opts

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.

Description of problem

Currently the codebase contains lot of repeated code in dies(generating fakes) for the WorkloadSpec and WorkloadStatus. This can be done better by adding some helper func to set some fields.

Description of problem

Proposed solution

<Please describe your proposed solution, preferably in the following style:>

Given <Some Condition>
When <Something Happens>
Then <This other thing should happen?>

Example

<Code snippets that illustrate the when/then blocks>

Describe alternatives you've considered

A clear and concise description of any alternative solutions or features you've considered.

Additional context

Add any other context or screenshots about the feature request here.

Please fill out the issue checklist below and provide ALL the requested information.

• I reviewed open and closed Github issues that may be related to my problem.
• I am reporting a bug that others will be able to reproduce.

Describe the bug

Running tanzu apps workload commands when KUBECONFIG is not set or pointing to a cluster that is not accessible/deleted returns a panic error stacktrace.

Running tanzu apps workload list when my KUBECONFIG is not set/empty

panic: invalid configuration: no configuration has been provided, try setting KUBERNETES_MASTER environment variable

goroutine 1 [running]:
github.com/vmware-tanzu/apps-cli-plugin/pkg/cli-runtime.(*client).lazyLoadDefaultNamespaceOrDie(0xc0005a8f80)
	/Users/adhol/projects/apps-cli-plugin/pkg/cli-runtime/client.go:215 +0x77
github.com/vmware-tanzu/apps-cli-plugin/pkg/cli-runtime.(*client).DefaultNamespace(0xc00013a010)
	/Users/adhol/projects/apps-cli-plugin/pkg/cli-runtime/client.go:52 +0x19
github.com/vmware-tanzu/apps-cli-plugin/pkg/cli-runtime.NamespaceFlag.func1(0xc000b0a000, {0x54363e8, 0x0, 0x0})
	/Users/adhol/projects/apps-cli-plugin/pkg/cli-runtime/flags.go:64 +0x5c
github.com/spf13/cobra.(*Command).execute(0xc000b0a000, {0x54363e8, 0x0, 0x0})
	/Users/adhol/projects/apps-cli-plugin/vendor/github.com/spf13/cobra/command.go:845 +0x5a8
github.com/spf13/cobra.(*Command).ExecuteC(0xc000216280)
	/Users/adhol/projects/apps-cli-plugin/vendor/github.com/spf13/cobra/command.go:974 +0x3bc
github.com/spf13/cobra.(*Command).Execute(...)
	/Users/adhol/projects/apps-cli-plugin/vendor/github.com/spf13/cobra/command.go:902
github.com/vmware-tanzu/tanzu-framework/pkg/v1/cli/command/plugin.(*Plugin).Execute(...)
	/Users/adhol/projects/apps-cli-plugin/vendor/github.com/vmware-tanzu/tanzu-framework/pkg/v1/cli/command/plugin/plugin.go:54
main.main()
	/Users/adhol/projects/apps-cli-plugin/cmd/plugin/apps/main.go:127 +0xa91
Error: exit status 2

✖  exit status 2

Expected behavior

Error: invalid configuration: no configuration has been provided, try setting KUBERNETES_MASTER environment variable
Error: exit status 2

✖  exit status 2

Running tanzu apps workload list when my KUBECONFIG is pointing to a cluster that is not accessible/deleted

panic: Get "https://127.0.0.1:50471/api?timeout=32s": dial tcp 127.0.0.1:50471: connect: connection refused

goroutine 1 [running]:
github.com/vmware-tanzu/apps-cli-plugin/pkg/cli-runtime.(*client).lazyLoadClientOrDie(0xc0005a9e80)
	/Users/adhol/projects/apps-cli-plugin/pkg/cli-runtime/client.go:203 +0x9b
github.com/vmware-tanzu/apps-cli-plugin/pkg/cli-runtime.(*client).Client(...)
	/Users/adhol/projects/apps-cli-plugin/pkg/cli-runtime/client.go:64
github.com/vmware-tanzu/apps-cli-plugin/pkg/cli-runtime.(*client).List(0xc0005a9e80, {0x3a951c8, 0xc000d2df80}, {0x3add610, 0xc000217730}, {0xc000fb44c0, 0x2, 0x2})
	/Users/adhol/projects/apps-cli-plugin/pkg/cli-runtime/client.go:77 +0x18c
github.com/vmware-tanzu/apps-cli-plugin/pkg/commands.(*WorkloadListOptions).Exec(0xc000cc2f90, {0x3a951c8, 0xc000d2df80}, 0xc000614320)
	/Users/adhol/projects/apps-cli-plugin/pkg/commands/workload_list.go:73 +0x197
github.com/vmware-tanzu/apps-cli-plugin/pkg/cli-runtime.ExecE.func1(0xc000ce0280, {0x54363e8, 0x0, 0x0})
	/Users/adhol/projects/apps-cli-plugin/pkg/cli-runtime/options.go:70 +0x12f
github.com/spf13/cobra.(*Command).execute(0xc000ce0280, {0x54363e8, 0x0, 0x0})
	/Users/adhol/projects/apps-cli-plugin/vendor/github.com/spf13/cobra/command.go:856 +0x60e
github.com/spf13/cobra.(*Command).ExecuteC(0xc000ca2c80)
	/Users/adhol/projects/apps-cli-plugin/vendor/github.com/spf13/cobra/command.go:974 +0x3bc
github.com/spf13/cobra.(*Command).Execute(...)
	/Users/adhol/projects/apps-cli-plugin/vendor/github.com/spf13/cobra/command.go:902
github.com/vmware-tanzu/tanzu-framework/pkg/v1/cli/command/plugin.(*Plugin).Execute(...)
	/Users/adhol/projects/apps-cli-plugin/vendor/github.com/vmware-tanzu/tanzu-framework/pkg/v1/cli/command/plugin/plugin.go:54
main.main()
	/Users/adhol/projects/apps-cli-plugin/cmd/plugin/apps/main.go:127 +0xa91
Error: exit status 2

✖  exit status 2

Expected behavior

Error: Unable to connect to k8s cluster at "https://127.0.0.1:50471/api?timeout=32s": dial tcp 127.0.0.1:50471: connect: connection refused
Error: exit status 1

✖  exit status 1

Screenshots

Version (Apps plugin version, Version of K8s running on cluster)

Apps plugin v0.5.1

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

macOS Monterey v12.3

Description of problem

The apps plugin relies on stern logging library to tail the logs for all pod resources created as a result of a tanzu apps workload create/update/apply...

The log output can be quite verbose and we currently provide the ability to filter the logs by --component (e.g. values: run or build).
This is helpful, but the logs even for a single pod can be lengthy and the stern library provides some additional filtering features we may want to take advantage of and expose to end-users.

The cf-cli enabled grabbing the most recent 100 log lines via cf logs my-app --recent.
--recent was used with a high degree of frequency.
We should look into whether/how we might provide a similar feature in the apps plugin.

Additionally - the current --component flag isn't intuitively named.
We should deprecate --component and provide a new --pod flag to allow user to filter the logs to those only from the pod specified.
--pod can be specified multiple times.
If no --pod value is provided, all pod logs should be included.

Proposed solution

1. tanzu apps workload tail my-app --recent
   • Returns the most recent 100 log lines, from ALL pods, ordered by timestamp ascending (most recent log entry would be at the end of the log output).
2. tanzu apps workload tail my-app --recent --pod my-app-build-3-build-pod
   • Returns the most recent 100 log lines, from pod my-app-build-3-build-pod, ordered by timestamp ascending.
3. tanzu apps workload tail my-app --recent --pod my-app-build-3-build-pod --pod my-app-config-writer-xgx4q-pod
   • Returns the most recent 100 log lines, from both my-app-build-3-build-pod and my-app-config-writer-xgx4q-pod, ordered by timestamp ascending.
4. tanzu apps workload tail -h
   • Returns help which includes two additional flags
     • --pod string pod to tail logs from (flag can be used multiple times)
     • --recent provide the most recent 100 log lines

Description of problem

Currently, the apps plugin gets the URL for a given workload directly from the knative service.
This implementation is brittle (if/when a workload has been deployed to a runtime other than kn, even if a publicly addressable route has been configured, there will be no URL displayed in workload get output).

Proposed solution

Given my workload is running, but not as a knative service and the workload has been configured to respond to public http requests (has an addressable URL)
When I run `tanzu apps workload get` for the workload
Then the publicly addressable URL is included in the command output

Example

<Code snippets that illustrate the when/then blocks>

Describe alternatives you've considered

A clear and concise description of any alternative solutions or features you've considered.

Additional context

Add any other context or screenshots about the feature request here.

In our unit tests, we currently shortcut all survey prompts creating code paths that are not covered. We should find a way to adequately provide input to the prompts in order to cover those cases.

issue originally submitted by @scothis

Please fill out the issue checklist below and provide ALL the requested information.

• I reviewed open and closed Github issues that may be related to my problem.
• I am reporting a bug that others will be able to reproduce.

Describe the bug

applying or updating the exact workload.yaml that was previously exported which includes a spec.source.subPath property/value --- causes the plugin to remove subPath from the workload

Expected behavior

subPath shouldn't be removed

Steps to Reproduce

create a workload:

tanzu apps workload create pc --git-repo https://github.com/spring-projects/spring-petclinic --gi
t-branch main --sub-path foo --service-ref database=rabbitmq.com/v1beta1:RabbitmqCluster:my-broker --limit-cpu 500 --annotation anba
r=bar --param foo=bar --label lfoo=lbar

export the workload:

tanzu apps workload get pc --export > pc.yaml

apply the workload.yaml that was just created in previous step (without changing it at all)

tanzu apps workload apply -f pc.yaml

You should see the removal of subPath in the resulting diff.

Screenshots

If applicable, add screenshots to help explain your problem.

Version (Apps plugin version, Version of K8s running on cluster)

Put the output of the following commad

tanzu version && tanzu apps version

version: v0.11.2
buildDate: 2022-03-17
sha: 9f16f375
v0.0.0-dev ---- the apps plugin was built locally from this commit: 6ae1969

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

tap installed on GKE
client - Mac

Description of problem

The long commands tanzu apps workload and tanzu apps cluster-supply-chain are error prone. We should add wld and csc alias to match the shortnames for cartographer api resources for tanzu apps workload and tanzu apps cluster-supply-chain commands

Proposed solution

tanzu apps wld and tanzu apps csc should work.

tanzu apps workload delete does not delete image from container registry

I am doing multiple test for deploying sample applications using TAP (tanzu apps workload create) and when deleting those apps workload (tanzu apps workload delete), it does not delete image from container registry. This causes several images on my registry.

Proposed solution

• I expect the image deletion when workload is deleted. OR atleast there can be an option to take input whether you want to delete image too and let use make the decision.

Given <Some Condition>
When <Something Happens>
Then <This other thing should happen?>

Example

<Code snippets that illustrate the when/then blocks>

Describe alternatives you've considered

A clear and concise description of any alternative solutions or features you've considered.

Additional context

Add any other context or screenshots about the feature request here.

Description of problem

One of the top issues folks have described having is that their supply chains get (or appear to get) stuck. Having a little information that the build is still running would help folks reason about the state of the workload.

I don't know how easy it is to get this status, feedback welcome.

Proposed solution

Proposed additional field 

In progress build

Source:        https://github.com/spring-projects/spring-petclinic
Branch:        main
Tag   :        v1.1.0
Commit:        g5na5c
Build Image:   waiting for build                 ## This line is new

Completed build

Source:        https://github.com/spring-projects/spring-petclinic
Branch:        main
Tag   :        v1.1.0
Commit:        g5na5c
Build Image:   <image information>                ## This line is new

Failed build

Source:        https://github.com/spring-projects/spring-petclinic
Branch:        main
Tag   :        v1.1.0
Commit:        g5na5c
Build Image:   Build failed                ## This line is new

Given I've submitted a tanzu apps workload create/apply/update recently 
When my workload hasn't finished building
Then I would like to see a status message that lets me know it is still working.

Describe alternatives you've considered

A clear and concise description of any alternative solutions or features you've considered.

Additional context

Original issue reported by @danfein

Description of problem

Extra logging data display while the log verbose level is not set or 0. See the example below.

Proposed solution

Option 1: Replace the internal LogSync implementation with github.com/go-logr/zapr

Option 2: Fix internal LogSync implementation so that verbose level is honored

Example

API Error name:tanzu apps error:workloads.carto.run "spring-petclinic" not found

Describe alternatives you've considered

N/A

Additional context

This issue was introduced while updating a newer version of the go-logr interface.

Description of problem

The main branch is now ubiquitous in git.
It's reasonable to assume a sane default of main for --git-branch if it's not provided.
If required, --git-branch or --git-tag or --git-commit can be provided.

Proposed solution

This command:

tanzu apps workload create my-app --git-url https://github.com/spring-projects/spring-petclinic

should just work.

Please fill out the issue checklist below and provide ALL the requested information.

• I reviewed open and closed Github issues that may be related to my problem.
• I am reporting a bug that others will be able to reproduce.

Describe the bug

For a workload with a .spec.serviceAccountName set, when executing an apply/update command the service account is unset.

tanzu apps workload update petclinic --label hello=world
Update workload:
...
  3,  3   |kind: Workload
  4,  4   |metadata:
  5,  5   |  labels:
  6,  6   |    apps.tanzu.vmware.com/workload-type: web
      7 + |    hello: world
  7,  8   |  name: petclinic
  8,  9   |  namespace: default
  9, 10   |spec:
 10, 11   |  env:
 11, 12   |  - name: SPRING_PROFILES_ACTIVE
 12, 13   |    value: mysql
 13     - |  serviceAccountName: default
 14, 14   |  serviceClaims:
 15, 15   |  - name: db
 16, 16   |    ref:
 17, 17   |      apiVersion: v1
...

? Really update the workload "petclinic"? No

Expected behavior

One should be able to execute an update/apply command against that workload to modify another value without the service account being unset.

Steps to Reproduce

Steps to reproduce the behavior:

1. create a workload with a service account name2.
2. run any tanzu apps workload apply/update command that would change the workload and doesn't also include the --file flag.

Version (Apps plugin version, Version of K8s running on cluster)

Custom build from main HEAD fc7b718

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

Additional context & Relevant Debug Output (Logs, etc)

Add any other context about the problem here.

Description of problem

Current --help output is too long.
Anything we can do to shorten the copy without compromising clarity should be done.

Proposed solution

These changes should be applied to --help output from:

1. tanzu apps workload create...
2. tanzu apps workload update...
3. tanzu apps workload apply...

Current copy:
This flag may be specified multiple times

Proposed copy:
Flag may be used multiple times

When this is done the output from the following grep should look as follows:

tanzu apps workload create -h | grep multiple
      --annotation "key=value" pair    annotation is represented as a "key=value" pair ("key-" to remove, flag can be used multiple times)
      --build-env "key=value" pair     build environment variables represented as a "key=value" pair ("key-" to remove, flag can be used multiple times)
      --env "key=value" pair           environment variables represented as a "key=value" pair ("key-" to remove, flag can be used multiple times)
      --label "key=value" pair         label is represented as a "key=value" pair ("key-" to remove, flag can be used multiple times)
      --param "key=value" pair         additional parameters represented as a "key=value" pair ("key-" to remove, flag can be used multiple times)
      --service-ref object reference   object reference for a service to bind to the workload "database=rabbitmq.com/v1beta1:RabbitmqCluster:my-broker" ("database-" to remove, flag can be used multiple times)

here's what it looks like currently

tanzu apps workload create -h | grep multiple
      --annotation "key=value" pair    annotation is represented as a "key=value" pair, or "key-" to remove. This flag may be specified multiple times
      --build-env "key=value" pair     build environment variables represented as a "key=value" pair, or "key-" to remove. This flag may be specified multiple times
      --env "key=value" pair           environment variables represented as a "key=value" pair, or "key-" to remove. This flag may be specified multiple times
      --label "key=value" pair         label is represented as a "key=value" pair, or "key-" to remove. This flag may be specified multiple times
      --param "key=value" pair         additional parameters represented as a "key=value" pair, or "key-" to remove. This flag may be specified multiple times
      --service-ref object reference   object reference for a service to bind to the workload "database=rabbitmq.com/v1beta1:RabbitmqCluster:my-broker", or "database-" to delete. This flag may be specified multiple times.

Describe alternatives you've considered

• flag is repeatable
• flag may be repeated
• can be repeated
• can be used multiple times
• repeatable

Additional context

Add any other context or screenshots about the feature request here.

Please fill out the issue checklist below and provide ALL the requested information.

• I reviewed open and closed Github issues that may be related to my problem.
• I am reporting a bug that others will be able to reproduce.

Describe the bug

For Example:

- tanzu-java-web-app-build-1-build-pod › completion
- tanzu-java-web-app-build-1-build-pod › prepare
+ tanzu-java-web-app-build-1-build-pod › prepare
+ tanzu-java-web-app-build-1-build-pod > completion

Expected behavior

Expected to see one entry for each init container.

+ tanzu-java-web-app-build-1-build-pod › prepare
+ tanzu-java-web-app-build-1-build-pod > completion

Steps to Reproduce

Run tanzu apps workload tail command against build service pod(that has multiple init containers).

Version (Apps plugin version, Version of K8s running on cluster)

Tanzu apps v0.4.0+

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

any/all

Additional context & Relevant Debug Output (Logs, etc)

Issue originally submitted by @shashwathi

Please fill out the issue checklist below and provide ALL the requested information.

• I reviewed open and closed Github issues that may be related to my problem.
• I am reporting a bug that others will be able to reproduce.

Describe the bug

There are currently two boolean flags that can be set via command flags and/or workload.yaml:

• --live-update
• --debug
  The apps plugin validates the values passed via command flags today and will throw an error if a non-boolean value is provided (e.g. --debug foo will fail validation).

However, it's possible to set spec.params.debug or spec.params.live-update to a value of foo and submit the workload.yaml without error.

Expected behavior

apps plugin should throw an error if/when workload.yaml includes non-boolean values for boolean workload spec properties.

Steps to Reproduce

1. create a workload using the following workload.yaml

   ---
   apiVersion: carto.run/v1alpha1
   kind: Workload
   metadata:
     labels:
       app.kubernetes.io/part-of: pc
       apps.tanzu.vmware.com/workload-type: web
     name: pc
     namespace: default
   spec:
     params:
     - name: live-update
       value: foo
     - name: debug
       value: bar
     source:
       git:
         ref:
           tag: tap-1.1
         url: https://github.com/sample-accelerators/spring-petclinic
   

Version (Apps plugin version, Version of K8s running on cluster)

Put the output of the following command

tanzu version && tanzu apps version
version: v0.11.2
buildDate: 2022-03-17
sha: 9f16f375
v0.5.1

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

Additional context & Relevant Debug Output (Logs, etc)

cc @shashwathi (Hey Shash - I ended up logging this bug since I didn't see it this morning).

Please fill out the issue checklist below and provide ALL the requested information.

• I reviewed open and closed Github issues that may be related to my problem.
• I am reporting a bug that others will be able to reproduce.

Describe the bug

When user removes a namespace from a previously created --service-ref entry which originally included namespace, the apps plugin doesn't think there's anything to change so the update is skipped.

Expected behavior

removal of namespace should trigger an update to the --service-ref claim

Steps to Reproduce

1. add the following --service-ref to an existing workload:

• tanzu apps workload apply [my-app] --service-ref my-db=rabbitmq.com/v1beta1:RabbitmqCluster:my-namespace:my-broker

1. update the my-db service-ref (remove :my-namespace):

• tanzu apps workload apply [my-app] --service-ref my-db=rabbitmq.com/v1beta1:RabbitmqCluster:my-broker

The result of the update should be that the my-namespace portion of the service-ref should be removed (after the diff is displayed and user-prompt accepted)

Version (Apps plugin version, Version of K8s running on cluster)

apps version v0.4.0+

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

TAP v0.5.0 on GKE

Please fill out the issue checklist below and provide ALL the requested information.

• I reviewed open and closed Github issues that may be related to my problem.
• I am reporting a bug that others will be able to reproduce.

Describe the bug

The cli attempts to parse the time stamp coming from the k8s api in the logs so that it can print the time in user's timezone. K8s returns time stamps inline with the log output as a prefix for each line. CLI prints error “unable” when log line is not regular log output but is being interpreted as a log line.

Expected behavior

Consider not parsing the log line for these special logs.

Steps to Reproduce

Have any application that logs without timestamps as part of the app logs. Example errors reported from customer using sample tanzu java web app.

Snippet

unexpected error: parsing time "unable" as "2006-01-02T15:04:05.999999999Z07:00": cannot parse "unable" as "2006"
unexpected error: parsing time "rpc" as "2006-01-02T15:04:05.999999999Z07:00": cannot parse "rpc" as "2006"

Version (Apps plugin version, Version of K8s running on cluster)

Put the output of the following commad
Apps plugin v0.4.0+

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

Additional context & Relevant Debug Output (Logs, etc)

Issue originally submitted by @shashwathi

Description of problem

I'd like to get a list of workloads in json format for scripting and programmatic parsing.

Proposed solution

Given I do `tanzu apps workload list --output json`
Then I see output of current information in json format

• I reviewed open and closed Github issues that may be related to my problem.
• I am reporting a bug that others will be able to reproduce.

Describe the bug

if there are two or more example commands included in the help, only the first command is indented.
all the example commands should be indented

Expected behavior

all the example commands in help should be indented

Steps to Reproduce

1. download and install the appstack cli commands plugin
2. execute tanzu apps workload create -h
3. notice the indentation for the second and third examples:

$ tanzu apps workload create -h
Create a workload with specified configuration.

Workload configuration options include:
- source code to build
- runtime resource limits
- environment variables
- services to bind

Usage:
    tanzu apps workload create [name] [flags]

Examples:
    tanzu apps workload create my-workload --git-repo https://example.com/my-workload.git
tanzu apps workload create my-workload --local-path . --source-image registry.example/repository:tag
tanzu apps workload create --file workload.yaml

...

Version (Apps plugin version, Version of K8s running on cluster)

Put the output of the following commad

tanzu version && tanzu apps version

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

Plugin version: apps:v0.5.1
k8s version (server): GitVersion:"v1.23.3+vmware.1"
MacOS, Docker Desktop

Originally submitted by

@codegold79

Description of problem

Many enterprises leverage a private intermediate signing authority to issue/manage their certificates. This intermediate CA cert must be distributed to all systems participating in the PKI.

When they deploy a private image registry such as harbor, all k8s clusters and clients interacting directly with the registry require this intermediate CA.

There's work underway to add support for private CA's to the various components of TAP on the server side, but when using the tanzu apps workload create xxx --local-path . command to create a workload from sources on developer workstation, it surfaces an issue in that there's no way to configure the tanzu CLI to pick up local CA certificates.

The most expeditious flow for demonstration of TAP accelerators is to create a workload directly off the downloaded accelerator assets. This surfaces the issue in that a developer cannot do this with TAP today if they are using private enterprise certificates to protect their registry.

Our only option now is to apply a series of TAP server-side workarounds to deploy enterprise CAs server-side, create a git-repo push sources to this location and finally use the --git-repo option to get workloads to create in TAP today when deployed against a private / enterprise registry.

Proposed solution

Provide tanzu cli with an "--insecure-skip-tls-verify" option -- not aligned with our "secure always" narrative
Provide tanzu cli with a "--ca-certs" option

Additional context

Originally submitted by @tfynes-pivotal

Description of problem

Developers will provide the same flags/values repeatedly when iterating on their application code.
Typing or copy/pasting those same flag values for every workload create/update/apply adds friction to the developer workflow.
We should make it possible for the user to configure/persist sane defaults for a subset of the supported flags such that they can execute their commands without having to provide the same flag/values repeatedly.

Proposed solution

• Support setting and unsetting config values for specific flags supported in workload create/update/apply commands.
• Where a configured value for a given flag exists, use the value.
• Where no flag or config value is provided for a required flag, throw an error
• Where flag/value has been provided AND a config value exists, the flag value takes precedence
• this command doesn't accept any positional args or flags/values - it's interactive (based on the cobra library)

Flags targeted for configuration (configurable flags should be listed in alphabetical order in the UI)

1. caCertsPath
2. debug
3. file
4. live-update
5. local-path
6. password
7. source-image
8. sub-path
9. token
10. username

Command and Interactions:

Listing / checking config (styling based on the cobra implementation used by tanzu login)

if user starts typing, the options displayed are filtered
user can use up/down arrow keys to move the ">" to their desired selection
hitting triggers edit mode.

$ tanzu apps config
? Select option [Use arrows to move, type to filter]
   caCertsPath     (not set)
> debug            (false)
  file             (not set)
  live-update      (false)
  local-path       (not set)
  password         (not set)
  source-image     (not set)
  sub-path         (not set)
  token            (not set)
  username         (not set)

username
password

Setting key that expects a bool

If user hits from the selected option and the selected option is a boolean, the UI should update as follows:

$ tanzu apps config
? Select option [Use arrows to move, type to filter]
Enable debug by default?
> true
  false   (default)

  --debug=true will be set by default when creating or updating workloads.
  
  This default can be overridden by using a --debug=false flag
  example: "tanzu apps workload update NAME --debug=false" 
$

Setting key that expects a string

Example below assumes user has clicked on "local-path" select option...

$ tanzu apps config
? Select option [Use arrows to move, type to filter]
? Set local-path: <user-entered-value-goes-here>

  --local-path will be set to <user-entered-value-goes-here> by default for any command that accepts the flag
  
   The --local-path flag will take precedence over the default.
   example: "tanzu apps workload update NAME --local-path value" 
$

the --local-path will be set to.... message should be displayed only after the user submits the value
upon submission, the config value is saved, confirmation text and other messaging is displayed and the command exits 0

Configuration UX when values have been previously configured

$ tanzu apps config
? Select option [Use arrows to move, type to filter]
  caCertsPath      (not set)
  debug            (true)
  file             (my-workload.yaml)
  live-update      (false)
> local-path       (.)
  password         (not set)
  source-image     (gcr.io/pivotal-knative/jc-apps)
  namespace        (not set)
  sub-path         (not set)
  token            (not set)
  username         (not set)
...

Unsetting key that expects a string

Example below assumes user has clicked on "local-path" select option...
Upon selection, the entry "area" is blank and if user hits the value will be unset

$ tanzu apps config
? Select option [Use arrows to move, type to filter]
? Set local-path: 

  --local-path value is not set
$

Help Text

$tanzu apps -h

Applications on Kubernetes

Usage:
  tanzu apps [command]

Aliases:
  apps, app

Available Commands:
  cluster-supply-chain   Patterns for building and configuring workloads
  config                 Configuration for the apps CLI plugin
  workload               Workload lifecycle management

Implementation Notes/questions

the config file should be stored at ~/.config/tanzu/apps/config.yaml

Describe alternatives you've considered

1. Set config values via ENVVARS - as per #114 (which we will not be implementing)
2. provide flag values via file that are merged together (e.g. tanzu apps workload apply hello-world -f workload.yaml -f overlays.yaml) -- suggested by @scothis

Additional context

Add any other context or screenshots about the feature request here.

Description of problem

Today when a user executes a command against a TAP cluster without a developer namespace, the command seems to work, and the subsequent errors have not been helpful with the troubleshooting process.

Proposed solution

Given I create an application
When the targeted namespace has not been prepared, or I do not have sufficient permissions to use it
Then I should get an alert informing me, and the workload should not be sent to the cluster. 

Example

Success case

$ tanzu apps workload create NAME <flags>
[silent check for presence of secrets/creds … ok]
<show diff>
<show confirmation prompt>

Failure case

$ tanzu apps workload create NAME <flags>
[silent check for presence of secrets/creds … uh oh]
Alert: Workload cannot be created, necessary credentials and secrets are not found in the current namespace. Please check that you have chosen a namespace that has been prepared for development. 

Describe alternatives you've considered

Updating docs to make the developer namespace setup step more prominent (this has been done)

Adding a type column to a listing of namespaces (there is not a namespace resource in the CLI currently)

$ tanzu namespace list

NAMESPACE      CLUSTER     TYPE    
example 1      name1       run 
example 2      name2       iterate
example 3      name2       iterate

Adding something to context awareness / context plugin to inform folks about the composition of the cluster/namespace

$tanzu context get

Current context is <name>
Using [type] namespace <name> 
within [iterate|build|run|view] cluster <name> 

Additional context

Question: Is it possible to differentiate between permissions failure and absence of needed certs/secrets/ role bindings?

Description of problem

For application developers, It is not as easy to check the state of the supply chain as it could be.

As an application developer, I would like to know if the supply chain is processing my changes or has finished applying them.

As an application developer, if the supply chain is unable to deploy my workload or apply my changes, I would like to understand where it got stuck and why.

Proposed solution

Status Case

Given I create/update a workload
When I check the details of the workload (workload get)
Then I should see which supply chain picked up my workload, and if it is running or completed.

*Source*
type:     git
url:      https://github.com/sample-accelerators/spring-petclinic.git
branch:   main
tag:      tap-1.0

*Supply Chain*
name:          web
last update:   4min ago
status:        healthy

RESOURCE           READY       TIME        
source-provider    True        9m ago
deliverable        True        9m ago
image-builder      True        8m ago
config-provider    True        8m ago
app-config         True        8m ago
config-writer      True        8m ago

*Issues*
No issues reported

*Pods*
NAME                                 STATUS      RESTARTS   AGE
petc-adhol-build-1-build-pod         Succeeded   0          2d3h
petc-adhol-config-writer-7ctp7-pod   Succeeded   0          2d3h
petc-adhol-config-writer-9fdv4-pod   Succeeded   0          72m

*Knative Services*
NAME         READY   URL
petc-adhol   Ready   http://petc-adhol.default.apps.34.85.152.116.nip.io/

Troubleshooting case

Given I create/update a workload
When I check the details of the workload (workload get)
Then I should see which supply chain picked up my workload if one has, otherwise I should see that no supply chain has matched. If the supply chain has picked up my workload and was not successful, I should see where it got stuck and why.

*Source*
type:     git
url:      https://github.com/sample-accelerators/spring-petclinic.git
branch:   main
tag:      tap-1.0

*Supply Chain*
name:          web
last update:   4min ago
status:        healthy

RESOURCE           READY       TIME        
source-provider    True        9m ago
deliverable        True        9m ago
image-builder      False       8m ago
config-provider    Unknown     
app-config         Unknown     
config-writer      Unknown     

*Issues*
reason: MissingValueAtPath
message: waiting to read value [.status.latestImage] from resource [image.kpack.io/petc-half-dead] in namespace [ns2]

*Pods*
NAME                                 STATUS      RESTARTS   AGE
petc-adhol-build-1-build-pod         Succeeded   0          2d3h
petc-adhol-config-writer-7ctp7-pod   Succeeded   0          2d3h
petc-adhol-config-writer-9fdv4-pod   Succeeded   0          72m

*Knative Services*
NAME         READY   URL
petc-adhol   Ready   http://petc-adhol.default.apps.34.85.152.116.nip.io/

Describe alternatives you've considered

A clear and concise description of any alternative solutions or features you've considered.

• Summary view, showing only the overall status and printing issues when there are any

Supply Chain
name:          web
last update:   4min ago
status:        healthy

Issues
no issues reported

• Status table - including outputs (similar to kubectl tree)

RESOURCE           STATUS    TIME       MESSAGE
Source Provider    healthy   9m ago
└─ Source code: [711a2d65b35d2cf2704beb01b5ea409d51eb4225.tar.gz](http://source-controller.flux-system.svc.cluster.local./gitrepository/default/tanzu-java-web-app/711a2d65b35d2cf2704beb01b5ea409d51eb4225.tar.gz)
Image Builder      unhealthy    8m ago    waiting to read value [.status.artifact.url] from resource [gitrepository.source.toolkit.fluxcd.io/petc] in namespace [default]
└─ Image:
Config Provider    unknown   22h ago
└─ Pod Intent:
App Config         unknown   22h ago
└─ delivery.yml:
Config Writer      unknown   21h ago

• Step by step status list - including outputs

Source Provider
Status:    success
Since:     8m ago
Output:    http://source-controller.flux-system.svc.cluster.local./gitrepository/default/petc/b458a176d4fd67cdcf9e1c7eaa98b7a3c748a2ca.tar.gz

Image Builder
Status:    success
Since:     8m ago
Output:    [harbor.contour.e2e.corby.cc/tap/supply-chain/spring-sensors-default@sha256:7ec6c5f20548f9afd4940a604e69878cd02eee2ae1cbfe0ba8b12de096095a9d](https://tap-gui.contour.e2e.corby.cc/supply-chain/default/spring-sensors/harbor.contour.e2e.corby.cc/tap/supply-chain/spring-sensors-default@sha256:7ec6c5f20548f9afd4940a604e69878cd02eee2ae1cbfe0ba8b12de096095a9d)

Config Provider
Status:    success
Since:     8m ago
Output:    sha256:aa473c5ebed86b233de96bf53b3ad6eee6108bf655236c36a418cfd5beb2abb6

App Config
Status:    success
Since:     8m ago
Output:    sha256:4a3285f7b95e781565268e6175b86d291bd0417ff22d3231583d48c9b32430fe

Config Writer
Status:    success
Since:     8m ago
Output:    Ready

Additional context

Add any other context or screenshots about the feature request here.

Description of problem

As of #76, it's possible to CRUD the workload spec.serviceAccountName via workload.yaml
As the community engages more deeply with TCE's App Toolkit, the desire/need to specify a non-default serviceAccountName for individual workloads is likely to increase over time.
Providing the --serviceAccountName flag will facilitate doing so for those who don't have the skill or desire to engage with yaml.

Proposed solution

new service-account flag

Given i have a workload to CRUD
When i provide "--service-account foo" in my "workload create/update/apply"
Then my submitted workload object will include "spec.serviceAccountName: foo" property/value

REMOVED THIS REQUIREMENT
new service-account flag alias

Given i have a workload to CRUD
When i provide "--sa foo" in my "workload create/update/apply"
Then my submitted workload object will include "spec.serviceAccountName: foo" property/value

delete service-account approach

Given i have a workload which has a `spec.serviceAccountName: foo` to CRUD
When i provide "--service-account '' (single or double quotes should be acceptable)
 " in my "workload create/update/apply"
Then my submitted workload object will delete the "spec.serviceAccountName: foo" property/value

Example

<Code snippets that illustrate the when/then blocks>

Describe alternatives you've considered

Providing support only via -f workload.yaml

cc @kartiklunkad26

Description of problem

adding support for --export to tanzu apps workload apply will make the tilt file command simpler/more efficient otherwise devs will have to specify tanzu apps workload apply, then tanzu apps workload get --export. Seems a little unwieldy.

If adding this support to apply - we should add it to workload create and workload update for consistency (so far all the commands have the same flags and we're setting an expectation).

Proposed solution

When --export is passed in with create/update/apply, Expect it to return the workload just created/updated/applied.

Given I have a compliant workload.yaml for my-app
When I create or update my-app workload and include the --export flag (or the --export and --output=yaml/yml flags/values) in my incantation
Then the output  from the command, displayed after confirming the prompt, contains only the content that would be returned if I were to have run "tanzu apps workload get my-app --export"  

Given I have a compliant workload.yaml for my-app
When I create or update my-app workload and include the --export and --output=json flags/values in my incantation
Then the output  from the command, displayed after confirming the prompt, contains only the content that would be returned if I were to have run "tanzu apps workload get my-app --export --output json"  

Given I have a compliant workload.yaml for my-app
When I create or update my-app workload and include the --export and --output=json flags/values in my incantation
Then the output  from the command, displayed after confirming the prompt, contains only the content that would be returned if I were to have run "tanzu apps workload get my-app --export --output json"  

Given I have a compliant workload.yaml for my-app
When I create or update my-app workload and include the --export and --yes and --output=json flags/values in my incantation
Then the output  from the command is displayed without user-prompt and contains only the content that would be returned if I were to have run "tanzu apps workload get my-app --export --output json"

Given I have a compliant workload.yaml for my-app
When I create or update my-app workload and include the --export and --yes and --output=json flags/values in my incantation, but some error occurs which prevents the workload object from becoming available within the timeout period (default 10 minutes)
Then then output  from the command is "[]"

Given I have a compliant workload.yaml for my-app
When I create or update my-app workload and include the --export and --yes and --output=yaml/yml flags/values in my incantation, but some error occurs which prevents the workload object from becoming available within the timeout period (default 10 minutes)
Then then output  from the command is "---"

Examples

Current UX: (--export isn't supported)

03/17/22-15:28:59 tanzu % tanzu apps workload create -f app-assets/valid-yaml.yaml
Create workload:
      1 + |---
      2 + |apiVersion: carto.run/v1alpha1
      3 + |kind: Workload
      4 + |metadata:
      5 + |  labels:
      6 + |    app.kubernetes.io/part-of: tanzu-java-web-app
      7 + |    apps.tanzu.vmware.com/has-tests: "true"
      8 + |    apps.tanzu.vmware.com/workload-type: web
      9 + |  name: tanzu-java-web-app-2-6
     10 + |  namespace: default
     11 + |spec:
     12 + |  source:
     13 + |    git:
     14 + |      ref:
     15 + |        branch: spring-boot-2.6
     16 + |      url: https://github.com/odinnordico/tanzu-java-web-app

? Do you want to create this workload? Yes
Created workload "tanzu-java-web-app-2-6"

Proposed UX (--export and --yes included)

• if --yes hasn't been provided and prompt should be triggered.
• --output/-o should support json or (yaml or yml) (default output: yaml)

03/17/22-15:28:59 tanzu % tanzu apps workload create -f app-assets/valid-yaml.yaml --export --yes
---
apiVersion: carto.run/v1alpha1
kind: Workload
metadata:
  labels:
    app.kubernetes.io/part-of: tanzu-java-web-app
    apps.tanzu.vmware.com/has-tests: "true"
    apps.tanzu.vmware.com/workload-type: web
  name: tanzu-java-web-app-2-6
  namespace: default
spec:
  source:
    git:
      ref:
        branch: spring-boot-2.6
      url: https://github.com/odinnordico/tanzu-java-web-app
03/17/22-15:29:13 tanzu %

Proposed UX (--export and -o json and --yes included)

 03/17/22-15:28:59 tanzu % tanzu apps workload create -f app-assets/valid-yaml.yaml --export -o json
{
  "apiVersion": "carto.run/v1alpha1",
  "kind": "Workload",
  "metadata": {
    "labels": {
      "app.kubernetes.io/part-of": "tanzu-java-web-app",
      "apps.tanzu.vmware.com/has-tests": "true",
      "apps.tanzu.vmware.com/workload-type": "web"
    },
    "name": "tanzu-java-web-app-2-6",
    "namespace": "default"
  },
  "spec": {
    "source": {
      "git": {
        "ref": {
          "branch": "spring-boot-2.6"
        },
        "url": "https://github.com/odinnordico/tanzu-java-web-app"
      }
    }
  }
}
03/17/22-15:29:13 tanzu %

Describe alternatives you've considered

• requiring two commands as is current
• providing --export silently implies --yes

Additional context/requirements

1. is --yes assumed?
   • Answer: No. We will not assume yes. Users/scripts will need to provide that.
2. should we support -o yaml/json when --export is provided?
   • Answer: Yes --- default should be yaml
3. help output - explanation
   • @danfein can you provide this content?
4. error cases
   • see gherkin's above

open questions:

• need to have a timeout be automatically applied (same as the --wait-timeout default value)
  • but should we actually generic-ize the timeout flag name to --timeout? so it can be used with --wait or --export

Description of problem

• Currently there is not a way for someone to specify a sub-section of a repo or a local project directory to create/update their workload from.
• Additionally, if there is a code change anywhere in the repo, any workload that references the repo will be rebuilt, even if there are no changes in the workload code.

Original comment from Oded Shopen, TSL:

Hi. We need a --sub-path parameter for tanzu apps workload create, similar to how it works in TBS.
Many GIT ?repositories contain many sub-modules in the same project, so we need to let the pipeline know which sub-path we want to use for the workload creation.

Proposed solution

Given I'm currently in the root directory of project in A which includes sub-component dirs B and C
When I run "tanzu apps workload create/update/apply my-app --local path . --sub-path B/
Then the entire contents of my project are uploaded and the workload object includes both spec.source.image=source-image-reference and spec.source.subPath=B

If an absolute path is provided for the sub-path value (for either --git* or --local-path), and the sub-path is legit, the plugin should be able to handle that scenario gracefully (meaning - it should work and not error).

Open Questions:

• can the sub-path be changed after workload creation?
• can the sub-path be removed after workload creation?
• can you just pass in sub-path in a workload update/apply (for existing workload - with and/or without previously configured sub-path)
• can/should it be possible to remove --sub-path if previously set? (this question is broader than just sub-path
  • if we decide on a pattern for this, we must apply it to other flags (limit-cpu, limit-memory, request-cpu, request-memory)

Error Cases:

• --sub-path value provided doesn't match a directory under what's provided for --local-path
• --sub-path and local-path point to same directory
• --sub-path value provided without --git* or --local-path
• --sub-path points to an individual file which isn't a JAR/ZIP (discuss - is a single file sufficient to run a workload?)

Autocomplete:

• --local-path (to a directory on the filesystem) -- auto-complete sub-directories under the --local-path directory
• --local-path (to a JAR/Zip) -- auto-complete to directory structure (discuss implementation complexity/cost)
• --git* -- auto-complete sub-directory (discuss implementation complexity/cost)

Describe alternatives you've considered

• (sub-section problem) Pull code down and deploy the subsection locally
• (rebuilding on changes problem) Could use --git-sha to manually specify which commit to build from
• sub-path was legitimate in original workload creation, then in subsequent update/apply, refers to a --local-path directory which doesn't include the directory originally set for sub-path -- what happens?
• sub-path no longer exists in gitHub after a commit has been made -- what happens?

Next Steps:

[ ] Additional feedback on how common it is to have multiple buildable workloads in a single repo to better understand the usecase(s).
[ ] Investigate feasibility of the underlying components (build service, supply chain) and how they might support the described behavior

Additional context

Issue originally submitted by @danfein

Description of problem

When it exists, the URL to the running workload is included in tanzu apps workload get.... output.
However, the URL isn't included in the output if the user runs that command with -o json/yaml.

Proposed solution

show the url that is included in the workload get command i.e. the last line in the output

Given workload A has been created, and a knative service has been successfully created
When I run `tanzu apps workload get A -o json (or yaml)`
Then I can see the URL in the output

Example

# tanzu-java-web-app: Ready
---
lastTransitionTime: "2022-02-12T04:45:10Z"
message: ""
reason: Ready
status: "True"
type: Ready

Workload pods
NAME                                                   STATUS      RESTARTS   AGE
tanzu-java-web-app-00002-deployment-7465d4848f-8s5k5   Running     0          5d22h
tanzu-java-web-app-build-1-build-pod                   Succeeded   0          6d2h
tanzu-java-web-app-config-writer-n5csw-pod             Succeeded   0          6d2h
tanzu-java-web-app-config-writer-s8d2j-pod             Succeeded   0          5d22h

Workload Knative Services
NAME                 READY   URL
tanzu-java-web-app   Ready   http://tanzu-java-web-app.default.usability-testing.tlc.dev/

But this URL and the pods is not visible when using -o json or -o yaml which is the way we normally consume this command

Alternatives considered

The alternative would be for us to use the k8s API to fetch that information manually, but I think that if this info is already fetched and aggregated by the CLI it would be great if we could use it

Additional context

Ideally we would like to provide users with an agnostic reachable url, independent of knative if that's how their cluster is setup

originally reported by @suarezjulian

Description of problem

This is the initial implementation of this feature.
We'll extend this feature via #132.

As more systems around us adopt the "as code" approaches, application developers will increasingly have files in their projects that have nothing to do with actually running code (those files don't end up in the running container).

This impacts the usability of --local-path as it:

• consumes resources unnecessarily (uploads code that isn't required)
• triggers automatic, time consuming, deployments (when --live-update or --debug is enabled/re-enabled) whenever any of those unnecessary files change.

Proposed solution

1. feature supported in workload create/update/apply
2. applies only to iterative development when --local-path is provided
3. expect the .tanzuignore to be in the root of --local-path value
4. implement a .tanzuignore file where users can provide the list of patterns to ignore.
5. each file/directory-name should be new-line delimited
6. relative paths to individual files are supported
7. relative path to directories are supported
8. comments (strings preceeded by # on any line in the file) should be "ignored" from the ignore file
9. show info/warning when a .tanzuignore file, with >= 1 entry, exists in the root of --local-path value

info message to display immediately following the command

• file exists and able to read it:
  • The files and/or directories listed in the .tanzuignore file are being excluded from the uploaded source code.
• file exists and unable to read it:
  • Unable to read .tanzuignore file.

Given I am in the root directory of my app project and the project includes extraneous `.foo` files AND extraneous files in the `bar` directory
When I execute 'tanzu apps workload create/apply --local-path .'  for the first time against my target cluster/namespace
Then all `*.foo` files and files in the `bar` directory are not included in the code that's uploaded

Given I am in the root directory of my app project AND the project includes extraneous `.foo` files AND extraneous files in the `bar` directory AND I've previously created a workload from my app project AND I've only updated extraneous files since the workload was initially created
When I execute workload update/apply --local-path . 
Then I see the "Workload is unchanged, skipping update" message

Given I am in the root directory of my app project AND the project includes extraneous `.foo` files AND extraneous files in the `bar` directory AND I've previously created a workload from my app project AND I've only updated extraneous files since the workload was initially created
When I execute workload update/apply --local-path .  --live-update
Then I see the "Workload is unchanged, skipping update" message

Describe alternatives you've considered

• use an --exclude flag on a per-command basis
• use .gitignore (if exists) --- not a good candidate because there may be files a user DOES want to include in the build, but DOESN'T want to commit.
• use .dockerignore - could be good but we're going to just pass the values into imgpkg and the patterns supported in dockerignore may not be supported properly.

Additional context

Prior art for review:

• https://docs.github.com/en/get-started/getting-started-with-git/ignoring-files
• https://www.perforce.com/manuals/p4vs/Content/P4VS/managing.excluding.html
• https://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-ignore.html
• https://marketplace.visualstudio.com/items?itemName=AdamWulkiewicz.ExcludeFromBuild
• https://www.jetbrains.com/help/idea/compiler-excludes.html

cc @paulcwarren