Allow installing plugins with vMAJOR or vMAJOR.MINOR or vMAJOR.MINOR.PATCH versions

[anujc25]

What this PR does / why we need it

• Allow installing plugins with vMAJOR or vMAJOR.MINOR or vMAJOR.MINOR.PATCH versions

Which issue(s) this PR fixes

Fixes #485

Describe testing done for PR

• Added Unit Tests and E2E Tests

~ $ tz plugin search --show-details --name insight                                                                                                                         
name: insight
description: Post & query image, package, source, and vulnerability data
target: kubernetes
latest: v1.6.3
versions:
    - v1.3.9
    - v1.4.6
    - v1.5.1
    - v1.6.0
    - v1.6.3
    - 
~ $ tz plugin install insight -v v1                                                                                                                                        (base)
[i] Installing plugin 'insight:v1.6.3' with target 'kubernetes'
[ok] successfully installed 'insight' plugin

~ $ tz plugin install insight -v v1.3                                                                                                                                      (base)
[i] Installing plugin 'insight:v1.3.9' with target 'kubernetes'
[ok] successfully installed 'insight' plugin

~ $ tz plugin install insight -v v1.6                                                                                                                                      (base)
[i] Installing plugin 'insight:v1.6.3' with target 'kubernetes'
[i] Plugin binary for 'insight:v1.6.3' found in cache
[ok] successfully installed 'insight' plugin

~ $ tz plugin install insight -v v1.6.3                                                                                                                                    (base)
[i] Installing plugin 'insight:v1.6.3' with target 'kubernetes'
[i] Plugin binary for 'insight:v1.6.3' found in cache
[ok] successfully installed 'insight' plugin

~ $ tz plugin install insight -v v1.5                                                                                                                                      (base)
[i] Installing plugin 'insight:v1.5.1' with target 'kubernetes'
[ok] successfully installed 'insight' plugin

~ $ tz plugin install insight -v v2                                                                                                                                        (base)
[x] : unable to find plugin 'insight' with version 'v2' for target 'kubernetes'

~ $ tz plugin list                                                                                                                                                      (base)
Standalone Plugins
  NAME       DESCRIPTION                                                  TARGET      VERSION     STATUS
  telemetry  configure cluster-wide settings for vmware tanzu telemetry   global      v1.1.0      installed
  insight    post & query image, package, source, and vulnerability data  kubernetes  v1.5.1      installed

Release note

Allow installing plugins with `vMAJOR` or `vMAJOR.MINOR` or `vMAJOR.MINOR.PATCH` versions with `tanzu plugin install` and `tanzu plugin sync` commands

Additional information

Special notes for your reviewer

[marckhouzam]

Thanks @anujc25 for this. While I review I wanted to mention an alternative implementation. I'm not suggesting using it, I'm just bringing it to your attention.

Currently when we look for a plugin in the DB:

1. the RecommendedVersion field returned is set to the highest semantic version found by the query
2. the query will either look for all versions (not filter on version) or will look for a specific version using WHERE Version=<vX.Y.Z>

For this feature, we could use SQL's matching functionality and have the version filter become WHERE Version like '<version>%'. Then the query would return all versions that match the specified version, even if it is vX.Y or vX. And the latest version matching would be in RecommendedVersion.

For example, requesting to install a version of v1.2 would return the highest version that matches v1.2, which means the latest patch of v1.2.

Pros:

• should be almost transparent to the code as the sql query does this already

Cons:

• we would be dependent on using the RecommendedVersion field so we would need to ignore that value if the DB ever provided one.

[marckhouzam]

@anujc25 my apologies but after merging #484 this PR needs a rebase

[marckhouzam]

Thanks for the update using SQL!

[marckhouzam]

1. For error messages that say unable to find plugin '%v' with version '%v' we will now show "short" versions like v1. How about changing the error message to use the word matching to say unable to find plugin '%v' matching version '%v'`?

2. Is it ok for the special plugins that have actual binaries with versions v0.25/v0.28/v0.29 to now install the latest patch instead of the specific binary with that version? I hope so, because the behaviour of the PR is what I'm hoping we can keep.

3. I think we need to look at how this feature can be used for context-scoped plugins.
   I created a CR for the cluster plugin with a version of v0.30.
   When the plugin is not installed I see version v0.30, which is probably ok

Plugins from Context:  tkg1
  NAME                DESCRIPTION                           TARGET      VERSION  STATUS
  cluster             Kubernetes cluster operations         kubernetes  v0.30    not installed

when I do a plugin sync I then see v0.30.1 which is ok, but is shows there is an update available, which is wrong, and the plugin sync will re-install the same version

Plugins from Context:  tkg1
  NAME                DESCRIPTION                           TARGET      VERSION  STATUS
  cluster             Kubernetes cluster operations         kubernetes  v0.30.1  update available

[anujc25]

• For error messages that say unable to find plugin '%v' with version '%v' we will now show "short" versions like v1. How about changing the error message to use the word matching to say unable to find plugin '%v' matching version '%v'`?

Good point. Updated the error message.

• Is it ok for the special plugins that have actual binaries with versions v0.25/v0.28/v0.29 to now install the latest patch instead of the specific binary with that version? I hope so, because the behaviour of the PR is what I'm hoping we can keep.

Yes. That was the goal with v0.25/v0.28/v0.29 versions but we did not have this feature in past and hence we had to release it separately.

• I think we need to look at how this feature can be used for context-scoped plugins.
  I created a CR for the cluster plugin with a version of v0.30.
  When the plugin is not installed I see version v0.30, which is probably ok
  when I do a plugin sync I then see v0.30.1 which is ok, but is shows there is an update available, which is wrong, and the plugin sync will re-install the same version

I have updated the DiscoverServerPlugins function a bit to handle this scenario. However, when the plugin is not installed it will also show the latest matching version (in this case v0.30.1). I feel it should be reasonable as it is more explicitly saying which version will be installed with the tanzu plugin sync but would be nice to get your opinion on this.

[marckhouzam]

One small suggestion to improve the tests.
LGTM

Nice job!

[marckhouzam]

Nice that you also added a pre-release version in the tests👍

LGTM

[marckhouzam]

@anujc25 I think this feature is impactful enough that it should be mentioned in the documentation. I'm thinking of at least two areas:

1. using plugin groups with "shortened" plugin versions
2. context-scope plugins with "shortened" plugin versions

What do you think?

[anujc25]

Added some basic documentation. I will be adding more as part of follow-up PR.