Open iancoffey opened 3 years ago
nrb
commented
3 years ago I think this is an interesting question for TCE, too. tanzu version on a TCE install could give some confusing information.
I was able to figure out TCE's version by looking at TCE-only plugins, but that's kind of opaque.
stmcginnis
commented
3 years ago I was thinking about this too based on feedback given in TCE that it's difficult to tell what version is installed.
I think especially since the root tanzu command is really an extensible toolbox to be used by multiple projects/products, we may need to have extended output. I was thinking something like tanzu version would just emit the version of the tanzu executable itself as it does now. But then something like tanzu version -a could print out a table (unless something like -o json is given) that would show the CLI version and the version of each plugin. Optionally, also the edition of the plugin. So something like:
> tanzu version -a
COMPONENT VERSION EDITION
cli v1.3.1 TKG
management-cluster v1.3.1 TCE
package v1.3.1 TKG
standalone-cluster v0.6.0 TCEI like the extended version output.
The plugin list command already gets similar info, but again, it's a little opaque.
% tanzu plugin list
NAME LATEST VERSION DESCRIPTION REPOSITORY VERSION STATUS
alpha v1.3.1 Alpha CLI commands core upgrade available
cluster v1.3.1 Kubernetes cluster operations core upgrade available
login v1.3.1 Login to the platform core upgrade available
management-cluster v1.3.1 Kubernetes management cluster operations core upgrade available
pinniped-auth v1.3.1 Pinniped authentication operations (usually not directly invoked) core upgrade available
kubernetes-release v1.3.1 Kubernetes release operations core upgrade available
builder Build Tanzu components v1.3.0 installed
conformance Run conformance tests against clusters v0.6.0-dev.2 installed
package Package management v0.6.0-dev.2 installed
standalone-cluster Create clusters without a dedicated management cluster v0.6.0-dev.2 installed
test Test the CLI v1.3.0 installed
vuil
commented
3 years ago > tanzu version -a
COMPONENT VERSION EDITION
cli v1.3.1 TKG
management-cluster v1.3.1 TCE
package v1.3.1 TKG
standalone-cluster v0.6.0 TCELike it, but a few thoughts
should cli just be 'special' iow output of -a = output without -a + some component list?
q: what does the TKG edition for package/cli mean for the TCE product? That too is rather confusing.
stmcginnis
commented
3 years ago I like cli, or whatever we would want to call it, so you can get the full set of versions relevant to what is installed locally.
I'm thinking this inclusion could be useful for any kind of automation we need to do for testing, or if we put together some kind of support info gathering scripts that would collect information. Then we could have something like tanzu version -a -o yaml and get something we could programmatically parse like:
- component: cli
version: v1.3.1
edition: tkg
- component: management-cluster
version: v1.3.1
edition: tce
- component: package
version: v1.3.1
edition: tkg
- component: standalone-cluster
version: v0.6.0
edition: tceNot sure if we would want to call it TKG either. But at least from the TCE perspective, we are hoping to only compile the parts where there are differences, so there seems to be some need to have some sort of edition difference. So maybe instead of TKG, it could be just "framework", or even just left blank if there isn't a specific edition designation.
nrb
commented
3 years ago Another issue I've found while trying to introduce a plugin that wraps Sonobuoy: there's only 1 version field on the PluginDescriptor, and it must comply with semantic versioning.
I would like to report, at least for tanzu conformance version, the version of Sonobuoy that is wrapped, but I cannot register that and our own tanzu build version right now. If I do, the following error occurs:
✖ 🦁 - output: F0728 15:22:31.365751 6165 main.go:36] version "conformance" "Sonobuoy Version: v0.52.0\nTanzu Version: v0.7.0-dev.1\n" is not a valid semantic version
randomvariable
commented
2 years ago Supporting -o yaml makes sense, In CAPA, we copied kubectl output to do this.
benjaminapetersen
commented
2 years ago Migrating here from an outside converstation:
~$ tanzu version
tanzu cli version: v0.2.0
tanzu cli buildDate: 2021-09-14
tanzu cli sha: 3add647d-dirty
tkg version: v1.5.0. # management cluster? tkr info? what can be meaningful here?
tmc version: x.y.z
kubectl version: x.y.z
kube server version: x.y.z # handy to bubble up as wellI would lean towards things that are useful to a user more than a developer, however, a flag to dump more information could be beneficial. IE, @randomvariable above has git and go information. I might not want that as a user, but as a dev it is probably helpful. A verbosity control optimized for the user first is probably. 👍
LukeShortCloud
commented
2 years ago For reporting the Tanzu Community Edition (TCE) version, we can extract the version from the "unmanaged-cluster" plugin. This will only ever be found in TCE.
$ tanzu plugin list | grep unmanaged-cluster
unmanaged-cluster Deploy and manage single-node, static, Tanzu clusters. Standalone default-local v0.12.0 installedExample adding TCE version:
$ tanzu version
CLI version: v0.11.4
TCE version: v0.12.0
buildDate: 2022-05-04
sha: a9b8f3aI also like the addition of more detailed version information suggested by @benjaminapetersen !
Describe the feature request What should
tanzu versionoutput? currently it is the version of TKG, but Tanzu is more than just TKGAffected product area (please put an X in all that apply)
[ ] APIs [x] CLI [ ] Docs [ ] Installation [ ] Plugin [ ] Security [x] Test and Release [ ] User Experience
Additional context
Collated Context
Context from 2021-02-05 17:19:00 User: frapposelli Distilled feedback for Tanzu versioning in general, this is the result of long conversations with customers and field.
Context from 2021-02-22 20:22:52 User: jorgemoralespou I would probably do the opposite that @frapposelli suggests. I would definitely have the short version as the default, as that's the binary we're going to be pulling down and have the plugins version as an extended list with
tanzu version --all(or similar) but have less fields shown (no description and no repository). I would expect the plugin list to provide the long verbose list with details.A user looking for versions would use the version command. A user looking for plugins details would use the plugin command.
Context from 2021-03-12 17:27:37 User: timothysc +1 to @jorgemoralespou to both
Context from 2021-05-26 18:04:13 User: vuil
Given that a version of the CLI was shipped with "tanzu version" returning v1.3.0, do we have plans to deviate from this convention for Dakar and other releases?
I recall there were also some discussion about some kind of edition information as part of the version output. That would give the freedom to evolve the tanzu cli version independently while still having a good indication of which release edition it was for.