Suport generic url for installing a tsuru-plugin

[tcarreira]

Currently, in order to instal a plugin, we nee a URL (tsuru-plugin-add plugin_name url).
This URL is platform+architecture dependent, as the client has no way to figure out the right binary/package for itself.

I'm proposing a new manifest-like json document, which would list the URL for all platform/arch combinations.
We would then include that document with the plugin release, and it would be available at eg: https://github.com/tsuru/rpaas-operator/releases/latest/download/manifest.json (eg with an already existing file checksum.txt)

This would allow a single installation URL for a plugin
It would also improve the usability of #171

---

Expected behavior:

$ tsuru plugin install myplugin https://github.com/org/myplugin/releases/latest/download/manifest.json
Plugin installed

## (tsuru-client will translate it to be) the same as:
$ tsuru plugin install myplugin https://github.com/org/myplugin/releases/download/v1.0.0/myplugin_v1.0.0_darwin_arm64.tar.gz
Plugin installed

---

Recommended structure for manifest.json:

{
  "SchemaVersion": "1.0",
  "Metadata": {
    "Name": "<pluginName>",
    "Version": "<pluginVersion>"
  },
  "UrlPerPlatform": {
    "darwin/amd64": "https://github.com/tsuru/<plugin_name>/releases/download/v<plugin_version>/<plugin_name>_Darwin_x86_64.tar.gz",
    "darwin/arm64": "https://github.com/tsuru/<plugin_name>/releases/download/v<plugin_version>/<plugin_name>_Darwin_arm64.tar.gz",
    "linux/amd64": "https://github.com/tsuru/<plugin_name>/releases/download/v<plugin_version>/<plugin_name>_Linux_x86_64.tar.gz",
    "linux/arm64": "https://github.com/tsuru/<plugin_name>/releases/download/v<plugin_version>/<plugin_name>_Linux_arm64.tar.gz",
    "linux/386": "https://github.com/tsuru/<plugin_name>/releases/download/v<plugin_version>/<plugin_name>_Linux_i386.tar.gz",
    "windows/386": "https://github.com/tsuru/<plugin_name>/releases/download/v<plugin_version>/<plugin_name>_Windows_i386.tar.gz",
    "windows/amd64": "https://github.com/tsuru/<plugin_name>/releases/download/v<plugin_version>/<plugin_name>_Windows_x86_64.tar.gz"
  }
}

(a real example that can be used for tests in a comment bellow)

---

what should be done:

• changes go inside func installPlugin(pluginName, pluginURL string) error
• nothing should be changed until http.Get(pluginURL) (actually, until defer resp.Body.Close() referring to that line)
• bind the content of the pluginURL to the new type PluginManifest. If it fails, keep the old behavior
• get GOOS and GOARCH from runtime
• get the new URL from that PluginManifest.UrlPerPlatform[GOOS/GOARCH]
• recursively call installPlugin() with this new pluginURL

To prevent infinite recursion, the func installPlugin(...) could take an extra argument: a counter to be checked for recursion

[otherpirate]

Hi, I need more information about it

1. Do you need to support other platforms?
2. In the examples URL, you have a kind of template? (eg <plugin_name>). Should I replace it with metadata information?

[tcarreira]

1. Do you need to support other platforms?

Currently, tsuru-client is available only for the following matrix of os/arch:

linux/386
linux/amd64
linux/arm64
darwin/amd64
darwin/arm64
windows/386
windows/amd64

(linux/arm64 was missing from the original description, I've added it)

You may check the releases page in order to check what exists in the moment.
Note: this are the names used in the releases, please choose the convention (probably the one used in Go) for the arch (amd64 vs x86_64)
EDIT: use combination from go tool dist list

Nonetheless, I believe the list should not be hardcoded.
Although it could be improved on later, I would implement it right now, as I think it is fairly easy to do so, and it will avoid some hard to find bugs.
But feel free to choose your way out.

---

2. In the examples URL, you have a kind of template? (eg <plugin_name>). Should I replace it with metada information?

There is currently no plugin implementing this. This is a new standard we are creating.
The tsuru/rpaas-operator will be a candidate for this new standard, but only after implementing #173

The current release of rpaas-operator (v0.33.1), would also be publishing the following manifest.json

{
  "SchemaVersion": "1.0",
  "Metadata": {
    "Name": "rpaasv2",
    "Version": "0.33.1"
  },
  "UrlPerPlatform": {
    "darwin/amd64": "https://github.com/tsuru/rpaas-operator/releases/download/v0.33.1/rpaasv2_0.33.1_Darwin_x86_64.tar.gz",
    "darwin/arm64": "https://github.com/tsuru/rpaas-operator/releases/download/v0.33.1/rpaasv2_0.33.1_Darwin_arm64.tar.gz",
    "linux/amd64": "https://github.com/tsuru/rpaas-operator/releases/download/v0.33.1/rpaasv2_0.33.1_Linux_x86_64.tar.gz",
    "linux/arm64": "https://github.com/tsuru/rpaas-operator/releases/download/v0.33.1/rpaasv2_0.33.1_Linux_arm64.tar.gz",
    "linux/386": "https://github.com/tsuru/rpaas-operator/releases/download/v0.33.1/rpaasv2_0.33.1_Linux_i386.tar.gz",
    "windows/amd64": "https://github.com/tsuru/rpaas-operator/releases/download/v0.33.1/rpaasv2_0.33.1_Windows_x86_64.tar.gz"
    "windows/386": "https://github.com/tsuru/rpaas-operator/releases/download/v0.33.1/rpaasv2_0.33.1_Windows_i386.tar.gz",
  }
}

---

Let me know if any question arises ;)