search

vmware-tanzu / tanzu-framework

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

Open joshrosso opened 2 years ago

joshrosso commented 2 years ago

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:

  1. Binary sizes grow significantly

    • For a TCE install, the total binary size is barely shy of 1GB.

  2. 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.

  3. 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)

Additional context

This conversation started on internal slack and has been brought to this issue for open discussion.

saji-pivotal commented 2 years ago

@joshrosso Does this issue need an assignee? What are the next steps here to discuss what needs to be done?