[feature] support rudr plugin system discovery/install/uninstall about kubevela HOT 10 CLOSED

I have two suggestions:

1. We don't need to emphasis the difference between workload and trait to user.

So they can all be plugins. What about use rudr repo plugins instead of rudr repo workloads and rudr repo traits. We can add --type workload/trait arguments to filter. Name of workload/trait should be globally unique as they are all helm charts.

2. Use rudr repo install <Name> instead of rudr repo down <Name>

from kubevela.

@zzxwill Workload/Trait in registry is infrastructure level while Application is user level, they are both natural in registry.

from kubevela.

Plan 1：Based on the Helm Repository specification

Cmd design

Add repository

Cmd: rudr repo add <Name> <URL>

Name: name can be empty, if it is empty, default set it is default .

URL: repository url is helm repository url. such as https://example.oamhelmrepo.com or https://example.oamhelmrepo.com/tenantrepo

Params:

​ --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle
​ --cert-file string identify HTTPS client using this SSL certificate file
​ --key-file string identify HTTPS client using this SSL key file
​ --no-update raise error if repo is already registered
​ --password string chart repository password
​ --username string chart repository username

Implementation summary

(1) check repository meta info.

(2) query helm chart index file.

​ Query path <URL>/index.yaml

(3) save repository meta info to local repository config file.

(4) distinguish the type of chart.

* oam application:   chart.annotations['OAM_RESOURCE_TYPE']=="Application"
* oam workload:   chart.annotations['OAM_RESOURCE_TYPE']=="Workload"
* oam trait:   chart.annotations['OAM_RESOURCE_TYPE']=="Trait"

(5) cache oam application meta

(6) cache oam workload meta

(7) cache oam trait meta

List repositorys

Cmd: rudr repo list

Implementation summary

(1) read repository list from local repository config file

(2) print repository list

Update repository cache data

Cmd: rudr repo update <Name>

Name: name can be empty, if set --all , will update all repository , else if it is empty, default set it is default .

Params:

​ --all update all repository

Implementation summary

(1) read repository list from local repository config file

(2) query helm chart index file.

(3) update oam application、workload、trait cache.

Delete repository

Cmd: rudr repo remove <Name>

Name: name must be set.

Implementation summary

(1) read repository list from local repository config file

(2) remove the specified repository

(3) save new repository list to local repository config file.

Get or search oam application list

Cmd: rudr repo apps

Params:

​ --repo specified repository name, if not set, query default repository.

​ --q specified search keys.

Implementation summary

(1) read application list from local cache file.

(2) based on repo name and search keys selection.

(3) print applications

Get or search workload list

Cmd: rudr repo workloads

Params:

​ --repo specified repository name, if not set, query default repository.

​ --q specified search keys.

Implementation summary

(1) read workload list from local cache file.

(2) based on repo name and search keys selection.

(3) print workloads

Get or search trait list

Cmd: rudr repo traits

Params:

​ --repo specified repository name, if not set, query default repository.

​ --q specified search keys.

Implementation summary

(1) read trait list from local cache file.

(2) based on repo name and search keys selection.

(3) print traits

Get oam application and version (for install)

Cmd: rudr repo app down <Name>

Params:

​ --repo specified repository name, if not set, query default repository.

​ --version specified chart version. if not set. download the latest version.

Implementation summary

(1) download chart from repository

​ Download path <URL>/charts/<Name>-<Version>.tgz

(2) save to application local cache

​ Cache path <Cache-dir>/applications/charts

Get workload and version (for install)

Cmd: rudr repo workload down <Name>

Params:

​ --repo specified repository name, if not set, query default repository.

​ --version specified chart version. if not set. download the latest version.

Implementation summary

(1) download chart from repository

​ Download path <URL>/charts/<Name>-<Version>.tgz

(2) save to workload local cache

Cache path <Cache-dir>/workloads/charts

Get trait and version (for install)

Cmd: rudr repo trait down <Name>

Params:

​ --repo specified repository name, if not set, query default repository.

​ --version specified chart version. if not set. download the latest version.

Implementation summary

(1) download chart from repository

​ Download path <URL>/charts/<Name>-<Version>.tgz

(2) save to trait local cache

​ Cache path <Cache-dir>/traits/charts

Commands that need to be implemented based on the above specification

• Install oam application
• Install workload
• Install trait
• uninstall trait
• uninstall workload
• uninstall oam application

The relevant

Local Cache Dir

Unix:
​ config-meta-dir: ~/.config/rudrx
​ cache-dir: ~/.cache/rudrx
Windows:
​ config-meta-dir: /.config/rudrx
​ cache-dir: /.cache/rudrx
Mac:
​ config-meta-dir: ~/Library/Preferences/rudrx
​ cache-dir: ~/Library/Caches/rudrx

from kubevela.

@wonderflow RFC

from kubevela.

The design is elaborated, cool!

1. Let's make helm repo add as simple as possible. You can support flags are blow later.

Params:
​ --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle
​ --cert-file string identify HTTPS client using this SSL certificate file
​ --key-file string identify HTTPS client using this SSL key file
​ --no-update raise error if repo is already registered
​ --password string chart repository password
​ --username string chart repository username

2. I doubt whether we should mark a chart as application? @wonderflow

• oam application: chart.annotations['OAM_RESOURCE_TYPE']=="Application"

3. For the implementation, I wonder whether we should warp the command/api of helm?

from kubevela.

@wonderflow

1. about use the plugin instead of workload and trait，Is that the conclusion now? As I have communicated with you before, it is all in the form of plugins in our products.

2. rudr repo down is before rudr repo install , It also has some value, such as simply caching installation packages. Install might need to be co-designed with other parts, so I haven't perfected it.

from kubevela.

For 1, I prefer plugins, but it's open for discuss.
For 2， down is not very clear, install is more intuitive.

from kubevela.

@zzxwill

1. rudr repo add is basically the same as helm repo add. Because we distribute applications or plugins based on the Helm repository specification.
2. We are just a Repository API specification based on Helm, but do not depend on the Helm client.

from kubevela.

@wonderflow If there is an OAM-Runtime in the cluster. The installation process is consistent with helm's installation chart process, Just create all the kubernetes resources. Don't worry about non-Kubernetes environments.

from kubevela.

@barnettZQG I have changed the design and describe in the issue content, tell me if you are still interested with this issue?

from kubevela.