vmware-tanzu / apps-cli-plugin Goto Github PK
View Code? Open in Web Editor NEWApps Plugin for the Tanzu CLI
License: Apache License 2.0
Apps Plugin for the Tanzu CLI
License: Apache License 2.0
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.
removal of namespace should trigger an update to the --service-ref claim
tanzu apps workload apply [my-app] --service-ref my-db=rabbitmq.com/v1beta1:RabbitmqCluster:my-namespace:my-broker
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)
apps version v0.4.0+
TAP v0.5.0 on GKE
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.
Consider not parsing the log line for these special logs.
Have any application that logs without timestamps as part of the app logs. Example errors reported from customer using sample tanzu java web app
.
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"
Put the output of the following commad
Apps plugin v0.4.0
+
Issue originally submitted by @shashwathi
Extra logging data display while the log verbose level is not set or 0. See the example below.
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
API Error name:tanzu apps error:workloads.carto.run "spring-petclinic" not found
N/A
This issue was introduced while updating a newer version of the go-logr
interface.
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
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`
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.
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
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.
Remove tanzu-framework dependency from the Apps plugin.
p := &cobra.Command{}
and map to the required fields used in PluginDescriptor{}
info
that returns required data fields in json format. See example belowtanzu 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":""}
N/A
N/A
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.
I expect to get the workload URL when I run tanzu apps workload get
tanzu apps workload get
, you'll see the below output.---
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
Kubernetes version - v1.22.4
tanzu version
buildDate: 2022-03-24
sha: 6431d1d
tanzu apps version - v0.5.1
TCE v0.11
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.
Update existing tests as needed to conform to the new standard or reconciler-runtime using https://pkg.go.dev/dies.dev
n/a
n/a
n/a
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.
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
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
tanzu apps cluster-supply-chain list
NAME READY AGE
source-test-scan-to-url Ready 38h
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).
Add any other context or screenshots about the feature request here.
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).
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
<Code snippets that illustrate the when/then blocks>
A clear and concise description of any alternative solutions or features you've considered.
Add any other context or screenshots about the feature request here.
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.
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).
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)--git-sha
to manually specify which commit to build from--local-path
directory which doesn't include the directory originally set for sub-path -- what happens?[ ] 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
Issue originally submitted by @danfein
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.
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.
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
A clear and concise description of any alternative solutions or features you've considered.
Dependent on prior story to include the source information section to the workload get output.
Add PR Template
Add PR Template
n/a
n/a
n/a
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.
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
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)
...
Originally submitted by @warango4
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.
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/
A clear and concise description of any alternative solutions or features you've considered.
Supply Chain
name: web
last update: 4min ago
status: healthy
Issues
no issues reported
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
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
Add any other context or screenshots about the feature request here.
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 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.
A clear and concise description of any alternative solutions or features you've considered.
Original issue reported by @danfein
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.
workload create/update/apply
commands.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
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"
$
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
$ 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)
...
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
$
$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
the config file should be stored at ~/.config/tanzu/apps/config.yaml
tanzu apps workload apply hello-world -f workload.yaml -f overlays.yaml
) -- suggested by @scothisAdd any other context or screenshots about the feature request here.
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.
This command:
tanzu apps workload create my-app --git-url https://github.com/spring-projects/spring-petclinic
should just work.
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
tanzu apps wld
and tanzu apps csc
should work.
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:
--live-update
or --debug
is enabled/re-enabled) whenever any of those unnecessary files change.--local-path
is provided.tanzuignore
to be in the root of --local-path
value.tanzuignore
file where users can provide the list of patterns to ignore..tanzuignore
file, with >= 1 entry, exists in the root of --local-path
valueinfo message to display immediately following the command
.tanzuignore
file are being excluded from the uploaded source code..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
cc @paulcwarren
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).
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 "---"
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)
--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 %
--yes
assumed?
-o yaml/json
when --export
is provided?
yaml
--wait-timeout
default value)
--timeout
? so it can be used with --wait
or --export
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.
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
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.
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.
Issue originally reported by @danfein
There are currently two boolean flags that can be set via command flags and/or workload.yaml:
--live-update
--debug
--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.
apps plugin should throw an error if/when workload.yaml includes non-boolean values for boolean workload spec properties.
---
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
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
cc @shashwathi (Hey Shash - I ended up logging this bug since I didn't see it this morning).
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.
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
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 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
Run tanzu apps workload tail
command against build service pod(that has multiple init containers).
Tanzu apps v0.4.0+
any/all
Issue originally submitted by @shashwathi
Current --help output is too long.
Anything we can do to shorten the copy without compromising clarity should be done.
These changes should be applied to --help output from:
tanzu apps workload create...
tanzu apps workload update...
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.
flag is repeatable
flag may be repeated
can be repeated
can be used multiple times
repeatable
Add any other context or screenshots about the feature request here.
Add Security Document
Adding Security Document
n/a
n/a
n/a
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
.
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.
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
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.
tanzu apps workload tail my-app --recent
tanzu apps workload tail my-app --recent --pod my-app-build-3-build-pod
my-app-build-3-build-pod
, ordered by timestamp ascending.tanzu apps workload tail my-app --recent --pod my-app-build-3-build-pod --pod my-app-config-writer-xgx4q-pod
my-app-build-3-build-pod
and my-app-config-writer-xgx4q-pod
, ordered by timestamp ascending.tanzu apps workload tail -h
--pod string pod to tail logs from (flag can be used multiple times)
--recent provide the most recent 100 log lines
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.
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
workload.yaml snippet
---
apiVersion: carto.run/v1alpha1
kind: Workload
metadata: {}
spec:
...
serviceAccountName: <string>
...
provide documentation instructing the user to use kubectl
.
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".
tanzu apps workload list --namespace foo
No workloads found.
tanzu apps workload list --namespace foo
Error: namespace "foo" not found
Error: exit status 1
✖ exit status 1
tanzu apps workload list --namespace foo
Error: user "user-name" has insufficient permissions to view namespace "foo"
Error: exit status 1
✖ exit status 1
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
tanzu apps workload list --namespace bogus-namespace
all versions
Add any other context about the problem here.
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
.
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
# 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
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
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
<Please describe your proposed solution, preferably in the following style:>
Given <Some Condition>
When <Something Happens>
Then <This other thing should happen?>
<Code snippets that illustrate the when/then blocks>
A clear and concise description of any alternative solutions or features you've considered.
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
Remove unused codecov-action
Remove unused codecov-action
n/a
n/a
n/a
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
--git-branch
or --git-tag
) when --git-commit
is providedIssue originally submitted by @warango4
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
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 the behavior:
tanzu apps workload apply/update
command that would change the workload and doesn't also include the --file
flag.Custom build from main HEAD fc7b718
Add any other context about the problem here.
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.
Given <Some Condition>
When <Something Happens>
Then <This other thing should happen?>
<Code snippets that illustrate the when/then blocks>
A clear and concise description of any alternative solutions or features you've considered.
Add any other context or screenshots about the feature request here.
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.
$ 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
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
$ 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
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
Apps Plugin version 0.5.1
I'd like to get a list of workloads in json format for scripting and programmatic parsing.
Given I do `tanzu apps workload list --output json`
Then I see output of current information in json format
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.
tanzu apps workload list
when my KUBECONFIG is not set/emptypanic: 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
Error: invalid configuration: no configuration has been provided, try setting KUBERNETES_MASTER environment variable
Error: exit status 2
✖ exit status 2
tanzu apps workload list
when my KUBECONFIG is pointing to a cluster that is not accessible/deletedpanic: 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
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
Apps plugin v0.5.1
macOS Monterey v12.3
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.
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
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).
FLAG | ENV VAR |
---|---|
- |
|
- |
|
--registry-ca-cert | TANZU_APPS_REGISTRY_CA_CERT |
--registry-password | TANZU_APPS_REGISTRY_PASSWORD |
--registry-username | TANZU_APPS_REGISTRY_USERNAME |
--registry-token | TANZU_APPS_REGISTRY_TOKEN |
--type | TANZU_APPS_TYPE |
*NOTE: |
use only configurable values
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
all the example commands in help should be indented
$ 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
...
Put the output of the following commad
tanzu version && tanzu apps version
Plugin version: apps:v0.5.1
k8s version (server): GitVersion:"v1.23.3+vmware.1"
MacOS, Docker Desktop
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
.
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 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
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
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
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
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.
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
Originally submitted by @tfynes-pivotal
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
subPath shouldn't be removed
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.
If applicable, add screenshots to help explain your problem.
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
tap installed on GKE
client - Mac
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.
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
<Code snippets that illustrate the when/then blocks>
Providing support only via -f workload.yaml
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.
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.
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.
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.
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.
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>
Question: Is it possible to differentiate between permissions failure and absence of needed certs/secrets/ role bindings?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.