Tanzu Framework provides a set of building blocks to build atop of the Tanzu platform and leverages Carvel packaging and plugins to provide users with a much stronger, more integrated experience than the loose coupling and stand-alone commands of the previous generation of tools.
Apache License 2.0
197
stars
194
forks
source link
Design Discussion: When does CLI functionality demand a new CLI plugin (statically linked binary) #884
The plugin model of tanzu CLI enables a variety of use cases such as the ability for editions, community members, or ISVs to import their own functionality into Tanzu. However, it also can encourage a pattern where each chunk of functionality ends up in its own statically compiled binary. This has the following negative implications:
Binary sizes grow significantly
For a TCE install, the total binary size is barely shy of 1GB.
Opportunity for version mismatches to occur in plugins that should always be
bound any way.
For example, management-cluster and cluster and wrapping the TKG Library. I can't think of a use case for these to be independently compiled static binaries.
Increased number of artifacts placed across the system
More statically compiled binaries stored in XDG_DATA_HOME and more.
Similar to that of organizations that go all-in on microservices only to realize they've decoupled too much, I'm worried we could end up in a similar trajectory with tanzu CLI. For example, I recently noticed the introduction of the imagepullsecret plugin which has a functional description of:
Manage image pull secret operations. Image pull secrets enable the package and package repository consumers to authenticate to private registries.
In digging into this plugin, it appears to be a 32MB static binary that is tasked with applying, modifying, or deleting a secret object from Kubernetes clusters.
In a similar example, it feels like a lot of functionality under the Run group will always want to be pinned together with the same semantic version. For example, when would you want your cluster plugin to be on version v0.2.4 and your management-cluster plugin on v1.6.2? Similar goes for the kubernetes-release plugin.
On the other hand, I'm not advocating we turn everything into a single binary, however, I am wondering if there's an opportunity here to re-consider how much we're decoupling functionality into separate binaries. Thanks to our use of cobra, it's entirely opaque to users whether commands are sourced from other binaries vs less binaries harboring multiple commands.
Describe alternatives you've considered
We could continue on our current trajectory and ignore the above concern.
Affected product area (please put an X in all that apply)
[x] CLI
[ ] Docs
[ ] Installation
[ ] Plugin
[ ] Security
[ ] Test and Release
[ ] User Experience
Additional context
This conversation started on internal slack and has been brought to this issue for open discussion.
Describe the feature request
The plugin model of
tanzu
CLI enables a variety of use cases such as the ability for editions, community members, or ISVs to import their own functionality into Tanzu. However, it also can encourage a pattern where each chunk of functionality ends up in its own statically compiled binary. This has the following negative implications:Binary sizes grow significantly
Opportunity for version mismatches to occur in plugins that should always be bound any way.
Increased number of artifacts placed across the system
Similar to that of organizations that go all-in on microservices only to realize they've decoupled too much, I'm worried we could end up in a similar trajectory with
tanzu
CLI. For example, I recently noticed the introduction of theimagepullsecret
plugin which has a functional description of:In digging into this plugin, it appears to be a 32MB static binary that is tasked with applying, modifying, or deleting a secret object from Kubernetes clusters.
In a similar example, it feels like a lot of functionality under the
Run
group will always want to be pinned together with the same semantic version. For example, when would you want yourcluster
plugin to be on versionv0.2.4
and yourmanagement-cluster
plugin onv1.6.2
? Similar goes for thekubernetes-release
plugin.On the other hand, I'm not advocating we turn everything into a single binary, however, I am wondering if there's an opportunity here to re-consider how much we're decoupling functionality into separate binaries. Thanks to our use of cobra, it's entirely opaque to users whether commands are sourced from other binaries vs less binaries harboring multiple commands.
Describe alternatives you've considered
We could continue on our current trajectory and ignore the above concern.
Affected product area (please put an X in all that apply)
Additional context
This conversation started on internal slack and has been brought to this issue for open discussion.