Plugin install feature through CLI

[rootwarp]

Checklist

• New Feature for the SVC/Plugin
• New Feature for CI/CD
• Enhancement on Vatz
• Others(etc. e.g, documentation,...)

---

Please describe, what it's about or related Problem with

A clear description of what feature need to be developed or enhanced in Vatz

Currently, using VATZ plugins seems a little bit messy.
We have to build VATZ, and VATZ Plugins from source code and execute each processes individually.
So it could be not easy to manage those plugins precisely.

So, I suggest the new CLI command to install plugins that will make a better experience for users.

Due to Golang provides go install command by default, it will not too hard to implement plugin install command.

Expected user scenario is like below.

1. Assume the user already install VATZ.
2. Execute `./vatz plugin install <PLUGIN_REPO>
3. Then internally VATZ try go install <PLUGIN_REPO> from some directory which is defined on VATZ.
4. If the installation is completed, new plugin binary is available on the machine.

Describe the output that you are expecting for above

A clear and concise description of what you expect to happen.

After the implementation is completed, the below command will be available.

~$ ./vatz plugins install <GITHUB_REPO>

Describe alternatives you've considered

A clear and concise description of any alternative solutions or features you've considered.
N/A

Additional context

Add any other context or screenshots about the feature request here.

After implementing this issue, it could be possible to start the plugin with VATZ CLI.

---

This issue will be splited into several tasks.

• Implement plugin install
• Add the new config to store plugin binaries

[rootwarp]

@xellos00 Please review this proposal.

[rootwarp]

@xellos00 How do I create subtasks for this? do I follow the issue template like this?

[xellos00]

@xellos00 How do I create subtasks for this? do I follow the issue template like this?

Yeah this is proposal, Please, create an issue for each task and make it parents to

• Developments for VATZ CLI Commands  #178

[xellos00]

@xellos00 Please review this proposal.

let's discuss little further to cover up plugin enable/disable in configs and this issue as well.
I will set a meeting any time soon on coming Wednesday.
I hope to @heejin-github there too.

---

Here's items that I'd like to discuss
include CLI command and official plugins.

• Install plugins
• start plugins
• stop plugins
• enable/disable plugins

[rootwarp]

@xellos00 Please review this proposal.

let's discuss little further to cover up plugin enable/disable in configs and this issue as well. I will set a meeting any time soon on coming Wednesday. I hope to @heejin-github there too.

OK. before then, I will try to implement PoC code from #298.

[rootwarp]

Naming Problem

Plugin install can be done by executing go install <REPO>. but here are some problems.
When I try to install github.com/dsrvlabs/vatz-plugin-cosmoshub/plugins/up, the selected plugins will be downloaded and built. And final binary will be copied into $GOBIN with the name up, which is the last part of the repository address.

Due to anyone can create Vatz plugin, this default naming rule can be a serious problem because another plugin that has the same suffix URL will overlap the old binary.
So the new naming rule is required to guarantee the uniqueness of the plugin name.

For that, here are some ideas,

1. Simply the Vatz users define the plugin name when they try to install it.

For example,

~$ vatz plugin install github.com/dsrvlabs/vatz-plugin-cosmoshub/plugins/up cosmos-up

Then installed plugin will have the name cosmos-up.

This approach seems very simple but it is too flexible.
The same plugin could have different names in different environments and that could make confusion.

2. Managing plugin registry.
   It is definitely similar to package managers like pip, npm, and apk.
   But you may know that for supporting full features like above, we should manage package server. That will be huge burden and we don't want that.

To make it simple, we could manage simple registry file on VATZ repo.
The content of the registry file could be,

cosmos-up github.com/dsrvlabs/vatz-plugin-cosmoshub/plugins/up
cosmos-status github.com/dsrvlabs/vatz-plugin-cosmoshub/plugins/active_status
...
...
...

If a developer built brand new VATZ plugins, the developer should add their repository info into the registry file.
To make the new plugin available, the modified registry file should be reviewed and merged into main branch.

FYI @xellos00

[xellos00]

from @rootwarp
Plan to create

• list plugins
  • (only installed in local)
• Install plugins
  • arguments git-address, and its name
  • create binary
• start plugins
• stop plugins
• delete plugins
  • delete binary
    default: /root/.vatz

from @xellos00 (optional)

• list plugins enable/disable
• enable/disable plugins

---

1. Naming rule may requires because of binary
   • Which rule to follow
2. Create repo list in the VATZ
3. (Optional) package server managements ( it's too soon, if this project boosted and then we can consider)

[xellos00]

First POC

@rootwarp

• list plugins
  • (only installed in local)
• Install plugins
  • arguments git-address, and its name
  • create binary
• start plugins

@heejin-github
Sync for share go.mod, go.sum
https://github.com/dsrvlabs/vatz-plugin-cosmoshub
https://github.com/dsrvlabs/vatz-plugin-sysutil

go public

• VATZ
• vatz-proto
• official plugins

---

meeting for next progress

• VATZ proto (agenda)
• additional CLI command
• Plugins template

[rootwarp]

Working scenario

TBD

1. Install Vatz

• go install github.com/dsrvlabs/vatz

2. Install plugins

• vatz plugin install github.com/dsrvlabs/vatz-plugin-cosmoshub/plugins/active_status validator-status
• The command will build plugin.
• Install information will be stored on local DB.

3. Register(Active) plugin

• vatz plugin register --plugin validator-status --args "-valoperAddr=XXXXXXXXX"
• The command arguments will be stored on local DB.

4. Start plugin

• vatz plugin start active_status