Merge pull request #530 from hongchaodeng/doc-cap

doc: add managing caps

.github/workflows/e2e.yml

@@ -8,15 +8,9 @@ on:
 
 jobs:
   build:
-    name: Build
-    runs-on: ubuntu-latest
+    name: e2e-tests
+    runs-on: aliyun
     steps:
-      - name: Set up Go 1.13
-        uses: actions/setup-go@v1
-        with:
-          go-version: 1.13
-        id: go
-
       - name: Check out code into the Go module directory
         uses: actions/checkout@v2
 
@@ -24,22 +18,22 @@ jobs:
         run: |
           go get -v -t -d ./...
 
-      - name: Install ginkgo
-        run:  |
-          sudo apt-get update
-          sudo apt-get install -y golang-ginkgo-dev
-
       - name: Setup Kind Cluster
         uses: engineerd/setup-kind@v0.4.0
         with:
           version: "v0.7.0"
+          skipClusterCreation: true
+
+      - name: Setup Kind Cluster
+        run: |
+          kind delete cluster
+          kind create cluster
+          kubectl version
+          kubectl cluster-info
 
       - name: Load Image to kind cluster
         run: make kind-load
 
-      - name: install Kubebuilder
-        uses: RyanSiu1995/kubebuilder-action@v1
-
       - name: Run Make
         run: make
 
@@ -48,7 +42,7 @@ jobs:
 
       - name: Run e2e tests
         run: |
+          make e2e-cleanup
           make e2e-setup
           make e2e-test
           make e2e-api-test
-          make e2e-cleanup

.github/workflows/go.yml

@@ -8,13 +8,13 @@ on:
 
 jobs:
   build:
-    name: Build
-    runs-on: ubuntu-latest
+    name: unit-tests
+    runs-on: ubuntu-20.04
     steps:
-      - name: Set up Go 1.13
+      - name: Set up Go 1.14
         uses: actions/setup-go@v1
         with:
-          go-version: 1.13
+          go-version: 1.14
         id: go
 
       - name: Check out code into the Go module directory
@@ -22,7 +22,6 @@ jobs:
 
       - name: Install ginkgo
         run:  |
-          sudo apt-get update
           sudo apt-get install -y golang-ginkgo-dev
 
       - name: Setup Kind Cluster

.github/workflows/release.yml

@@ -13,10 +13,10 @@ jobs:
       VELA_VERSION: ${{ github.ref }}
       GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
     steps:
-      - name: Set up Go 1.13
+      - name: Set up Go 1.14
         uses: actions/setup-go@v1
         with:
-          go-version: 1.13
+          go-version: 1.14
         id: go
       - name: Check out code into the Go module directory
         uses: actions/checkout@v2

.gitignore

@@ -39,6 +39,7 @@ tmp/
 cmd/vela/fake/source.go
 cmd/vela/fake/chart_source.go
 charts/vela-core/crds/_.yaml
+.test_vela
 
 .vela/
 

CONTRIBUTING.md

@@ -1,5 +1,9 @@
 # CONTRIBUTING
 
+## About KubeVela
+
+KubeVela project is initialized and maintained by the cloud native community since day 0 with [bootstrapping contributors from 8+ different organizations](https://github.com/oam-dev/kubevela/graphs/contributors). We intend for KubeVela to have a open governance since the very beginning and donate the project to neutral foundation as soon as it's released. 
+
 This doc explains how to set up a development environment, so you can get started
 contributing to `kubevela` or build a PoC (Proof of Concept). 
 
@@ -70,43 +74,60 @@ vela env init myenv --namespace myenv --email my@email.com --domain kubevela.io
 For example, use the following command to create and run an application.
 
 ```shell script
-$ vela comp deploy mycomp -t webservice --image crccheck/hello-world --port 8000
-Creating AppConfig appcomp
-SUCCEED
+$ vela svc deploy mysvc -t webservice --image crccheck/hello-world --port 8000 -a abc
+  App abc deployed
 ```
 
 * Add Trait
 
 ```shell script
-$ vela route mycomp
-Adding route for app abc
-Succeeded!
+$ vela route abc
+  Adding route for app mysvc
+  ⠋ Deploying ...
+  ✅ Application Deployed Successfully!
+    - Name: mysvc
+      Type: webservice
+      HEALTHY Ready: 1/1
+      Last Deployment:
+        Created at: 2020-11-02 11:17:28 +0800 CST
+        Updated at: 2020-11-02T11:21:23+08:00
+      Routes:
+        - route: Visiting URL: http://abc.kubevela.io	IP: 47.242.68.137
 ```
 
 * Check Status
 
 ```
-$ vela comp status abc
-Showing status of Component abc deployed in Environment t2
-Component Status:
-	Name: abc  PodSpecWorkload(type) UNKNOWN APIVersion standard.oam.dev/v1alpha1 Kind PodSpecWorkload workload is unknown for HealthScope
-	Traits
-	    └─Trait/route
-
-Last Deployment:
-	Created at: 2020-09-18 18:47:09 +0800 CST
-	Updated at: 2020-09-18T18:47:16+08:00
+$ vela status abc
+  About:
+  
+    Name:      	abc
+    Namespace: 	default
+    Created at:	2020-11-02 11:17:28.067738 +0800 CST
+    Updated at:	2020-11-02 11:28:13.490986 +0800 CST
+  
+  Services:
+  
+    - Name: mysvc
+      Type: webservice
+      HEALTHY Ready: 1/1
+      Last Deployment:
+        Created at: 2020-11-02 11:17:28 +0800 CST
+        Updated at: 2020-11-02T11:28:13+08:00
+      Routes:
+        - route: Visiting URL: http://abc.kubevela.io	IP: 47.242.68.137
 ```
 
 * Delete App
 
 ```shell script
-$ vela app ls
-abc
+$ vela ls
+  SERVICE       	APP      	TYPE	TRAITS	STATUS  	CREATED-TIME
+  mysvc            	abc       	    	      	Deployed 	2020-11-02 11:17:28 +0800 CST
 
-$ vela app delete abc
-Deleting Application "abc"
-delete apps succeed abc from t2
+$ vela delete abc
+  Deleting Application "abc"
+  delete apps succeed abc from default
 ```
 
 ## Tests
@@ -119,7 +140,7 @@ make test
 
 ### E2E test
 
-** Before e2e test start, make sure you have vela-core running.**
+**Before e2e test start, make sure you have vela-core running.**
 
 ```shell script
 make core-run

Makefile

@@ -20,8 +20,8 @@ endif
 all: build
 
 # Run tests
-test: fmt vet lint
-	./hack/unit_test.sh
+test: vet lint
+	go test -race -coverprofile=coverage.txt -covermode=atomic ./pkg/... ./cmd/...
 
 # Build manager binary
 build: fmt vet lint
@@ -29,6 +29,9 @@ build: fmt vet lint
 	go build -o bin/vela -ldflags ${LDFLAGS} cmd/vela/main.go
 	git checkout cmd/vela/fake/chart_source.go
 
+vela-cli:
+	go build -o bin/vela -ldflags ${LDFLAGS} cmd/vela/main.go
+
 npm-build:
 	cd dashboard && npm run build && cd ./..
 
@@ -36,7 +39,7 @@ npm-install:
 	cd dashboard && npm install && cd ./..
 
 generate-doc:
-	rm -r documentation/cli/*
+	rm -r docs/cli/*
 	go run hack/docgen/gen.go
 
 generate-source:
@@ -63,6 +66,7 @@ run: fmt vet
 # Run go fmt against code
 fmt:
 	go fmt ./...
+	./hack/cue-fmt.sh
 
 # Run go vet against code
 vet:
@@ -88,7 +92,7 @@ e2e-setup:
 
 e2e-test:
 	# Run e2e test
-	ginkgo -v -skipPackage setup,apiserver -r e2e
+	ginkgo -v -skipPackage capability,setup,apiserver -r e2e
 
 e2e-api-test:
 	# Run e2e test
@@ -96,6 +100,7 @@ e2e-api-test:
 
 e2e-cleanup:
 	# Clean up
+	rm -rf ~/.vela
 
 # load docker image to the kind cluster
 kind-load:
@@ -122,19 +127,20 @@ core-run: generate fmt vet manifests
 # Install CRDs and Definitions of Vela Core into a cluster, this is for develop convenient.
 core-install: manifests
 	kubectl apply -f charts/vela-core/crds/
+	kubectl apply -f charts/vela-core/templates/defwithtemplate/
 	kubectl apply -f charts/vela-core/templates/definitions/
-	kubectl apply -f charts/third_party/prometheus
+	bin/vela system update
 
 # Uninstall CRDs and Definitions of Vela Core from a cluster, this is for develop convenient.
 core-uninstall: manifests
-	kubectl delete -f charts/vela-core/crds/
 	kubectl delete -f charts/vela-core/templates/definitions/
-	kubectl delete -f charts/third_party/prometheus
+	kubectl delete -f charts/vela-core/templates/defwithtemplate/
+	kubectl delete -f charts/vela-core/crds/
 
 # Generate manifests e.g. CRD, RBAC etc.
 manifests: controller-gen
 	$(CONTROLLER_GEN) $(CRD_OPTIONS) rbac:roleName=manager-role webhook paths="./..." output:crd:artifacts:config=charts/vela-core/crds
-	rm charts/vela-core/crds/_.yaml
+	./hack/vela-templates/gen_definitions.sh
 
 # Generate code
 generate: controller-gen

OWNERS

@@ -0,0 +1,9 @@
+approvers:
+- kubevela-controller
+- kubevela-devex
+
+reviewers:
+- kubevela-controller
+- kubevela-dashboard
+- oam-k8s-runtime
+- oam-spec

OWNERS_ALIASES

@@ -0,0 +1,49 @@
+aliases:
+  kubevela-devex:
+  - hongchaodeng
+  - wonderflow
+
+  kubevela-dashboard:
+  - zzxwill
+  - hanxie-crypto
+  - hongchaodeng
+
+  kubevela-controller:
+  - resouer
+  - wonderflow
+  - hongchaodeng
+  - zzxwill
+  - ryanzhang-oss
+  
+  oam-k8s-runtime:            # inherit from https://github.com/crossplane/oam-kubernetes-runtime/blob/master/OWNERS.md
+  - hongchaodeng
+  - wonderflow
+  - ryanzhang-oss
+  - captainroy-hy
+  - negz
+  - hasheddan
+
+  oam-spec:                   # inherit from https://github.com/oam-dev/spec/blob/master/OWNERS.md
+  - hongchaodeng
+  - resouer
+  - vturecek
+
+  community-collaborators:
+  - Fei-Guo
+  - szihai
+
+  bootstrap-contributors:     # thank you for bootstrapping KubeVela at the very early stage!
+  - xiaoyuaiheshui
+  - Ghostbaby
+  - wenxinnnnn
+  - silenceper
+  - erdun
+  - sunny0826
+  - mosesyou
+  - artursouza
+  - wonderflow
+  - hongchaodeng
+  - ryanzhang-oss
+  - woshilanren11
+  - hanxie-crypto
+  - zzxwill

README.md

@@ -1,338 +1,28 @@
+![alt](resources/KubeVela-03.png)
+
+*Make shipping applications more enjoyable.*
+
 # KubeVela
 
-The Open Application Platform based on Kubernetes and Open Application Model (OAM).
+For developers, KubeVela is an easy-to-use tool that enables them to describe and ship their applications to Kubernetes with minimal effort.
 
-## Project Status
+For platform builders, KubeVela serves as a framework that empowers them to create developer facing yet highly extensible platforms at ease.
 
-:rotating_light: **Warning: this project is still a work in progress with lots of rough edges, please don't look inside unless you know what you are doing.**
+- Slack: [Discuss](https://cloud-native.slack.com/archives/C01BLQ3HTJA)
+- Gitter: [Community](https://gitter.im/oam-dev/community)
 
-KubeVela project is initialized and maintained by the cloud native community since day 0 with [bootstrapping contributors from 8+ different organizations](https://github.com/oam-dev/kubevela/graphs/contributors). We intend for KubeVela to have a open governance since the very beginning and donate the project to neutral foundation as soon as it's released. 
+## Quick Start
 
-## Purpose and Goal
+Quick start guides are available on [this section](docs/quick-start.md).
 
-- For developers and operators
-  - KubeVela, as an out-of-box Cloud Native Application Management Platform, provides numerous workloads and operation tooling for application defining, deployment, scaling, traffic, rollout, routing, monitoring, logging, alerting, CI/CD and so on.
-- For platform builders
-  - KubeVela, as a highly extensible PaaS/Serverless Core, provides pluggable capabilities, an elegant way to integrate any workloads and operational capabilities (i.e. traits).
+## Documentation
 
-## Design and Architecture
-
-Read more about [KubeVela's high level design and architecture](DESIGN.md).
-
-## Demo Instructions
-
-See the demo instructions below get a sense of what we've accomplished and are working on.
-
-## Install
-
-### Prerequisites
-- Kubernetes cluster running Kubernetes v1.15.0 or greater
-- kubectl current context is configured for the target cluster install
-  - ```kubectl config current-context```
-
-### Get the Vela CLI
-
-Download the `vela` binary from the [releases page](https://github.com/oam-dev/kubevela/releases). Unpack the `vela` binary and add it to `$PATH` to get started.
-
-```shell
-sudo mv ./vela /usr/local/bin/vela
-```
-
-### Install Vela Core
-
-```console
-$ vela install
-```
-This command will install vela core controller into your K8s cluster, along with built-in workloads and traits.
-
-## Using KubeVela
-
-After `vela install` you will see available workloads and traits.
-
-```console
-$ vela workloads
-NAME         	DEFINITION
-backend      	podspecworkloads.standard.oam.dev
-task         	jobs.batch.k8s.io
-webservice   	podspecworkloads.standard.oam.dev
-```
-
-```console
-$ vela traits
-NAME        	DEFINITION                        	APPLIES TO
-route       	routes.standard.oam.dev           	webservice,backend            	                                  
-scale       	manualscalertraits.core.oam.dev   	webservice,backend
-```
-
-### Create environment
-
-Before working with your application, you should prepare an deploy environment for it (e.g. test, staging, prod etc).
-
-```console
-$ vela env init demo --namespace demo --email my@email.com --domain kubevela.io
-ENVIROMENT demo CREATED, Namespace: demo, Email: my@email.com.
-```
-
-Vela will create a Kubernetes namespace called `demo` , with namespace level issuer for certificate generation using the email you provided.
-
-You could check the environment metadata in your local:
-
-```console
-$ cat ~/.vela/envs/demo/config.json
-  {"name":"demo","namespace":"demo","email":"my@email.com","domain":"kubevela.io","issuer":"oam-env-demo"}
-```
-
-
-### Create simple component 
-
-Then let's create application, we will use the `demo` environment.
-
-```console
-$ vela comp deploy mycomp -t webservice --image crccheck/hello-world --port 8000 --app myapp
-Creating AppConfig appcomp
-SUCCEED
-```
-
-### Create micro-services application
-
-Vela supports micro-services application by default thanks to Open Application Model.
-
-```console
-$ vela comp deploy db -t backend --image crccheck/hello-world --app myapp
-Creating App myapp
-SUCCEED
-```
-
-```console
-$ vela comp ls
-NAME  	APP  	WORKLOAD  	TRAITS	STATUS 	  CREATED-TIME
-db    	myapp	backend   	      	Deployed	2020-09-18 22:42:04 +0800 CST
-mycomp	myapp	webservice	      	Deployed	2020-09-18 22:42:04 +0800 CST
-```
-
-#### Under the hood
-
-In Kubernetes, vela creates an OAM application configuration named `myapp` to manage all related components.
-
-```console
-$ kubectl get appconfig -n demo
-  NAME    AGE
-  myapp   24s
-```
-
-```console
-$ kubectl get components -n demo
-  NAME     AGE
-  mycomp   24s
-  db       10s
-```
-
-Vela Core is responsible for managing the underlying Kubernetes resources linked with the components and application configuration above.
-
-```console
-$ kubectl get deployment -n demo
-  NAME     READY   UP-TO-DATE   AVAILABLE   AGE
-  mycomp   1/1     1            1           38s
-  db       1/1     1            1           20s
-``` 
-
-```console
-$ kubectl get svc -n demo
- NAME     TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
- mycomp   ClusterIP   172.21.4.228   <none>        8080/TCP   49s
-```
-
-### Manage operational configurations of the application
-
-Vela leverages OAM trait system to manage operational configurations such as `scale`, `route`, `canary`, `autocale`etc in application centric approach.
-
-Let's take `route` as example.
-
-### `route`
-
-If you want to use `route`, please make sure you have [nginx-ingress controller[https://kubernetes.github.io/ingress-nginx/deploy/] in your cluster.
-
-```console
-$ vela route mycomp --app myapp
- Adding route for app mycomp
- Succeeded!
-```
-
-For now you have to check the public address manually (this will be fixed soon so `vela route` will return visiting URL as result):
-
-```console
-$ kubectl get ingress -n demo
-NAME                        HOSTS                ADDRESS         PORTS     AGE
-mycomp-trait-5b576c4fc      mycomp.kubevela.io   123.57.10.233   80, 443   73s
-```
-
-And after you configure the `kubevela.io` domain pointing to the public address above.
-
-Your application will be reached by `https://mycomp.kubevela.io` with `mTLS` automatically enabled.
-
-### Under the hood
-
-Vela will manage the underlying Kubernetes resource which implements the `route` trait.
-
-```console
-$ kubectl get routes.standard.oam.dev -n demo
-NAME                     AGE
-mycomp-trait-5b576c4fc   18s
-```
-
-`routes.standard.oam.dev` is a CRD controller which will manage ingress, domain, certificate etc for your application.
-
-### Check status
-
-
-Check the application:
-
-```console
-$ vela app show myapp
-  About:
-  
-    Name:      	myapp
-    Created at:	2020-09-18 22:42:04.191171 +0800 CST
-    Updated at:	2020-09-18 22:51:11.128997 +0800 CST
-  
-  
-  Environment:
-  
-    Namespace:	demo
-  
-  Components:
-  
-    Name  	Type      	Traits
-    db    	backend
-    mycomp	webservice	route
-```
-
-Check specific component:
-
-```console
-$ vela comp show mycomp
- About:
- 
-   Name:        	mycomp
-   WorkloadType:	webservice
-   Application: 	myapp
- 
- Environment:
- 
-   Namespace:	demo
- 
- Arguments:
- 
-   image:	crccheck/hello-world
-   name: 	mycomp
-   port: 	8000
- 
- 
- Traits:
- 
-   route:
-     domain:	mycomp.kubevela.io
-     issuer:	oam-env-demo
-     name:  	route
-```
-
-```
-$ vela comp status mycomp
-  Showing status of Component mycomp deployed in Environment demo
-  Component Status:
-  	Name: mycomp  PodSpecWorkload(type) UNKNOWN APIVersion standard.oam.dev/v1alpha1 Kind PodSpecWorkload workload is unknown for HealthScope
-  	Traits
-  	    └─Trait/route
-  
-  Last Deployment:
-  	Created at: 2020-09-18 22:42:04 +0800 CST
-  	Updated at: 2020-09-18T22:51:11+08:00
-```
-
-### Delete application or component
-
-```console
-$ vela app ls
-myapp
-```
-
-```console
-$ vela comp ls
-NAME  	APP  	WORKLOAD  	TRAITS	STATUS 	CREATED-TIME
-db    	myapp	backend   	      	Deployed	2020-09-18 22:42:04 +0800 CST
-mycomp	myapp	webservice	route 	Deployed	2020-09-18 22:42:04 +0800 CST
-```
-
-```console
-$ vela comp delete db
-Deleting Component 'db' from Application 'db'
-```
-
-```console
-$ vela comp ls
-NAME  	APP  	WORKLOAD  	TRAITS	STATUS 	CREATED-TIME
-mycomp	myapp	webservice	route 	Deployed	2020-09-18 22:42:04 +0800 CST
-```
-
-```console
-$ vela app delete myapp
-Deleting Application "myapp"
-delete apps succeed myapp from demo
-```
-
-## Dashboard
-
-Vela has a simple client side dashboard for you to interact with (note it's still under development). The functionality is equivalent to the vela cli.
-
-```console
-$ vela dashboard
-```
-
-#### Auto-completion
-
-##### bash
-
-```console
-To load completions in your current shell session:
-$ source <(vela completion bash)
-
-To load completions for every new session, execute once:
-Linux:
-  $ vela completion bash > /etc/bash_completion.d/vela
-MacOS:
-  $ vela completion bash > /usr/local/etc/bash_completion.d/vela
-```
-
-##### zsh
-
-```console
-To load completions in your current shell session:
-$ source <(vela completion zsh)
-
-To load completions for every new session, execute once:
-$ vela completion zsh > "${fpath[1]}/_vela"
-```
-
-### Clean your environment
-
-```console
-$ helm uninstall kubevela -n vela-system
-release "kubevela" uninstalled
-```
-
-```console
-$ kubectl delete crd workloaddefinitions.core.oam.dev traitdefinitions.core.oam.dev  scopedefinitions.core.oam.dev
-customresourcedefinition.apiextensions.k8s.io "workloaddefinitions.core.oam.dev" deleted
-customresourcedefinition.apiextensions.k8s.io "traitdefinitions.core.oam.dev" deleted
-```
-
-```console
-$ rm -r ~/.vela
-```
+Full documentation is available on the [documentation section](docs/README.md).
 
 ## Contributing
-Check out [CONTRIBUTING.md](./CONTRIBUTING.md) to see how to develop with KubeVela.
+Check out [CONTRIBUTING](./CONTRIBUTING.md) to see how to develop with KubeVela.
 
 ## Code of Conduct
-This project has adopted the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md). See [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md) for further details.
+This project has adopted the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md). See [CODE OF CONDUCT](CODE_OF_CONDUCT.md) for details.
 
+> NOTE: KubeVela is an early project and iterating quickly to continue to make it easier to ship applications and build platforms atop. It's still under preview release for now.

api/types/capability.go

@@ -21,6 +21,7 @@ import (
 	"fmt"
 
 	"cuelang.org/go/cue"
+	"github.com/google/go-cmp/cmp"
 	"github.com/spf13/pflag"
 	"k8s.io/apimachinery/pkg/runtime"
 )
@@ -84,6 +85,7 @@ type Parameter struct {
 	Default  interface{} `json:"default,omitempty"`
 	Usage    string      `json:"usage,omitempty"`
 	Type     cue.Kind    `json:"type,omitempty"`
+	Alias    string      `json:"alias,omitempty"`
 }
 
 // ConvertTemplateJSON2Object convert spec.extension to object
@@ -104,6 +106,10 @@ func ConvertTemplateJSON2Object(in *runtime.RawExtension) (Capability, error) {
 }
 
 func SetFlagBy(flags *pflag.FlagSet, v Parameter) {
+	name := v.Name
+	if v.Alias != "" {
+		name = v.Alias
+	}
 	switch v.Type {
 	case cue.IntKind:
 		var vv int64
@@ -117,11 +123,11 @@ func SetFlagBy(flags *pflag.FlagSet, v Parameter) {
 		case float64:
 			vv = int64(val)
 		}
-		flags.Int64P(v.Name, v.Short, vv, v.Usage)
+		flags.Int64P(name, v.Short, vv, v.Usage)
 	case cue.StringKind:
-		flags.StringP(v.Name, v.Short, v.Default.(string), v.Usage)
+		flags.StringP(name, v.Short, v.Default.(string), v.Usage)
 	case cue.BoolKind:
-		flags.BoolP(v.Name, v.Short, v.Default.(bool), v.Usage)
+		flags.BoolP(name, v.Short, v.Default.(bool), v.Usage)
 	case cue.NumberKind, cue.FloatKind:
 		var vv float64
 		switch val := v.Default.(type) {
@@ -134,6 +140,71 @@ func SetFlagBy(flags *pflag.FlagSet, v Parameter) {
 		case float64:
 			vv = val
 		}
-		flags.Float64P(v.Name, v.Short, vv, v.Usage)
+		flags.Float64P(name, v.Short, vv, v.Usage)
 	}
 }
+
+var CapabilityCmpOptions = []cmp.Option{
+	cmp.Comparer(func(a, b Parameter) bool {
+		if a.Name != b.Name || a.Short != b.Short || a.Required != b.Required ||
+			a.Usage != b.Usage || a.Type != b.Type {
+			return false
+		}
+		switch a.Type {
+		case cue.IntKind:
+			var va, vb int64
+			switch vala := a.Default.(type) {
+			case int64:
+				va = vala
+			case json.Number:
+				va, _ = vala.Int64()
+			case int:
+				va = int64(vala)
+			case float64:
+				va = int64(vala)
+			}
+			switch valb := b.Default.(type) {
+			case int64:
+				vb = valb
+			case json.Number:
+				vb, _ = valb.Int64()
+			case int:
+				vb = int64(valb)
+			case float64:
+				vb = int64(valb)
+			}
+			return va == vb
+		case cue.StringKind:
+			return a.Default.(string) == b.Default.(string)
+		case cue.BoolKind:
+			return a.Default.(bool) == b.Default.(bool)
+		case cue.NumberKind, cue.FloatKind:
+			var va, vb float64
+			switch vala := a.Default.(type) {
+			case int64:
+				va = float64(vala)
+			case json.Number:
+				va, _ = vala.Float64()
+			case int:
+				va = float64(vala)
+			case float64:
+				va = float64(vala)
+			}
+			switch valb := b.Default.(type) {
+			case int64:
+				vb = float64(valb)
+			case json.Number:
+				vb, _ = valb.Float64()
+			case int:
+				vb = float64(valb)
+			case float64:
+				vb = float64(valb)
+			}
+			return va == vb
+		}
+		return true
+	})}
+
+func EqualCapability(a, b Capability) bool {
+	return cmp.Equal(a, b, CapabilityCmpOptions...)
+}

api/v1alpha1/autoscaler_types.go

@@ -0,0 +1,118 @@
+/*
+
+
+Licensed under the Apache License, Version 2.0 (the "License");
+you may not use this file except in compliance with the License.
+You may obtain a copy of the License at
+
+    http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+*/
+
+package v1alpha1
+
+import (
+	"github.com/crossplane/crossplane-runtime/apis/core/v1alpha1"
+	runtimev1alpha1 "github.com/crossplane/crossplane-runtime/apis/core/v1alpha1"
+	metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
+)
+
+// NOTE: json tags are required.  Any new fields you add must have json tags for the fields to be serialized.
+
+// Protocol defines network protocols supported for things like container ports.
+type Protocol string
+
+// TriggerType defines the type of trigger
+type TriggerType string
+
+// +kubebuilder:object:root=true
+// +kubebuilder:resource:categories={oam}
+// Autoscaler is the Schema for the autoscalers API
+type Autoscaler struct {
+	metav1.TypeMeta   `json:",inline"`
+	metav1.ObjectMeta `json:"metadata,omitempty"`
+
+	Spec   AutoscalerSpec   `json:"spec"`
+	Status AutoscalerStatus `json:"status,omitempty"`
+}
+
+func (as *Autoscaler) SetConditions(c ...v1alpha1.Condition) {
+	as.Status.SetConditions(c...)
+}
+
+func (as *Autoscaler) GetCondition(conditionType v1alpha1.ConditionType) v1alpha1.Condition {
+	return as.Status.GetCondition(conditionType)
+}
+
+func (as *Autoscaler) GetWorkloadReference() v1alpha1.TypedReference {
+	return as.Spec.WorkloadReference
+}
+
+func (as *Autoscaler) SetWorkloadReference(reference v1alpha1.TypedReference) {
+	as.Spec.WorkloadReference = reference
+}
+
+// Trigger defines the trigger of Autoscaler
+type Trigger struct {
+	// Name is the trigger name, if not set, it will be automatically generated and make it globally unique
+	Name string `json:"name,omitempty"`
+
+	// Type allows value in [cpu/memory/storage/ephemeral-storage、cron、pps、qps/rps、custom]
+	Type TriggerType `json:"type"`
+
+	// Condition set the condition when to trigger scaling
+	Condition map[string]string `json:"condition"`
+}
+
+// AutoscalerSpec defines the desired state of Autoscaler
+type AutoscalerSpec struct {
+	// MinReplicas is the minimal replicas
+	// +optional
+	MinReplicas *int32 `json:"minReplicas,omitempty"`
+
+	// MinReplicas is the maximal replicas
+	// +optional
+	MaxReplicas *int32 `json:"maxReplicas,omitempty"`
+
+	// Triggers lists all triggers
+	Triggers []Trigger `json:"triggers"`
+
+	// TargetWorkload specify the workload which is going to be scaled,
+	// it could be WorkloadReference or the child resource of it
+	TargetWorkload TargetWorkload `json:"targetWorkload,omitempty"`
+
+	// WorkloadReference marks the owner of the workload
+	WorkloadReference runtimev1alpha1.TypedReference `json:"workloadRef,omitempty"`
+}
+
+// TargetWorkload holds the a reference to the scale target Object
+type TargetWorkload struct {
+	Name string `json:"name"`
+	// +optional
+	APIVersion string `json:"apiVersion,omitempty"`
+	// +optional
+	Kind string `json:"kind,omitempty"`
+}
+
+// AutoscalerStatus defines the observed state of Autoscaler
+type AutoscalerStatus struct {
+	runtimev1alpha1.ConditionedStatus `json:",inline"`
+}
+
+// +kubebuilder:object:root=true
+
+// AutoscalerList contains a list of Autoscaler
+type AutoscalerList struct {
+	metav1.TypeMeta `json:",inline"`
+	metav1.ListMeta `json:"metadata,omitempty"`
+	Items           []Autoscaler `json:"items"`
+}
+
+func init() {
+	SchemeBuilder.Register(&Autoscaler{}, &AutoscalerList{})
+}

api/v1alpha1/metricstrait_types.go

@@ -39,12 +39,11 @@ type ScapeServiceEndPoint struct {
 	// The default and only supported format is "prometheus" for now
 	Format string `json:"format,omitempty"`
 	// Number or name of the port to access on the pods targeted by the service.
-	// When this field has value implies that we need to create a service for the workload
-	// Mutually exclusive with port.
+	// The default is discovered automatically from podTemplate, metricTrait will create a service for the workload
 	TargetPort intstr.IntOrString `json:"port,omitempty"`
 	// Route service traffic to pods with label keys and values matching this
-	// The default is the labels in the workload
-	// Mutually exclusive with port.
+	// The default is discovered automatically from podTemplate.
+	// If no podTemplate, use the labels specified here, or use the labels of the workload
 	TargetSelector map[string]string `json:"selector,omitempty"`
 	// HTTP path to scrape for metrics.
 	// default is /metrics
@@ -63,8 +62,13 @@ type ScapeServiceEndPoint struct {
 type MetricsTraitStatus struct {
 	runtimev1alpha1.ConditionedStatus `json:",inline"`
 
-	// ServiceMonitorNames managed by this trait
-	ServiceMonitorNames []string `json:"serviceMonitorName,omitempty"`
+	// ServiceMonitorName managed by this trait
+	ServiceMonitorName string `json:"serviceMonitorName,omitempty"`
+
+	// Port is the real port monitoring
+	Port intstr.IntOrString `json:"port,omitempty"`
+	// SelectorLabels is the real labels selected
+	SelectorLabels map[string]string `json:"selectorLabels,omitempty"`
 }
 
 // +kubebuilder:object:root=true

api/v1alpha1/podspecworkload_types.go

@@ -28,7 +28,7 @@ type PodSpecWorkloadSpec struct {
 	// Replicas is the desired number of replicas of the given podSpec.
 	// These are replicas in the sense that they are instantiations of the same podSpec.
 	// If unspecified, defaults to 1.
-	Replicas *int32 `json:"replicas"`
+	Replicas *int32 `json:"replicas,omitempty"`
 
 	// PodSpec describes the pods that will be created,
 	// we omit the meta part as it will be exactly the same as the PodSpecWorkload
@@ -46,6 +46,8 @@ type PodSpecWorkloadStatus struct {
 // +kubebuilder:object:root=true
 
 // PodSpecWorkload is the Schema for the PodSpec API
+// +genclient:method=GetScale,verb=get,subresource=scale,result=k8s.io/api/autoscaling/v1.Scale
+// +genclient:method=UpdateScale,verb=update,subresource=scale,input=k8s.io/api/autoscaling/v1.Scale,result=k8s.io/api/autoscaling/v1.Scale
 // +kubebuilder:resource:categories={oam}
 // +kubebuilder:subresource:status
 type PodSpecWorkload struct {

api/v1alpha1/route_types.go

@@ -105,6 +105,7 @@ type BackendServiceRef struct {
 type RouteStatus struct {
 	Ingresses                         []runtimev1alpha1.TypedReference `json:"ingresses,omitempty"`
 	Service                           *runtimev1alpha1.TypedReference  `json:"service,omitempty"`
+	Status                            string                           `json:"status,omitempty"`
 	runtimev1alpha1.ConditionedStatus `json:",inline"`
 }
 

api/v1alpha1/zz_generated.deepcopy.go

@@ -25,6 +25,115 @@ import (
 	runtime "k8s.io/apimachinery/pkg/runtime"
 )
 
+// DeepCopyInto is an autogenerated deepcopy function, copying the receiver, writing into out. in must be non-nil.
+func (in *Autoscaler) DeepCopyInto(out *Autoscaler) {
+	*out = *in
+	out.TypeMeta = in.TypeMeta
+	in.ObjectMeta.DeepCopyInto(&out.ObjectMeta)
+	in.Spec.DeepCopyInto(&out.Spec)
+	in.Status.DeepCopyInto(&out.Status)
+}
+
+// DeepCopy is an autogenerated deepcopy function, copying the receiver, creating a new Autoscaler.
+func (in *Autoscaler) DeepCopy() *Autoscaler {
+	if in == nil {
+		return nil
+	}
+	out := new(Autoscaler)
+	in.DeepCopyInto(out)
+	return out
+}
+
+// DeepCopyObject is an autogenerated deepcopy function, copying the receiver, creating a new runtime.Object.
+func (in *Autoscaler) DeepCopyObject() runtime.Object {
+	if c := in.DeepCopy(); c != nil {
+		return c
+	}
+	return nil
+}
+
+// DeepCopyInto is an autogenerated deepcopy function, copying the receiver, writing into out. in must be non-nil.
+func (in *AutoscalerList) DeepCopyInto(out *AutoscalerList) {
+	*out = *in
+	out.TypeMeta = in.TypeMeta
+	in.ListMeta.DeepCopyInto(&out.ListMeta)
+	if in.Items != nil {
+		in, out := &in.Items, &out.Items
+		*out = make([]Autoscaler, len(*in))
+		for i := range *in {
+			(*in)[i].DeepCopyInto(&(*out)[i])
+		}
+	}
+}
+
+// DeepCopy is an autogenerated deepcopy function, copying the receiver, creating a new AutoscalerList.
+func (in *AutoscalerList) DeepCopy() *AutoscalerList {
+	if in == nil {
+		return nil
+	}
+	out := new(AutoscalerList)
+	in.DeepCopyInto(out)
+	return out
+}
+
+// DeepCopyObject is an autogenerated deepcopy function, copying the receiver, creating a new runtime.Object.
+func (in *AutoscalerList) DeepCopyObject() runtime.Object {
+	if c := in.DeepCopy(); c != nil {
+		return c
+	}
+	return nil
+}
+
+// DeepCopyInto is an autogenerated deepcopy function, copying the receiver, writing into out. in must be non-nil.
+func (in *AutoscalerSpec) DeepCopyInto(out *AutoscalerSpec) {
+	*out = *in
+	if in.MinReplicas != nil {
+		in, out := &in.MinReplicas, &out.MinReplicas
+		*out = new(int32)
+		**out = **in
+	}
+	if in.MaxReplicas != nil {
+		in, out := &in.MaxReplicas, &out.MaxReplicas
+		*out = new(int32)
+		**out = **in
+	}
+	if in.Triggers != nil {
+		in, out := &in.Triggers, &out.Triggers
+		*out = make([]Trigger, len(*in))
+		for i := range *in {
+			(*in)[i].DeepCopyInto(&(*out)[i])
+		}
+	}
+	out.TargetWorkload = in.TargetWorkload
+	out.WorkloadReference = in.WorkloadReference
+}
+
+// DeepCopy is an autogenerated deepcopy function, copying the receiver, creating a new AutoscalerSpec.
+func (in *AutoscalerSpec) DeepCopy() *AutoscalerSpec {
+	if in == nil {
+		return nil
+	}
+	out := new(AutoscalerSpec)
+	in.DeepCopyInto(out)
+	return out
+}
+
+// DeepCopyInto is an autogenerated deepcopy function, copying the receiver, writing into out. in must be non-nil.
+func (in *AutoscalerStatus) DeepCopyInto(out *AutoscalerStatus) {
+	*out = *in
+	in.ConditionedStatus.DeepCopyInto(&out.ConditionedStatus)
+}
+
+// DeepCopy is an autogenerated deepcopy function, copying the receiver, creating a new AutoscalerStatus.
+func (in *AutoscalerStatus) DeepCopy() *AutoscalerStatus {
+	if in == nil {
+		return nil
+	}
+	out := new(AutoscalerStatus)
+	in.DeepCopyInto(out)
+	return out
+}
+
 // DeepCopyInto is an autogenerated deepcopy function, copying the receiver, writing into out. in must be non-nil.
 func (in *Backend) DeepCopyInto(out *Backend) {
 	*out = *in
@@ -141,10 +250,13 @@ func (in *MetricsTraitSpec) DeepCopy() *MetricsTraitSpec {
 func (in *MetricsTraitStatus) DeepCopyInto(out *MetricsTraitStatus) {
 	*out = *in
 	in.ConditionedStatus.DeepCopyInto(&out.ConditionedStatus)
-	if in.ServiceMonitorNames != nil {
-		in, out := &in.ServiceMonitorNames, &out.ServiceMonitorNames
-		*out = make([]string, len(*in))
-		copy(*out, *in)
+	out.Port = in.Port
+	if in.SelectorLabels != nil {
+		in, out := &in.SelectorLabels, &out.SelectorLabels
+		*out = make(map[string]string, len(*in))
+		for key, val := range *in {
+			(*out)[key] = val
+		}
 	}
 }
 
@@ -446,3 +558,40 @@ func (in *TLS) DeepCopy() *TLS {
 	in.DeepCopyInto(out)
 	return out
 }
+
+// DeepCopyInto is an autogenerated deepcopy function, copying the receiver, writing into out. in must be non-nil.
+func (in *TargetWorkload) DeepCopyInto(out *TargetWorkload) {
+	*out = *in
+}
+
+// DeepCopy is an autogenerated deepcopy function, copying the receiver, creating a new TargetWorkload.
+func (in *TargetWorkload) DeepCopy() *TargetWorkload {
+	if in == nil {
+		return nil
+	}
+	out := new(TargetWorkload)
+	in.DeepCopyInto(out)
+	return out
+}
+
+// DeepCopyInto is an autogenerated deepcopy function, copying the receiver, writing into out. in must be non-nil.
+func (in *Trigger) DeepCopyInto(out *Trigger) {
+	*out = *in
+	if in.Condition != nil {
+		in, out := &in.Condition, &out.Condition
+		*out = make(map[string]string, len(*in))
+		for key, val := range *in {
+			(*out)[key] = val
+		}
+	}
+}
+
+// DeepCopy is an autogenerated deepcopy function, copying the receiver, creating a new Trigger.
+func (in *Trigger) DeepCopy() *Trigger {
+	if in == nil {
+		return nil
+	}
+	out := new(Trigger)
+	in.DeepCopyInto(out)
+	return out
+}

charts/vela-core/crds/cert-manager.yaml

@@ -1,16 +1,3 @@
-# Copyright YEAR The Jetstack cert-manager contributors.
-#
-# Licensed under the Apache License, Version 2.0 (the "License");
-# you may not use this file except in compliance with the License.
-# You may obtain a copy of the License at
-#
-#     http://www.apache.org/licenses/LICENSE-2.0
-#
-# Unless required by applicable law or agreed to in writing, software
-# distributed under the License is distributed on an "AS IS" BASIS,
-# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-# See the License for the specific language governing permissions and
-# limitations under the License.
 
 apiVersion: apiextensions.k8s.io/v1
 kind: CustomResourceDefinition
@@ -25238,5 +25225,4 @@ status:
     kind: ""
     plural: ""
   conditions: []
-  storedVersions: []
-
+  storedVersions: []

charts/vela-core/crds/standard.oam.dev_autoscalers.yaml

@@ -0,0 +1,155 @@
+
+---
+apiVersion: apiextensions.k8s.io/v1
+kind: CustomResourceDefinition
+metadata:
+  annotations:
+    controller-gen.kubebuilder.io/version: v0.2.5
+  creationTimestamp: null
+  name: autoscalers.standard.oam.dev
+spec:
+  group: standard.oam.dev
+  names:
+    categories:
+    - oam
+    kind: Autoscaler
+    listKind: AutoscalerList
+    plural: autoscalers
+    singular: autoscaler
+  scope: Namespaced
+  versions:
+  - name: v1alpha1
+    schema:
+      openAPIV3Schema:
+        description: Autoscaler is the Schema for the autoscalers API
+        properties:
+          apiVersion:
+            description: 'APIVersion defines the versioned schema of this representation
+              of an object. Servers should convert recognized schemas to the latest
+              internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources'
+            type: string
+          kind:
+            description: 'Kind is a string value representing the REST resource this
+              object represents. Servers may infer this from the endpoint the client
+              submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds'
+            type: string
+          metadata:
+            type: object
+          spec:
+            description: AutoscalerSpec defines the desired state of Autoscaler
+            properties:
+              maxReplicas:
+                description: MinReplicas is the maximal replicas
+                format: int32
+                type: integer
+              minReplicas:
+                description: MinReplicas is the minimal replicas
+                format: int32
+                type: integer
+              targetWorkload:
+                description: TargetWorkload specify the workload which is going to
+                  be scaled, it could be WorkloadReference or the child resource of
+                  it
+                properties:
+                  apiVersion:
+                    type: string
+                  kind:
+                    type: string
+                  name:
+                    type: string
+                required:
+                - name
+                type: object
+              triggers:
+                description: Triggers lists all triggers
+                items:
+                  description: Trigger defines the trigger of Autoscaler
+                  properties:
+                    condition:
+                      additionalProperties:
+                        type: string
+                      description: Condition set the condition when to trigger scaling
+                      type: object
+                    name:
+                      description: Name is the trigger name, if not set, it will be
+                        automatically generated and make it globally unique
+                      type: string
+                    type:
+                      description: Type allows value in [cpu/memory/storage/ephemeral-storage、cron、pps、qps/rps、custom]
+                      type: string
+                  required:
+                  - condition
+                  - type
+                  type: object
+                type: array
+              workloadRef:
+                description: WorkloadReference marks the owner of the workload
+                properties:
+                  apiVersion:
+                    description: APIVersion of the referenced object.
+                    type: string
+                  kind:
+                    description: Kind of the referenced object.
+                    type: string
+                  name:
+                    description: Name of the referenced object.
+                    type: string
+                  uid:
+                    description: UID of the referenced object.
+                    type: string
+                required:
+                - apiVersion
+                - kind
+                - name
+                type: object
+            required:
+            - triggers
+            type: object
+          status:
+            description: AutoscalerStatus defines the observed state of Autoscaler
+            properties:
+              conditions:
+                description: Conditions of the resource.
+                items:
+                  description: A Condition that may apply to a resource.
+                  properties:
+                    lastTransitionTime:
+                      description: LastTransitionTime is the last time this condition
+                        transitioned from one status to another.
+                      format: date-time
+                      type: string
+                    message:
+                      description: A Message containing details about this condition's
+                        last transition from one status to another, if any.
+                      type: string
+                    reason:
+                      description: A Reason for this condition's last transition from
+                        one status to another.
+                      type: string
+                    status:
+                      description: Status of this condition; is it currently True,
+                        False, or Unknown?
+                      type: string
+                    type:
+                      description: Type of this condition. At most one of each condition
+                        type may apply to a resource at any point in time.
+                      type: string
+                  required:
+                  - lastTransitionTime
+                  - reason
+                  - status
+                  - type
+                  type: object
+                type: array
+            type: object
+        required:
+        - spec
+        type: object
+    served: true
+    storage: true
+status:
+  acceptedNames:
+    kind: ""
+    plural: ""
+  conditions: []
+  storedVersions: []

charts/vela-core/crds/standard.oam.dev_metricstraits.yaml

@@ -56,9 +56,9 @@ spec:
                     - type: integer
                     - type: string
                     description: Number or name of the port to access on the pods
-                      targeted by the service. When this field has value implies that
-                      we need to create a service for the workload Mutually exclusive
-                      with port.
+                      targeted by the service. The default is discovered automatically
+                      from podTemplate, metricTrait will create a service for the
+                      workload
                     x-kubernetes-int-or-string: true
                   scheme:
                     description: Scheme at which metrics should be scraped The default
@@ -68,8 +68,9 @@ spec:
                     additionalProperties:
                       type: string
                     description: Route service traffic to pods with label keys and
-                      values matching this The default is the labels in the workload
-                      Mutually exclusive with port.
+                      values matching this The default is discovered automatically
+                      from podTemplate. If no podTemplate, use the labels specified
+                      here, or use the labels of the workload
                     type: object
                 type: object
               workloadRef:
@@ -132,11 +133,20 @@ spec:
                   - type
                   type: object
                 type: array
-              serviceMonitorName:
-                description: ServiceMonitorNames managed by this trait
-                items:
+              port:
+                anyOf:
+                - type: integer
+                - type: string
+                description: Port is the real port monitoring
+                x-kubernetes-int-or-string: true
+              selectorLabels:
+                additionalProperties:
                   type: string
-                type: array
+                description: SelectorLabels is the real labels selected
+                type: object
+              serviceMonitorName:
+                description: ServiceMonitorName managed by this trait
+                type: string
             type: object
         required:
         - spec

charts/vela-core/crds/standard.oam.dev_podspecworkloads.yaml

@@ -5691,7 +5691,6 @@ spec:
                 type: integer
             required:
             - podSpec
-            - replicas
             type: object
           status:
             description: PodSpecWorkloadStatus defines the observed state of PodSpecWorkload

charts/vela-core/crds/standard.oam.dev_routes.yaml

@@ -241,6 +241,8 @@ spec:
                 - kind
                 - name
                 type: object
+              status:
+                type: string
             type: object
         type: object
     served: true

charts/vela-core/templates/definitions/backend.yaml

@@ -1,39 +0,0 @@
-apiVersion: core.oam.dev/v1alpha2
-kind: WorkloadDefinition
-metadata:
-  name: backend
-  annotations:
-    definition.oam.dev/apiVersion: "standard.oam.dev/v1alpha1"
-    definition.oam.dev/kind: "PodSpecWorkload"
-    definition.oam.dev/description: "Backend worker without ports exposed"
-spec:
-  definitionRef:
-    name: podspecworkload.standard.oam.dev
-  childResourceKinds:
-    - apiVersion: apps/v1
-      kind: Deployment
-  extension:
-    template: |
-      output: {
-        apiVersion: "standard.oam.dev/v1alpha1"
-        kind:       "PodSpecWorkload"
-        metadata:
-          name: parameter.name
-        spec: {
-          replicas: 1
-            podSpec: {
-              containers: [{
-                 image: parameter.image
-                   name:  parameter.name
-               }]
-            }
-        }
-      }
-      #backend: {
-        name: string
-          // +usage=specify app image
-          // +short=i
-        image: string
-      }
-      parameter: #backend
-

charts/vela-core/templates/definitions/metricstraits.yaml

@@ -1,53 +0,0 @@
----
-apiVersion: v1
-kind: Namespace
-metadata:
-  labels:
-    mornitoring: oam
-  name: monitoring
-
----
-apiVersion: core.oam.dev/v1alpha2
-kind: TraitDefinition
-metadata:
-  name: metric
-  namespace: default
-  annotations:
-    definition.oam.dev/apiVersion: standard.oam.dev/v1alpha1
-    definition.oam.dev/kind: MetricsTrait
-    definition.oam.dev/description: "Add metric monitoring for workload"
-spec:
-  appliesToWorkloads:
-    - webservice
-    - backend
-    - task
-    - containerizedworkloads.core.oam.dev
-    - clonesetworkloads.apps.kruise.io
-    - deployments.apps
-    - statefulsets.apps
-  definitionRef:
-    name: metricstraits.standard.oam.dev
-  workloadRefPath: spec.workloadRef
-  extension:
-    template: |-
-      #metrics: {
-        // +usage=format of the metrics, default as prometheus
-        // +short=f
-        format:  *"prometheus" | string
-        path:    *"/metrics" | string
-        scheme:  *"http" | string
-        enabled: *true | bool
-        port:    *8080 | >=1024 & uint16
-        // +usage= the label selector for the pods, default is the workload labels
-        selector?: [string]: string
-      }
-      spec: {
-        apiVersion: "standard.oam.dev/v1alpha1"
-          kind:       "MetricsTrait"
-          spec: {
-            scrapeService: parameter
-          }
-      }
-      parameter: #metrics
-      output: {}
-

charts/vela-core/templates/definitions/podspecworkload.yaml

@@ -1,48 +0,0 @@
-apiVersion: core.oam.dev/v1alpha2
-kind: WorkloadDefinition
-metadata:
-  name: podspecworkloads.standard.oam.dev
-  annotations:
-    definition.oam.dev/apiVersion: "standard.oam.dev/v1alpha1"
-    definition.oam.dev/kind: "PodSpecWorkload"
-spec:
-  definitionRef:
-    name: podspecworkloads.standard.oam.dev
-  childResourceKinds:
-    - apiVersion: apps/v1
-      kind: Deployment
-    - apiVersion: v1
-      kind: Service
-  extension:
-    template: |
-      output: {
-      	apiVersion: "standard.oam.dev/v1alpha1"
-      	kind:       "PodSpecWorkload"
-      	metadata:
-      		name: parameter.name
-      	spec: {
-      		replicas: 1
-      		podSpec: {
-      			containers: [{
-      				image: parameter.image
-      				name:  parameter.name
-      				ports: [{
-      					containerPort: parameter.port
-      					protocol:      "TCP"
-      					name:          "default"
-      				}]
-      			}]
-      		}
-      	}
-      }
-      #webservice: {
-      	name: string
-      	// +usage=specify app image
-      	// +short=i
-      	image: string
-      	// +usage=specify port for container
-      	// +short=p
-      	port: *6379 | int
-      }
-      parameter: #webservice
-

charts/vela-core/templates/definitions/tasks.yaml

@@ -1,49 +0,0 @@
-apiVersion: core.oam.dev/v1alpha2
-kind: WorkloadDefinition
-metadata:
-  name: task
-  annotations:
-    definition.oam.dev/apiVersion: "v1"
-    definition.oam.dev/kind: "Job"
-    definition.oam.dev/description: "One-time off task or job"
-spec:
-  definitionRef:
-    name: jobs
-  extension:
-    defaultTraits:
-    - monitor
-    - logging
-    template: |
-      output: {
-        apiVersion: "v1"
-        kind:       "Job"
-        metadata: name: parameter.name
-        spec: {
-          parallelism: parameter.count
-            completions: parameter.count
-            template:
-              spec:
-                containers: [{
-                   image: parameter.image
-                     name:  parameter.name
-                     ports: [{
-                       containerPort: parameter.port
-                         protocol:      "TCP"
-                         name:          "default"
-                     }]
-                 }]
-        }
-      }
-      #task: {
-        // +usage=specify number of tasks to run in parallel
-        // +short=c
-        count: *1 | int
-        name:  string
-          // +usage=specify app image
-          // +short=i
-        image: string
-          // +usage=specify port for container
-          // +short=p
-        port: *6379 | int
-      }
-      parameter: #task

charts/vela-core/templates/defwithtemplate/autoscale.yaml

@@ -0,0 +1,73 @@
+apiVersion: core.oam.dev/v1alpha2
+kind: TraitDefinition
+metadata:
+  name: autoscale
+  annotations:
+    definition.oam.dev/apiVersion: standard.oam.dev/v1alpha1
+    definition.oam.dev/kind: Autoscaler
+    definition.oam.dev/description: "Automatically scale workloads"
+spec:
+  appliesToWorkloads:
+    - webservice
+    - backend
+    - deployments.apps
+    - podspecworkload
+  workloadRefPath: spec.workloadRef
+  definitionRef:
+    name: autoscalers.standard.oam.dev
+  extension:
+    template: |
+      output: {
+      	apiVersion: "standard.oam.dev/v1alpha1"
+      	kind:       "Autoscaler"
+      	spec: {
+      		minReplicas: parameter.min
+      		maxReplicas: parameter.max
+      		if parameter["cpu"] != _|_ && parameter["cron"] != _|_ {
+      			triggers: [cpuScaler, cronScaler]
+      		}
+      		if parameter["cpu"] != _|_ && parameter["cron"] == _|_ {
+      			triggers: [cpuScaler]
+      		}
+      		if parameter["cpu"] == _|_ && parameter["cron"] != _|_ {
+      			triggers: [cronScaler]
+      		}
+      	}
+      }
+      
+      cpuScaler: {
+      	type: "cpu"
+      	condition: {
+      		type: "Utilization"
+      		if parameter["cpu"] != _|_ {
+      			value: parameter.cpu
+      		}
+      	}
+      }
+      
+      cronScaler: {
+      	type: "cron"
+      	if parameter["cron"] != _|_ {
+      		condition: parameter.cron
+      	}
+      }
+      
+      parameter: {
+      	// +usage=minimal replicas of the workload
+      	min: int
+      	// +usage=maximal replicas of the workload
+      	max: int
+      	// +usage=specify the value for CPU utilization, like 80, which means 80%
+      	cpu?: string
+      	// +usage=just for `appfile`, not available for Cli usage
+      	cron?: {
+      		startAt:  string
+      		duration: string
+      		// +usage=several workdays or weekends, like "Monday, Tuesday"
+      		days:     string
+      		replicas: string
+      		// +usage=timezone, like "America/Seattle"
+      		timezone: string
+      	}
+      }
+      

charts/vela-core/templates/defwithtemplate/manualscale.yaml

@@ -6,12 +6,11 @@ metadata:
     definition.oam.dev/kind: ManualScalerTrait
     definition.oam.dev/description: "Scale replica for workload"
   name: scaler
-  namespace: default
 spec:
   appliesToWorkloads:
-    - core.oam.dev/v1alpha2.ContainerizedWorkload
-    - apps/v1.Deployment
     - webservice
+    - containerizedworkloads.core.oam.dev
+    - deployments.apps
   definitionRef:
     name: manualscalertraits.core.oam.dev
   workloadRefPath: spec.workloadRef
@@ -24,8 +23,8 @@ spec:
       		replicaCount: parameter.replica
       	}
       }
-      #scale: {
+      parameter: {
       	//+short=r
-      	replica: *2 | int
+      	replica: *1 | int
       }
-      parameter: #scale
+      

charts/vela-core/templates/defwithtemplate/metrics.yaml

@@ -0,0 +1,43 @@
+apiVersion: core.oam.dev/v1alpha2
+kind: TraitDefinition
+metadata:
+  name: metric
+  annotations:
+    definition.oam.dev/apiVersion: standard.oam.dev/v1alpha1
+    definition.oam.dev/kind: MetricsTrait
+    definition.oam.dev/description: "Add metric monitoring for workload"
+spec:
+  appliesToWorkloads:
+    - webservice
+    - backend
+    - task
+    - containerizedworkloads.core.oam.dev
+    - clonesetworkloads.apps.kruise.io
+    - deployments.apps
+    - statefulsets.apps
+  definitionRef:
+    name: metricstraits.standard.oam.dev
+  workloadRefPath: spec.workloadRef
+  extension:
+    template: |-
+      output: {
+      	apiVersion: "standard.oam.dev/v1alpha1"
+      	kind:       "MetricsTrait"
+      	spec: {
+      		scrapeService: parameter
+      	}
+      }
+      parameter: {
+      	// +usage=format of the metrics, default as prometheus
+      	// +short=f
+      	format: *"prometheus" | string
+      	// +usage= the metric path of the service
+      	path:    *"/metrics" | string
+      	scheme:  *"http" | string
+      	enabled: *true | bool
+      	// +usage= the port for metrics, will discovery automatically by default
+      	port: *0 | >=1024 & <=65535 & int
+      	// +usage= the label selector for the pods, will discovery automatically by default
+      	selector?: [string]: string
+      }
+      

charts/vela-core/templates/defwithtemplate/route.yaml

@@ -0,0 +1,43 @@
+apiVersion: core.oam.dev/v1alpha2
+kind: TraitDefinition
+metadata:
+  name: route
+  annotations:
+    definition.oam.dev/apiVersion: standard.oam.dev/v1alpha1
+    definition.oam.dev/kind: Route
+    definition.oam.dev/description: "Add a route for workload"
+spec:
+  appliesToWorkloads:
+    - webservice
+    - deployments.apps
+  workloadRefPath: spec.workloadRef
+  definitionRef:
+    name: routes.standard.oam.dev
+  extension:
+    template: |
+      output: {
+      	apiVersion: "standard.oam.dev/v1alpha1"
+      	kind:       "Route"
+      	spec: {
+      		host: parameter.domain
+      
+      		if parameter.issuer != "" {
+      			tls: {
+      				issuerName: parameter.issuer
+      			}
+      		}
+      
+      		if parameter["rules"] != _|_ {
+      			rules: parameter.rules
+      		}
+      	}
+      }
+      parameter: {
+      	domain: *"" | string
+      	issuer: *"" | string
+      	rules?: [...{
+      		path:          string
+      		rewriteTarget: *"" | string
+      	}]
+      }
+      

charts/vela-core/templates/defwithtemplate/task.yaml

@@ -0,0 +1,43 @@
+apiVersion: core.oam.dev/v1alpha2
+kind: WorkloadDefinition
+metadata:
+  name: task
+  annotations:
+    definition.oam.dev/apiVersion: "v1"
+    definition.oam.dev/kind: "Job"
+    definition.oam.dev/description: "One-time task/job"
+spec:
+  definitionRef:
+    name: jobs
+  extension:
+    template: |
+      output: {
+      	apiVersion: "v1"
+      	kind:       "Job"
+      	spec: {
+      		parallelism: parameter.count
+      		completions: parameter.count
+      		template: spec: {
+      			containers: [{
+      				name:  context.name
+      				image: parameter.image
+      
+      				if parameter["cmd"] != _|_ {
+      					command: parameter.cmd
+      				}
+      			}]
+      		}
+      	}
+      }
+      parameter: {
+      	// +usage=specify number of tasks to run in parallel
+      	// +short=c
+      	count: *1 | int
+      
+      	// +usage=specify app image
+      	// +short=i
+      	image: string
+      
+      	cmd?: [...string]
+      }
+      

charts/vela-core/templates/defwithtemplate/webservice.yaml

@@ -0,0 +1,91 @@
+apiVersion: core.oam.dev/v1alpha2
+kind: WorkloadDefinition
+metadata:
+  name: webservice
+  annotations:
+    definition.oam.dev/apiVersion: "apps/v1"
+    definition.oam.dev/kind: "Deployment"
+    definition.oam.dev/description: "Long running service with network routes"
+spec:
+  definitionRef:
+    name: deployments.apps
+  extension:
+    template: |
+      output: {
+      	apiVersion: "apps/v1"
+      	kind:       "Deployment"
+      	spec: {
+      		selector: matchLabels: {
+      			"app.oam.dev/component": context.name
+      		}
+      
+      		template: {
+      			metadata: labels: {
+      				"app.oam.dev/component": context.name
+      			}
+      
+      			spec: {
+      				containers: [{
+      					name:  context.name
+      					image: parameter.image
+      
+      					if parameter["cmd"] != _|_ {
+      						command: parameter.cmd
+      					}
+      
+      					if parameter["env"] != _|_ {
+      						env: parameter.env
+      					}
+      
+      					if context["config"] != _|_ {
+      						env: [
+      							for k, v in context.config {
+      								name:  k
+      								value: v
+      							},
+      						]
+      					}
+      
+      					ports: [{
+      						containerPort: parameter.port
+      					}]
+      
+      					if parameter["cpuRequests"] != _|_ {
+      						resources: {
+      							limits:
+      								cpu: parameter.cpuRequests
+      							requests:
+      								cpu: parameter.cpuRequests
+      						}
+      					}
+      				}]
+      		}
+      		}
+      	}
+      }
+      parameter: {
+      	// +usage=specify app image
+      	// +short=i
+      	image: string
+      
+      	cmd?: [...string]
+      
+      	// +usage=specify port for container
+      	// +short=p
+      	port: *6379 | int
+      
+      	env?: [...{
+      		name:   string
+      		value?: string
+      		valueFrom?: {
+      			secretKeyRef: {
+      				name: string
+      				key:  string
+      			}
+      		}
+      	}]
+      	// +usage=CPU core requests for the workload
+      	// +alias=cpu-requests
+      	cpuRequests?: string
+      }
+      

charts/vela-core/templates/defwithtemplate/worker.yaml

@@ -0,0 +1,52 @@
+apiVersion: core.oam.dev/v1alpha2
+kind: WorkloadDefinition
+metadata:
+  name: worker
+  annotations:
+    definition.oam.dev/apiVersion: "apps/v1"
+    definition.oam.dev/kind: "Deployment"
+    definition.oam.dev/description: "Backend worker without ports exposed"
+spec:
+  definitionRef:
+    name: deployments.apps
+  extension:
+    template: |
+      output: {
+      	apiVersion: "apps/v1"
+      	kind:       "Deployment"
+      	spec: {
+      		selector: matchLabels: {
+      			"app.oam.dev/component": context.name
+      		}
+      
+      		template: {
+      			metadata: labels: {
+      				"app.oam.dev/component": context.name
+      			}
+      
+      			spec: {
+      				containers: [{
+      					name:  context.name
+      					image: parameter.image
+      
+      					if parameter["cmd"] != _|_ {
+      						command: parameter.cmd
+      					}
+      				}]
+      			}
+      		}
+      
+      		selector:
+      			matchLabels:
+      				"app.oam.dev/component": context.name
+      	}
+      }
+      
+      parameter: {
+      	// +usage=specify app image
+      	// +short=i
+      	image: string
+      
+      	cmd?: [...string]
+      }
+      

charts/vela-core/templates/velaConfig.yaml

@@ -4,14 +4,6 @@ metadata:
   name: vela-config
   namespace: {{ .Release.Namespace }}
 data:
-  certificates.cert-manager.io: |
-    {
-      "repo": "jetstack",
-      "urL": "https://charts.jetstack.io",
-      "name": "cert-manager",
-      "namespace": "cert-manager",
-      "version": "1.0.3"
-    }
   servicemonitors.monitoring.coreos.com: |
     {
       "repo": "prometheus-community",
@@ -19,4 +11,20 @@ data:
       "name": "kube-prometheus-stack",
       "namespace": "monitoring",
       "version": "9.4.4"
-    }
+    }
+  flagger.app: |
+    {
+      "repo": "flagger",
+      "urL": "https://flagger.app",
+      "name": "flagger",
+      "namespace": "vela-system",
+      "version": "1.2.0"
+    }
+  keda: |
+    {
+      "repo": "kedacore",
+      "urL": "https://kedacore.github.io/charts",
+      "name": "keda",
+      "namespace": "keda",
+      "version": "2.0.0-rc3"
+    }

charts/vela-core/values.yaml

@@ -7,7 +7,7 @@ useWebhook: true
 image:
   repository: oamdev/vela-core
   tag: latest
-  pullPolicy: Always
+  pullPolicy: IfNotPresent
 
 imagePullSecrets: []
 nameOverride: ""

cmd/core/main.go

@@ -6,8 +6,10 @@ import (
 	"fmt"
 	"io"
 	"os"
+	"os/signal"
 	"path/filepath"
 	"strconv"
+	"syscall"
 	"time"
 
 	monitoring "github.com/coreos/prometheus-operator/pkg/apis/monitoring/v1"
@@ -16,11 +18,13 @@ import (
 	oamcontroller "github.com/crossplane/oam-kubernetes-runtime/pkg/controller"
 	oamv1alpha2 "github.com/crossplane/oam-kubernetes-runtime/pkg/controller/v1alpha2"
 	oamwebhook "github.com/crossplane/oam-kubernetes-runtime/pkg/webhook/v1alpha2"
+	"github.com/go-logr/logr"
 	injectorv1alpha1 "github.com/oam-dev/trait-injector/api/v1alpha1"
 	injectorcontroller "github.com/oam-dev/trait-injector/controllers"
 	"github.com/oam-dev/trait-injector/pkg/injector"
 	"github.com/oam-dev/trait-injector/pkg/plugin"
 	certmanager "github.com/wonderflow/cert-manager-api/pkg/apis/certmanager/v1"
+	kedav1alpha1 "github.com/wonderflow/keda-api/api/v1alpha1"
 	"go.uber.org/zap/zapcore"
 	"gopkg.in/natefinch/lumberjack.v2"
 	crdv1 "k8s.io/apiextensions-apiserver/pkg/apis/apiextensions/v1"
@@ -58,7 +62,7 @@ func init() {
 	_ = velacoreoamdev.AddToScheme(scheme)
 	_ = injectorv1alpha1.AddToScheme(scheme)
 	_ = certmanager.AddToScheme(scheme)
-
+	_ = kedav1alpha1.AddToScheme(scheme)
 	// +kubebuilder:scaffold:scheme
 }
 
@@ -110,10 +114,7 @@ func main() {
 		setupLog.Error(err, "unable to create a kubernetes client")
 		os.Exit(1)
 	}
-	if err = dependency.Install(k8sClient); err != nil {
-		setupLog.Error(err, "unable to install the dependency")
-		os.Exit(1)
-	}
+	go dependency.Install(k8sClient)
 
 	mgr, err := ctrl.NewManager(ctrl.GetConfigOrDie(), ctrl.Options{
 		Scheme:                 scheme,
@@ -136,7 +137,10 @@ func main() {
 
 	if useWebhook {
 		setupLog.Info("vela webhook enabled, will serving at :" + strconv.Itoa(webhookPort))
-		oamwebhook.Add(mgr)
+		if err = oamwebhook.Add(mgr); err != nil {
+			setupLog.Error(err, "unable to setup oam runtime webhook")
+			os.Exit(1)
+		}
 		velawebhook.Register(mgr)
 		if err := waitWebhookSecretVolume(certDir, waitSecretTimeout, waitSecretInterval); err != nil {
 			setupLog.Error(err, "unable to get webhook secret")
@@ -173,10 +177,11 @@ func main() {
 	}
 
 	setupLog.Info("starting the vela controller manager")
-	if err := mgr.Start(ctrl.SetupSignalHandler()); err != nil {
+	if err := mgr.Start(makeSignalHandler(setupLog, k8sClient)); err != nil {
 		setupLog.Error(err, "problem running manager")
 		os.Exit(1)
 	}
+	setupLog.Info("program safely stops...")
 }
 
 // registerHealthChecks is used to create readiness&liveness probes
@@ -203,25 +208,53 @@ func waitWebhookSecretVolume(certDir string, timeout, interval time.Duration) er
 		setupLog.Info(fmt.Sprintf("waiting webhook secret, time consumed: %d/%d seconds ...",
 			int64(time.Since(start).Seconds()), int64(timeout.Seconds())))
 		if _, err := os.Stat(certDir); !os.IsNotExist(err) {
-			f, _ := os.Open(certDir)
-			defer f.Close()
-			// check if dir is empty
-			if _, err := f.Readdir(1); err == io.EOF {
-				continue
-			}
-			// check if secret files are empty
-			err := filepath.Walk(certDir, func(path string, info os.FileInfo, err error) error {
-				// even Cert dir is created, cert files are still empty for a while
-				if info.Size() == 0 {
-					return errors.New("secret is not ready")
+			ready := func() bool {
+				f, _ := os.Open(certDir)
+				defer f.Close()
+				// check if dir is empty
+				if _, err := f.Readdir(1); err == io.EOF {
+					return false
 				}
-				return nil
-			})
-			if err == nil {
-				setupLog.Info(fmt.Sprintf("webhook secret is ready (time consumed: %d seconds)",
-					int64(time.Since(start).Seconds())))
+				// check if secret files are empty
+				err := filepath.Walk(certDir, func(path string, info os.FileInfo, err error) error {
+					// even Cert dir is created, cert files are still empty for a while
+					if info.Size() == 0 {
+						return errors.New("secret is not ready")
+					}
+					return nil
+				})
+				if err == nil {
+					setupLog.Info(fmt.Sprintf("webhook secret is ready (time consumed: %d seconds)",
+						int64(time.Since(start).Seconds())))
+					return true
+				}
+				return false
+			}()
+			if ready {
 				return nil
 			}
 		}
 	}
 }
+
+func makeSignalHandler(log logr.Logger, kubecli client.Client) (stopCh <-chan struct{}) {
+	stop := make(chan struct{})
+	c := make(chan os.Signal, 2)
+
+	signal.Notify(c, os.Interrupt, syscall.SIGTERM)
+
+	go func() {
+		<-c
+		// Do not uninstall when vela-core terminating.
+		// When running on K8s, old pod will terminate after new pod running, it will cause charts uninstalled.
+		// https://github.com/oam-dev/kubevela/issues/499
+		// dependency.Uninstall(kubecli)
+		close(stop)
+
+		// second signal. Exit directly.
+		<-c
+		os.Exit(1)
+	}()
+
+	return stop
+}

codecov.yml

@@ -0,0 +1,3 @@
+coverage:
+  status:
+    patch: off

docs/README.md

@@ -0,0 +1,34 @@
+# KubeVela Documentation
+
+Learn and use KubeVela with tutorials and user stories.
+
+**Overview**
+- [Introduction](introduction.md)
+- [Installation](./install.md)
+- [Quick Start](quick-start.md)
+- [Concepts](concepts.md)
+
+**For Developers**
+- [Setting Up Deployment Environment](developers/config-enviroments.md)
+- [Initializing Application](developers/app-init.md)
+- [Setting Routes](developers/set-route.md)
+- [Setting Auto-scaling Policy](developers/set-autoscale.md)
+- [Setting Rollout Strategy](developers/set-rollout.md)
+- [Monitoring Application](developers/set-metrics.md)
+- [Using Appfile](developers/devex/appfile.md)
+- [Check Application Logs](developers/check-logs.md)
+- [Execute Commands in Container](developers/exec-cmd.md)
+- [Port Forward to Container](developers/port-forward.md)
+- [Configuring data/env in Application](developers/config-app.md)
+- [Consuming Cloud Services](developers/cloud-service.md)
+- [Managing Capabilities](developers/cap-center.md)
+- [Capability References](developers/references/README.md)
+
+**For Platform Engineers**
+- [Extending KubeVela](platform-engineers/extending-kubevela.md)
+
+**Internals**
+- [Design and Architecture](design.md)
+
+**Roadmap**
+- [Roadmap of KubeVela](roadmap.md)

docs/cli/vela.md

@@ -19,23 +19,30 @@ vela [flags]
 
 ### SEE ALSO
 
-* [vela app](vela_app.md)	 - Manage applications
+* [vela autoscale](vela_autoscale.md)	 - Attach autoscale trait to an app
 * [vela cap](vela_cap.md)	 - Capability Management
-* [vela comp](vela_comp.md)	 - Manage Components
 * [vela completion](vela_completion.md)	 - Output shell completion code for the specified shell (bash or zsh)
+* [vela config](vela_config.md)	 - Manage application configurations
 * [vela dashboard](vela_dashboard.md)	 - Setup API Server and launch Dashboard
+* [vela delete](vela_delete.md)	 - Delete Applications
 * [vela env](vela_env.md)	 - Manage application environments
+* [vela exec](vela_exec.md)	 - Execute a command in a container
 * [vela init](vela_init.md)	 - Init an OAM Application
 * [vela install](vela_install.md)	 - Initialize vela on both client and server
-* [vela logs](vela_logs.md)	 - Tail pods logs of an application
-* [vela metrics](vela_metrics.md)	 - Attach metrics trait to an app
+* [vela logs](vela_logs.md)	 - Tail logs for application
+* [vela ls](vela_ls.md)	 - List services
+* [vela metric](vela_metric.md)	 - Attach metric trait to an app
+* [vela port-forward](vela_port-forward.md)	 - Forward one or more local ports to a Pod of a service in an application
 * [vela route](vela_route.md)	 - Attach route trait to an app
-* [vela scale](vela_scale.md)	 - Attach scale trait to an app
-* [vela system](vela_system.md)	 - system management utilities
+* [vela scaler](vela_scaler.md)	 - Attach scaler trait to an app
+* [vela show](vela_show.md)	 - Get details of an application
+* [vela status](vela_status.md)	 - get status of an application
+* [vela svc](vela_svc.md)	 - Manage services
+* [vela system](vela_system.md)	 - System management utilities
 * [vela template](vela_template.md)	 - Manage templates
 * [vela traits](vela_traits.md)	 - List traits
 * [vela up](vela_up.md)	 - Apply an appfile
 * [vela version](vela_version.md)	 - Prints out build version information
 * [vela workloads](vela_workloads.md)	 - List workloads
 
-###### Auto generated by spf13/cobra on 20-Oct-2020
+###### Auto generated by spf13/cobra on 6-Nov-2020

docs/cli/vela_autoscale.md

@@ -0,0 +1,47 @@
+## vela autoscale
+
+Attach autoscale trait to an app
+
+### Synopsis
+
+Attach autoscale trait to an app
+
+```
+vela autoscale <appname> [args]
+```
+
+### Examples
+
+```
+vela autoscale frontend
+```
+
+### Options
+
+```
+      --days string       
+      --detach            detach trait from service
+      --duration string   
+  -h, --help              help for autoscale
+      --maxReplicas int    (default 4)
+      --minReplicas int    (default 1)
+      --name string       
+      --replicas string    (default "2")
+  -s, --staging           only save changes locally without real update application
+      --startAt string    
+      --svc string        specify one service belonging to the application
+      --timezone string    (default "Asia/Shanghai")
+      --type string        (default "cron")
+```
+
+### Options inherited from parent commands
+
+```
+  -e, --env string   specify environment name for application
+```
+
+### SEE ALSO
+
+* [vela](vela.md)	 - 
+
+###### Auto generated by spf13/cobra on 6-Nov-2020

docs/cli/vela_cap.md

@@ -21,9 +21,9 @@ Capability Management with config, list, add, remove capabilities
 ### SEE ALSO
 
 * [vela](vela.md)	 - 
-* [vela cap add](vela_cap_add.md)	 - Add capability into cluster
 * [vela cap center](vela_cap_center.md)	 - Manage Capability Center
-* [vela cap ls](vela_cap_ls.md)	 - List all capabilities in center
-* [vela cap remove](vela_cap_remove.md)	 - Remove capability from cluster
+* [vela cap install](vela_cap_install.md)	 - Install capability into cluster
+* [vela cap ls](vela_cap_ls.md)	 - List capabilities from cap-center
+* [vela cap uninstall](vela_cap_uninstall.md)	 - Uninstall capability from cluster
 
-###### Auto generated by spf13/cobra on 20-Oct-2020
+###### Auto generated by spf13/cobra on 6-Nov-2020

docs/cli/vela_cap_center.md

@@ -21,9 +21,9 @@ Manage Capability Center with config, sync, list
 ### SEE ALSO
 
 * [vela cap](vela_cap.md)	 - Capability Management
-* [vela cap center config](vela_cap_center_config.md)	 - Configure or add the capability center, default is local (built-in capabilities)
+* [vela cap center config](vela_cap_center_config.md)	 - Configure (add if not exist) a capability center, default is local (built-in capabilities)
 * [vela cap center ls](vela_cap_center_ls.md)	 - List all capability centers
 * [vela cap center remove](vela_cap_center_remove.md)	 - Remove specified capability center
 * [vela cap center sync](vela_cap_center_sync.md)	 - Sync capabilities from remote center, default to sync all centers
 
-###### Auto generated by spf13/cobra on 20-Oct-2020
+###### Auto generated by spf13/cobra on 6-Nov-2020

docs/cli/vela_cap_center_config.md

@@ -1,10 +1,10 @@
 ## vela cap center config
 
-Configure or add the capability center, default is local (built-in capabilities)
+Configure (add if not exist) a capability center, default is local (built-in capabilities)
 
 ### Synopsis
 
-Configure or add the capability center, default is local (built-in capabilities)
+Configure (add if not exist) a capability center, default is local (built-in capabilities)
 
 ```
 vela cap center config <centerName> <centerURL> [flags]
@@ -33,4 +33,4 @@ vela cap center config mycenter https://github.com/oam-dev/catalog/cap-center
 
 * [vela cap center](vela_cap_center.md)	 - Manage Capability Center
 
-###### Auto generated by spf13/cobra on 20-Oct-2020
+###### Auto generated by spf13/cobra on 6-Nov-2020

docs/cli/vela_cap_center_ls.md

@@ -32,4 +32,4 @@ vela cap center ls
 
 * [vela cap center](vela_cap_center.md)	 - Manage Capability Center
 
-###### Auto generated by spf13/cobra on 20-Oct-2020
+###### Auto generated by spf13/cobra on 6-Nov-2020

docs/cli/vela_cap_center_remove.md

@@ -32,4 +32,4 @@ vela cap center remove mycenter
 
 * [vela cap center](vela_cap_center.md)	 - Manage Capability Center
 
-###### Auto generated by spf13/cobra on 20-Oct-2020
+###### Auto generated by spf13/cobra on 6-Nov-2020

docs/cli/vela_cap_center_sync.md

@@ -32,4 +32,4 @@ vela cap center sync mycenter
 
 * [vela cap center](vela_cap_center.md)	 - Manage Capability Center
 
-###### Auto generated by spf13/cobra on 20-Oct-2020
+###### Auto generated by spf13/cobra on 6-Nov-2020

docs/cli/vela_cap_install.md

@@ -1,25 +1,25 @@
-## vela cap add
+## vela cap install
 
-Add capability into cluster
+Install capability into cluster
 
 ### Synopsis
 
-Add capability into cluster
+Install capability into cluster
 
 ```
-vela cap add <center>/<name> [flags]
+vela cap install <center>/<name> [flags]
 ```
 
 ### Examples
 
 ```
-vela cap add mycenter/route
+vela cap install mycenter/route
 ```
 
 ### Options
 
 ```
-  -h, --help           help for add
+  -h, --help           help for install
   -t, --token string   Github Repo token
 ```
 
@@ -33,4 +33,4 @@ vela cap add mycenter/route
 
 * [vela cap](vela_cap.md)	 - Capability Management
 
-###### Auto generated by spf13/cobra on 20-Oct-2020
+###### Auto generated by spf13/cobra on 6-Nov-2020

docs/cli/vela_cap_ls.md

@@ -1,13 +1,13 @@
 ## vela cap ls
 
-List all capabilities in center
+List capabilities from cap-center
 
 ### Synopsis
 
-List all capabilities in center
+List capabilities from cap-center
 
 ```
-vela cap ls [centerName] [flags]
+vela cap ls [cap-center] [flags]
 ```
 
 ### Examples
@@ -32,4 +32,4 @@ vela cap ls
 
 * [vela cap](vela_cap.md)	 - Capability Management
 
-###### Auto generated by spf13/cobra on 20-Oct-2020
+###### Auto generated by spf13/cobra on 6-Nov-2020

docs/cli/vela_cap_uninstall.md

@@ -1,25 +1,25 @@
-## vela cap remove
+## vela cap uninstall
 
-Remove capability from cluster
+Uninstall capability from cluster
 
 ### Synopsis
 
-Remove capability from cluster
+Uninstall capability from cluster
 
 ```
-vela cap remove <name> [flags]
+vela cap uninstall <name> [flags]
 ```
 
 ### Examples
 
 ```
-vela cap remove route
+vela cap uninstall route
 ```
 
 ### Options
 
 ```
-  -h, --help           help for remove
+  -h, --help           help for uninstall
   -t, --token string   Github Repo token
 ```
 
@@ -33,4 +33,4 @@ vela cap remove route
 
 * [vela cap](vela_cap.md)	 - Capability Management
 
-###### Auto generated by spf13/cobra on 20-Oct-2020
+###### Auto generated by spf13/cobra on 6-Nov-2020

docs/cli/vela_completion.md

@@ -27,4 +27,4 @@ of vela commands.
 * [vela completion bash](vela_completion_bash.md)	 - generate autocompletions script for bash
 * [vela completion zsh](vela_completion_zsh.md)	 - generate autocompletions script for zsh
 
-###### Auto generated by spf13/cobra on 20-Oct-2020
+###### Auto generated by spf13/cobra on 6-Nov-2020

docs/cli/vela_completion_bash.md

@@ -36,4 +36,4 @@ vela completion bash
 
 * [vela completion](vela_completion.md)	 - Output shell completion code for the specified shell (bash or zsh)
 
-###### Auto generated by spf13/cobra on 20-Oct-2020
+###### Auto generated by spf13/cobra on 6-Nov-2020

docs/cli/vela_completion_zsh.md

@@ -33,4 +33,4 @@ vela completion zsh
 
 * [vela completion](vela_completion.md)	 - Output shell completion code for the specified shell (bash or zsh)
 
-###### Auto generated by spf13/cobra on 20-Oct-2020
+###### Auto generated by spf13/cobra on 6-Nov-2020

docs/cli/vela_config.md

@@ -0,0 +1,29 @@
+## vela config
+
+Manage application configurations
+
+### Synopsis
+
+Manage application configurations under given env
+
+### Options
+
+```
+  -h, --help   help for config
+```
+
+### Options inherited from parent commands
+
+```
+  -e, --env string   specify environment name for application
+```
+
+### SEE ALSO
+
+* [vela](vela.md)	 - 
+* [vela config del](vela_config_del.md)	 - Delete config
+* [vela config get](vela_config_get.md)	 - Get data for a config
+* [vela config ls](vela_config_ls.md)	 - List configs
+* [vela config set](vela_config_set.md)	 - Set data for a config
+
+###### Auto generated by spf13/cobra on 6-Nov-2020

docs/cli/vela_config_del.md

@@ -0,0 +1,35 @@
+## vela config del
+
+Delete config
+
+### Synopsis
+
+Delete config
+
+```
+vela config del
+```
+
+### Examples
+
+```
+vela config del <config-name>
+```
+
+### Options
+
+```
+  -h, --help   help for del
+```
+
+### Options inherited from parent commands
+
+```
+  -e, --env string   specify environment name for application
+```
+
+### SEE ALSO
+
+* [vela config](vela_config.md)	 - Manage application configurations
+
+###### Auto generated by spf13/cobra on 6-Nov-2020

docs/cli/vela_config_get.md

@@ -0,0 +1,35 @@
+## vela config get
+
+Get data for a config
+
+### Synopsis
+
+Get data for a config
+
+```
+vela config get
+```
+
+### Examples
+
+```
+vela config get <config-name>
+```
+
+### Options
+
+```
+  -h, --help   help for get
+```
+
+### Options inherited from parent commands
+
+```
+  -e, --env string   specify environment name for application
+```
+
+### SEE ALSO
+
+* [vela config](vela_config.md)	 - Manage application configurations
+
+###### Auto generated by spf13/cobra on 6-Nov-2020

docs/cli/vela_config_ls.md

@@ -0,0 +1,35 @@
+## vela config ls
+
+List configs
+
+### Synopsis
+
+List all configs
+
+```
+vela config ls
+```
+
+### Examples
+
+```
+vela config ls
+```
+
+### Options
+
+```
+  -h, --help   help for ls
+```
+
+### Options inherited from parent commands
+
+```
+  -e, --env string   specify environment name for application
+```
+
+### SEE ALSO
+
+* [vela config](vela_config.md)	 - Manage application configurations
+
+###### Auto generated by spf13/cobra on 6-Nov-2020

docs/cli/vela_config_set.md

@@ -0,0 +1,35 @@
+## vela config set
+
+Set data for a config
+
+### Synopsis
+
+Set data for a config
+
+```
+vela config set
+```
+
+### Examples
+
+```
+vela config set <config-name> KEY=VALUE K2=V2
+```
+
+### Options
+
+```
+  -h, --help   help for set
+```
+
+### Options inherited from parent commands
+
+```
+  -e, --env string   specify environment name for application
+```
+
+### SEE ALSO
+
+* [vela config](vela_config.md)	 - Manage application configurations
+
+###### Auto generated by spf13/cobra on 6-Nov-2020

docs/cli/vela_dashboard.md

@@ -38,4 +38,4 @@ dashboard
 
 * [vela](vela.md)	 - 
 
-###### Auto generated by spf13/cobra on 20-Oct-2020
+###### Auto generated by spf13/cobra on 6-Nov-2020

docs/cli/vela_delete.md

@@ -0,0 +1,36 @@
+## vela delete
+
+Delete Applications
+
+### Synopsis
+
+Delete Applications
+
+```
+vela delete <APPLICATION_NAME>
+```
+
+### Examples
+
+```
+vela delete frontend
+```
+
+### Options
+
+```
+  -h, --help         help for delete
+      --svc string   delete only the specified service in this app
+```
+
+### Options inherited from parent commands
+
+```
+  -e, --env string   specify environment name for application
+```
+
+### SEE ALSO
+
+* [vela](vela.md)	 - 
+
+###### Auto generated by spf13/cobra on 6-Nov-2020

docs/cli/vela_env.md

@@ -26,4 +26,4 @@ Manage application environments
 * [vela env ls](vela_env_ls.md)	 - List environments
 * [vela env set](vela_env_set.md)	 - Set an environment
 
-###### Auto generated by spf13/cobra on 20-Oct-2020
+###### Auto generated by spf13/cobra on 6-Nov-2020

docs/cli/vela_env_delete.md

@@ -32,4 +32,4 @@ vela env delete test
 
 * [vela env](vela_env.md)	 - Manage application environments
 
-###### Auto generated by spf13/cobra on 20-Oct-2020
+###### Auto generated by spf13/cobra on 6-Nov-2020

docs/cli/vela_env_init.md

@@ -22,7 +22,7 @@ vela env init test --namespace test --email my@email.com
       --domain string      specify domain your applications
       --email string       specify email for production TLS Certificate notification
   -h, --help               help for init
-      --namespace string   specify K8s namespace for env (default "default")
+      --namespace string   specify K8s namespace for env
 ```
 
 ### Options inherited from parent commands
@@ -35,4 +35,4 @@ vela env init test --namespace test --email my@email.com
 
 * [vela env](vela_env.md)	 - Manage application environments
 
-###### Auto generated by spf13/cobra on 20-Oct-2020
+###### Auto generated by spf13/cobra on 6-Nov-2020

docs/cli/vela_env_ls.md

@@ -13,7 +13,7 @@ vela env ls
 ### Examples
 
 ```
-vela env list [env-name]
+vela env ls [env-name]
 ```
 
 ### Options
@@ -32,4 +32,4 @@ vela env list [env-name]
 
 * [vela env](vela_env.md)	 - Manage application environments
 
-###### Auto generated by spf13/cobra on 20-Oct-2020
+###### Auto generated by spf13/cobra on 6-Nov-2020

docs/cli/vela_env_set.md

@@ -32,4 +32,4 @@ vela env set test
 
 * [vela env](vela_env.md)	 - Manage application environments
 
-###### Auto generated by spf13/cobra on 20-Oct-2020
+###### Auto generated by spf13/cobra on 6-Nov-2020

docs/cli/vela_exec.md

@@ -0,0 +1,32 @@
+## vela exec
+
+Execute a command in a container
+
+### Synopsis
+
+Execute a command in the 1st container of specific Application => Service => (1st)Pod
+
+```
+vela exec [flags] AppName -- COMMAND [args...]
+```
+
+### Options
+
+```
+  -h, --help                           help for exec
+      --pod-running-timeout duration   The length of time (like 5s, 2m, or 3h, higher than zero) to wait until at least one pod is running (default 1m0s)
+  -i, --stdin                          Pass stdin to the container (default true)
+  -t, --tty                            Stdin is a TTY (default true)
+```
+
+### Options inherited from parent commands
+
+```
+  -e, --env string   specify environment name for application
+```
+
+### SEE ALSO
+
+* [vela](vela.md)	 - 
+
+###### Auto generated by spf13/cobra on 6-Nov-2020

docs/cli/vela_init.md

@@ -19,7 +19,8 @@ vela init
 ### Options
 
 ```
-  -h, --help   help for init
+  -h, --help          help for init
+      --render-only   Rendering vela.yaml in current dir and do not deploy
 ```
 
 ### Options inherited from parent commands
@@ -32,4 +33,4 @@ vela init
 
 * [vela](vela.md)	 - 
 
-###### Auto generated by spf13/cobra on 20-Oct-2020
+###### Auto generated by spf13/cobra on 6-Nov-2020

docs/cli/vela_install.md

@@ -14,10 +14,11 @@ vela install [flags]
 
 ```
   -h, --help                       help for install
-      --image-pull-policy string   vela core image pull policy, this will align to chart value image.pullPolicy (default "Always")
+      --image-pull-policy string   vela core image pull policy, this will align to chart value image.pullPolicy (default "IfNotPresent")
       --image-repo string          vela core image repo, this will align to chart value image.repo (default "oamdev/vela-core")
       --image-tag string           vela core image repo, this will align to chart value image.tag (default "latest")
   -p, --vela-chart-path string     path to vela core chart to override default chart
+  -w, --wait                       wait until vela-core is ready to serve
 ```
 
 ### Options inherited from parent commands
@@ -30,4 +31,4 @@ vela install [flags]
 
 * [vela](vela.md)	 - 
 
-###### Auto generated by spf13/cobra on 20-Oct-2020
+###### Auto generated by spf13/cobra on 6-Nov-2020

docs/cli/vela_logs.md

@@ -0,0 +1,30 @@
+## vela logs
+
+Tail logs for application
+
+### Synopsis
+
+Tail logs for application
+
+```
+vela logs [flags]
+```
+
+### Options
+
+```
+  -h, --help            help for logs
+  -o, --output string   output format for logs, support: [default, raw, json] (default "default")
+```
+
+### Options inherited from parent commands
+
+```
+  -e, --env string   specify environment name for application
+```
+
+### SEE ALSO
+
+* [vela](vela.md)	 - 
+
+###### Auto generated by spf13/cobra on 6-Nov-2020

docs/cli/vela_ls.md

@@ -0,0 +1,36 @@
+## vela ls
+
+List services
+
+### Synopsis
+
+List services with their application, type, traits, status and created time, etc.
+
+```
+vela ls
+```
+
+### Examples
+
+```
+vela ls
+```
+
+### Options
+
+```
+      --app string   specify the name of application
+  -h, --help         help for ls
+```
+
+### Options inherited from parent commands
+
+```
+  -e, --env string   specify environment name for application
+```
+
+### SEE ALSO
+
+* [vela](vela.md)	 - 
+
+###### Auto generated by spf13/cobra on 6-Nov-2020

docs/cli/vela_metric.md

@@ -0,0 +1,43 @@
+## vela metric
+
+Attach metric trait to an app
+
+### Synopsis
+
+Attach metric trait to an app
+
+```
+vela metric <appname> [args]
+```
+
+### Examples
+
+```
+vela metric frontend
+```
+
+### Options
+
+```
+      --detach          detach trait from service
+      --enabled          (default true)
+  -f, --format string   format of the metrics, default as prometheus (default "prometheus")
+  -h, --help            help for metric
+      --path string      the metric path of the service (default "/metrics")
+      --port int         the port for metrics, will discovery automatically by default
+      --scheme string    (default "http")
+  -s, --staging         only save changes locally without real update application
+      --svc string      specify one service belonging to the application
+```
+
+### Options inherited from parent commands
+
+```
+  -e, --env string   specify environment name for application
+```
+
+### SEE ALSO
+
+* [vela](vela.md)	 - 
+
+###### Auto generated by spf13/cobra on 6-Nov-2020

docs/cli/vela_port-forward.md

@@ -0,0 +1,31 @@
+## vela port-forward
+
+Forward one or more local ports to a Pod of a service in an application
+
+### Synopsis
+
+Forward one or more local ports to a Pod of a service in an application
+
+```
+vela port-forward APP_NAME [options] [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N] [flags]
+```
+
+### Options
+
+```
+      --address strings                Addresses to listen on (comma separated). Only accepts IP addresses or localhost as a value. When localhost is supplied, vela will try to bind on both 127.0.0.1 and ::1 and will fail if neither of these addresses are available to bind. (default [localhost])
+  -h, --help                           help for port-forward
+      --pod-running-timeout duration   The length of time (like 5s, 2m, or 3h, higher than zero) to wait until at least one pod is running (default 1m0s)
+```
+
+### Options inherited from parent commands
+
+```
+  -e, --env string   specify environment name for application
+```
+
+### SEE ALSO
+
+* [vela](vela.md)	 - 
+
+###### Auto generated by spf13/cobra on 6-Nov-2020

docs/cli/vela_route.md

@@ -19,14 +19,12 @@ vela route frontend
 ### Options
 
 ```
-  -a, --app string      create or add into an existing application group
-      --detach          detach trait from component
+      --detach          detach trait from service
       --domain string   
   -h, --help            help for route
       --issuer string   
-      --path string     
-      --port int         (default 443)
   -s, --staging         only save changes locally without real update application
+      --svc string      specify one service belonging to the application
 ```
 
 ### Options inherited from parent commands
@@ -39,4 +37,4 @@ vela route frontend
 
 * [vela](vela.md)	 - 
 
-###### Auto generated by spf13/cobra on 20-Oct-2020
+###### Auto generated by spf13/cobra on 6-Nov-2020

docs/cli/vela_scaler.md

@@ -0,0 +1,39 @@
+## vela scaler
+
+Attach scaler trait to an app
+
+### Synopsis
+
+Attach scaler trait to an app
+
+```
+vela scaler <appname> [args]
+```
+
+### Examples
+
+```
+vela scaler frontend
+```
+
+### Options
+
+```
+      --detach        detach trait from service
+  -h, --help          help for scaler
+  -r, --replica int    (default 1)
+  -s, --staging       only save changes locally without real update application
+      --svc string    specify one service belonging to the application
+```
+
+### Options inherited from parent commands
+
+```
+  -e, --env string   specify environment name for application
+```
+
+### SEE ALSO
+
+* [vela](vela.md)	 - 
+
+###### Auto generated by spf13/cobra on 6-Nov-2020

docs/cli/vela_show.md

@@ -0,0 +1,36 @@
+## vela show
+
+Get details of an application
+
+### Synopsis
+
+Get details of an application
+
+```
+vela show <APPLICATION-NAME> [flags]
+```
+
+### Examples
+
+```
+vela show <APPLICATION-NAME>
+```
+
+### Options
+
+```
+  -h, --help         help for show
+  -s, --svc string   service name
+```
+
+### Options inherited from parent commands
+
+```
+  -e, --env string   specify environment name for application
+```
+
+### SEE ALSO
+
+* [vela](vela.md)	 - 
+
+###### Auto generated by spf13/cobra on 6-Nov-2020

docs/cli/vela_status.md

@@ -1,13 +1,13 @@
-## vela app status
+## vela status
 
 get status of an application
 
 ### Synopsis
 
-get status of an application, including workloads and traits of each components.
+get status of an application, including workloads and traits of each service.
 
 ```
-vela app status <APPLICATION-NAME> [flags]
+vela status <APPLICATION-NAME> [flags]
 ```
 
 ### Examples
@@ -19,7 +19,8 @@ vela status <APPLICATION-NAME>
 ### Options
 
 ```
-  -h, --help   help for status
+  -h, --help         help for status
+  -s, --svc string   service name
 ```
 
 ### Options inherited from parent commands
@@ -30,6 +31,6 @@ vela status <APPLICATION-NAME>
 
 ### SEE ALSO
 
-* [vela app](vela_app.md)	 - Manage applications
+* [vela](vela.md)	 - 
 
-###### Auto generated by spf13/cobra on 20-Oct-2020
+###### Auto generated by spf13/cobra on 6-Nov-2020

docs/cli/vela_svc.md

@@ -0,0 +1,27 @@
+## vela svc
+
+Manage services
+
+### Synopsis
+
+Manage services
+
+### Options
+
+```
+  -a, --app string   specify the name of application containing the services
+  -h, --help         help for svc
+```
+
+### Options inherited from parent commands
+
+```
+  -e, --env string   specify environment name for application
+```
+
+### SEE ALSO
+
+* [vela](vela.md)	 - 
+* [vela svc deploy](vela_svc_deploy.md)	 - Initialize and run a service
+
+###### Auto generated by spf13/cobra on 6-Nov-2020

docs/cli/vela_svc_deploy.md

@@ -0,0 +1,38 @@
+## vela svc deploy
+
+Initialize and run a service
+
+### Synopsis
+
+Initialize and run a service. The app name would be the same as service name, if it's not specified.
+
+```
+vela svc deploy [args]
+```
+
+### Examples
+
+```
+vela svc deploy -t <SERVICE_TYPE>
+```
+
+### Options
+
+```
+  -h, --help          help for deploy
+  -s, --staging       only save changes locally without real update application
+  -t, --type string   specify workload type of the service
+```
+
+### Options inherited from parent commands
+
+```
+  -a, --app string   specify the name of application containing the services
+  -e, --env string   specify environment name for application
+```
+
+### SEE ALSO
+
+* [vela svc](vela_svc.md)	 - Manage services
+
+###### Auto generated by spf13/cobra on 6-Nov-2020

docs/cli/vela_system.md

@@ -1,10 +1,10 @@
 ## vela system
 
-system management utilities
+System management utilities
 
 ### Synopsis
 
-system management utilities
+System management utilities
 
 ### Options
 
@@ -21,7 +21,7 @@ system management utilities
 ### SEE ALSO
 
 * [vela](vela.md)	 - 
-* [vela system info](vela_system_info.md)	 - show vela client and cluster chartPath
+* [vela system info](vela_system_info.md)	 - Show vela client and cluster chartPath
 * [vela system update](vela_system_update.md)	 - Sync definition from cluster
 
-###### Auto generated by spf13/cobra on 20-Oct-2020
+###### Auto generated by spf13/cobra on 6-Nov-2020

docs/cli/vela_system_info.md

@@ -1,10 +1,10 @@
 ## vela system info
 
-show vela client and cluster chartPath
+Show vela client and cluster chartPath
 
 ### Synopsis
 
-show vela client and cluster chartPath
+Show vela client and cluster chartPath
 
 ```
 vela system info [flags]
@@ -24,6 +24,6 @@ vela system info [flags]
 
 ### SEE ALSO
 
-* [vela system](vela_system.md)	 - system management utilities
+* [vela system](vela_system.md)	 - System management utilities
 
-###### Auto generated by spf13/cobra on 20-Oct-2020
+###### Auto generated by spf13/cobra on 6-Nov-2020

docs/cli/vela_system_update.md

@@ -30,6 +30,6 @@ vela system update
 
 ### SEE ALSO
 
-* [vela system](vela_system.md)	 - system management utilities
+* [vela system](vela_system.md)	 - System management utilities
 
-###### Auto generated by spf13/cobra on 20-Oct-2020
+###### Auto generated by spf13/cobra on 6-Nov-2020

docs/cli/vela_template.md

@@ -21,6 +21,6 @@ Manage templates
 ### SEE ALSO
 
 * [vela](vela.md)	 - 
-* [vela template context](vela_template_context.md)	 - show context parameters
+* [vela template context](vela_template_context.md)	 - Show context parameters
 
-###### Auto generated by spf13/cobra on 20-Oct-2020
+###### Auto generated by spf13/cobra on 6-Nov-2020

docs/cli/vela_template_context.md

@@ -1,10 +1,10 @@
 ## vela template context
 
-show context parameters
+Show context parameters
 
 ### Synopsis
 
-show context parameter
+Show context parameter
 
 ```
 vela template context
@@ -32,4 +32,4 @@ vela template context
 
 * [vela template](vela_template.md)	 - Manage templates
 
-###### Auto generated by spf13/cobra on 20-Oct-2020
+###### Auto generated by spf13/cobra on 6-Nov-2020

docs/cli/vela_traits.md

@@ -21,6 +21,7 @@ vela traits
 ```
       --apply-to string   Workload name
   -h, --help              help for traits
+  -s, --sync              Synchronize capabilities from cluster into local (default true)
 ```
 
 ### Options inherited from parent commands
@@ -33,4 +34,4 @@ vela traits
 
 * [vela](vela.md)	 - 
 
-###### Auto generated by spf13/cobra on 20-Oct-2020
+###### Auto generated by spf13/cobra on 6-Nov-2020

docs/cli/vela_up.md

@@ -4,7 +4,7 @@ Apply an appfile
 
 ### Synopsis
 
-Apply an appfile, by default vela.yml
+Apply an appfile, by default vela.yaml
 
 ```
 vela up
@@ -13,7 +13,8 @@ vela up
 ### Options
 
 ```
-  -h, --help   help for up
+  -f, -- string   specify file path for appfile
+  -h, --help      help for up
 ```
 
 ### Options inherited from parent commands
@@ -26,4 +27,4 @@ vela up
 
 * [vela](vela.md)	 - 
 
-###### Auto generated by spf13/cobra on 20-Oct-2020
+###### Auto generated by spf13/cobra on 6-Nov-2020

docs/cli/vela_version.md

@@ -26,4 +26,4 @@ vela version [flags]
 
 * [vela](vela.md)	 - 
 
-###### Auto generated by spf13/cobra on 20-Oct-2020
+###### Auto generated by spf13/cobra on 6-Nov-2020

docs/cli/vela_workloads.md

@@ -20,6 +20,7 @@ vela workloads
 
 ```
   -h, --help   help for workloads
+  -s, --sync   Synchronize capabilities from cluster into local (default true)
 ```
 
 ### Options inherited from parent commands
@@ -32,4 +33,4 @@ vela workloads
 
 * [vela](vela.md)	 - 
 
-###### Auto generated by spf13/cobra on 20-Oct-2020
+###### Auto generated by spf13/cobra on 6-Nov-2020

docs/concepts.md

@@ -0,0 +1,28 @@
+# Concepts and Glossaries
+
+This document explains some technical terms that are widely used in KubeVela, such as `application`, `service`, `workload type`, `trait` etc., from application developer's perspective. The goal is to clarify them in the context of KubeVela.
+
+## Overview
+
+![alt](../resources/concepts.png)
+
+## Workload Type & Trait
+The core KubeVela APIs are built based on Open Application Model (OAM). Hence, the `workload type` and `trait` concepts are borrowed from OAM.
+
+A [workload type](https://github.com/oam-dev/spec/blob/master/4.workload_definitions.md) declares the characteristics that runtime infrastructure should take into account in application management. A typical workload type could be a "long running service", or a "one-time off task" that can be instantiated as part of your application.
+
+A [trait](https://github.com/oam-dev/spec/blob/master/6.traits.md) represents an optional configuration that attaches to an instance of workload type. Traits augment a workload type instance with operational features such as load balancing policy, network ingress routing, circuit breaking, rate limiting, auto-scaling policies, upgrade strategies, and many more.
+
+## Capability
+A capability is a functionality provided by the runtime infrastructure (i.e. Kubernetes) that can support your application management requirements. Both `workload type` and `trait` are capabilities defined in KubeVela.
+
+## Service
+A service represents the runtime configurations (i.e., workload type and traits) needed to run your application in Kubernetes. Service is the descriptor of a basic deployable unit in KubeVela.
+
+## Application
+An application in KubeVela is a collection of services which describes what a developer tries to build and ship from high level. An example could be an "website" application which is composed of two services "frontend" and "backend", or a "wordpress" application which is composed of "php-server" and "database".
+
+An application is defined by an `Appfile` (named `vela.yaml` by default) in KubeVela.
+
+## Environment
+Before releasing an application to production, it's important to test the code in testing/staging workspaces. In KubeVela, we describe these workspaces as "deployment environments" or "environments" for short. Each environment has its own configuration (e.g., domain, Kubernetes namespace, configuration data, access control policy etc.) to allow user to create different deployment environments such as "test" and "production".

docs/design.md

@@ -6,7 +6,7 @@ This document is the detailed design and architecture of the KubeVela being buil
 
 ## Overview
 
-KubeVela is a simple, complete, but highly extensible cloud native application platform based on Kubernetes and Open Application Model (OAM). KubeVela intends to bring application-centric experience to its end users and democratize building cloud native application platforms for platform engineers.
+KubeVela is a simple, complete, but highly extensible cloud native application platform based on Kubernetes. KubeVela intends to bring application-centric experience to end users and democratize building cloud native application platforms for platform engineers.
 
 ## User Stories
 
@@ -18,31 +18,31 @@ As a end user (e.g. application developers, operators etc) of the platform, I on
 - Monitoring, debugging, rollout/rollback the application.
 - Dockerfile is fine, but please keep it simple. 
 
-As a platform engineer, I want to build a easy-to-use platform for my end users. In detail, the platform should be:
+As a platform engineer, I want to build a easy-to-use platform for end users. In detail, the platform should be:
 - Heroku-like (_in terms of both user experience and functionality_). 
   - and I prefer to build my own version with OSS tools, particularly, with Kubernetes (for obvious reason).
 - Easy to build. 
   - I am too busy to reinvent any wheel, I want to reuse every capability in Kubernetes community as possible,  with minimal effort. Writing some simple CRD and controllers is fine, but please, just the simple ones like copy-paste.
 - Powerful and highly extensible.
-  - I don't want to lock my users with restricted abstractions and capabilities like traditional PaaS or FaaS/Serverless. I love Kubernetes and what it has enabled. So in terms of capability, I hope my platform is fully open and has unlimited possibilities like Kubernetes itself, rather than another opinionated close system like traditional PaaS.
+  - I don't want to lock users with restricted abstractions and capabilities like traditional PaaS or FaaS/Serverless. I love Kubernetes and what it has enabled. So in terms of capability, I hope my platform is fully open and has unlimited possibilities like Kubernetes itself, rather than another opinionated close system like traditional PaaS.
 
 
 ## Core Principles
 
 In nutshell, the principles for KubeVela project are:
 
-- For end users, it out-of-the-box ships a fully featured PaaS-like experience, nothing special.
-- For platform builders, it works like a special Kubernetes "distro" or extensible PaaS core that could be used to build something more complex. It allows platform builders to ship any existing capabilities in cloud native ecosystem to end users with minimal effort, or develop a new capability at ease in a standardized and Kubernetes-native approach.
+- For end users, it out-of-the-box provides a fully featured PaaS-like experience, nothing special.
+- For platform builders, it works like a special Kubernetes "distro" or extensible PaaS core that could be used to build something more complex on top of. It allows platform builders to integrate any existing capabilities in Kubernetes ecosystem to end users with minimal effort, or develop a new capability at ease in a standardized and Kubernetes-native approach.
 
 ## Design Details
 
 ### 1. Application Centric
 
-The design of KubeVela intends to make users think in terms of application, not containers or infrastructure. 
+The API and interfaces of KubeVela intends to make users think in terms of application, not containers or infrastructure. 
 
 Lacking application context impacts the user experience and significantly raised the bar to adopt cloud native stack. We believe "application" is the natural mindset of developers and it's the core concept an application platform should expose.
 
-![alt](resources/app-centric.png)
+![alt](../resources/app-centric.png)
 
 KubeVela intends to let developers push code, define application in developer facing primitives, and make daily operations as configurations of the application.  
 
@@ -53,15 +53,15 @@ Thus, KubeVela choose to:
 #### Solution
 
 Instead of creating a in-house "application CRD", KubeVela adopts [Open Application Model (OAM)](https://github.com/oam-dev/spec) as its application definition, since OAM:
-1. Defines micro-services application by default.
-2. Can model operations as part of the application (i.e. `Trait`).
-2. Highly extensible: every workload and trait in OAM is a independent definition, no abstraction or capability lock-in.
+1. defines micro-services application by default.
+2. models day 2 operations as part of the application (i.e. `Application Traits`).
+2. is highly extensible: every workload and trait in OAM is a independent definition, no abstraction or capability lock-in.
 
 ### 2. Capability Oriented Architecture
 
-To enable platform builders use KubeVela as the extensible "PaaS core", KubeVela intends to make its every capability a standalone "plug-in".
+To enable platform builders use KubeVela to create their own application platforms in an easy and Kubernetes native approach, KubeVela intends to make its every capability a standalone "plug-in".
 
-![alt](resources/coa.png)
+![alt](../resources/coa.png)
 
 For example, there are several "built-in" workload types in KubeVela such as `Web Service` or `Task`. It is by design that they are all independent CRD controllers that abstract Kubernetes built-in workloads and create Service automatically if needed. KubeVela itself is **NOT** aware of the specification or implementation of these workload types.
 
@@ -73,7 +73,7 @@ This loosely coupled design of KubeVela adopts the idea of Capability Oriented A
 
 #### Solution
 
-We decide to build KubeVela core with [OAM Kubernetes runtime](https://github.com/crossplane/oam-kubernetes-runtime) which already implemented the building block features such as standalone workload type and trait controllers. Whether a given trait could work with certain workload types is also clarified as `appliesTo` field of trait definition. For platform builders, OAM Kubernetes Runtime also provided a [lightweight library](https://github.com/crossplane/oam-kubernetes-runtime/blob/2be3900a3817aed570de9ec353e6ab0b50e100f0/pkg/controller/v1alpha2/core/traits/manualscalertrait/manualscalertrait_controller.go#L42) to implement trait controller so it doesn't need to care about workload kinds.
+KubeVela core is built with [OAM Kubernetes Runtime](https://github.com/crossplane/oam-kubernetes-runtime) which met the requirements of KubeVela such as supporting bring in standalone controllers as workload type and trait, it also defined a clear interface between how a trait could operate a workload instance in a generic approach. Overall, this library defined a set of abstraction and interfaces for platform builder to assemble various Kubernetes capabilities into a PaaS without coupling them together or introducing any glue code.  
 
 ##### Capability Register and Discovery
 
@@ -94,17 +94,17 @@ For capabilities like cloud services, KubeVela intends to leverage Kubernetes as
 
 ### 3. Extensible User Interface
 
-KubeVela is built with Kubernetes and OAM also adopts Kubernetes API resource model. So in nutshell, **ALL** functionalities of KubeVela core are able to be consumed by simple `kubectl`, for example:
+KubeVela is built with Kubernetes and OAM (which adopts Kubernetes API model). So in nutshell, **ALL** functionalities of KubeVela core can be handled by simple `kubectl`, for example:
 
 ```yaml
 $ kubectl apply -f frontend-component.yaml # create frontend component
 $ kubectl apply -f backend-component.yaml # create backend component
-$ kubectl apply -f application-config.yaml # assign operational traits to components
+$ kubectl apply -f application-config.yaml # assign operational traits to components and deploy the whole application
 ```
 
-However, Kubernetes API should not be the end game. Declarative YAML objects are great to build platforms like KubeVela with but when directly exposed to end users, it creates heavy mental burden and high learning curve. For example, even with highest level abstraction, the default [containerized workload schema](https://github.com/oam-dev/spec/blob/master/core/workloads/schema/containerized_workload.md) of OAM still has dozens fields to learn with many rough edges to be aware.
+We call these server side objects "the application model of KubeVela", they are essentially the Kubernetes API objects KubeVela exposes.
 
-Thus KubeVela intends to introduce a lightweight user facing layer on top of its Kubernetes API objects with following goals in mind:
+However, we also agree that Kubernetes API model is great to build platforms like KubeVela with but when directly exposed to end users, it creates heavy mental burden and high learning curve. Hence, as any other user facing platforms, KubeVela intend to introduce a lightweight user facing layer with following goals in mind:
 
 - Shorten the learning curve of new developers. Most capabilities in KubeVela are developed by big
 companies that run very complex workloads. However, for the bigger developer community, the new user facing layer will provide a much simpler path to on-board KubeVela.
@@ -114,79 +114,46 @@ companies that run very complex workloads. However, for the bigger developer com
 
 #### Solution
 
-We concluded above requirements of the user interface layer as introducing a modeling language on top of the existing model objects. With this context, we decide to adopt [CUElang](https://github.com/cuelang/cue) as the modeling language of KubeVela. In detail, every workload or trait definition will inline a cue template as the contract between user and Kubernetes API object.
+We concluded such "highly extensible user interface layer" as a need for a dynamic "modeling language" on top of the KubeVela's application model objects. After evaluation, we decided to adopt [CUElang](https://github.com/cuelang/cue) since it's perfect as a pure data configuration language that allow us to build developer facing tools, nothing more, nothing less.
 
-However, we don't assume users need to learn or write CUElang directly. Instead, the reason we choose CUElang is it's just perfect to help us create developer facing tools based on it. Thus, KubeVela introduced three most common tools based to CUElang for developers to use:
+In detail, we integrated CUE based abstraction as part of OAM implementation since the *abstraction* and *model* are closely related. For platform builders, every workload or trait definition in KubeVela references a CUE template as its abstraction between human and the underlying Kubernetes capability, platform builders are free to modify those templates at any time
+
+On the other hand, it's by intention that the end users of KubeVela don't need to learn or write CUE. Instead, we created following tools for them by leveraging above OAM + CUE user interface layer:
 
 1. A command line tool.
 2. A GUI dashboard.
 3. A Docker Compose style `appfile`.
 
-An example for `vela cli`:
+For example, the `vela cli`:
 
 ```console
-$ vela comp deploy frontend -t webservice --image oamdev/testapp:v1 --port 80 --app helloworld
+$ vela svc deploy frontend -t webservice --image oamdev/testapp:v1 --port 80 --app helloworld
 ```
 
 The `-t webservice --image oamdev/testapp:v1 --port 80` arguments are not hard coded, they are schema defined by in-line CUE template of `WebService` workload definition.
 
-The `appfile` is essentially a YAML version of command line tool so we can support more complex and serious scenarios by simply running `$ vela up hello-world.yaml`:
+The `appfile` is essentially a YAML version of command line tool but it can support more complex structures with a single command like `$ vela up`:
 
-```yaml
-version: "1.0-alpha.1"
+![alt](../resources/appfile.png)
 
-name: helloworld
+The schema of above `appfile` is not hard coded as well, they are organized following OAM and enforced by CUE templates of `WebService` workload definition, `Scaling` trait definition and `Canary` trait definition.
 
-services:
-  express-server:
-    type: webservice # workload type
-    build:
-      docker:
-        file: Dockerfile
-        context: .
-
-    image: oamdev/testapp:v1
-    cmd: ["node", "server.js"]
-    ports:
-      - 8080:80
-    env:
-      - FOO=bar
-
-    scale: # scaling trait
-      replica: 2
-      auto:
-        range: "1-10"
-        cpu: 80
-        qps: 1000
-
-    canary: # canary trait
-      step: 5
-      headers:
-        - "foo:bar.*"
-
-  redis:
-    image: oamdev/redis
-
-secrets:
-  my-secret: /local-path/my-secret # load local file into k8s secret
-```
-
-The schema of above `appfile` is not hard coded, they are defined by in-line CUE templates of `WebService` workload definition, `Scaling` trait definition and `Canary` trait definition.
+> Appfile has its [independent design doc](./design/appfile-design.md) which includes more details. There's also [an example](./design/appfile-design.md#multiple-outputs-in-traitdefinition) showing how platform builder could use CUE to define a `route` capability in KubeVela.
 
 We will skip the example of dashboard, but similarly, the schema of GUI forms are defined by in-lined CUE template of definition objects.
 
 ## Architecture
 
-![alt](resources/arch.png)
+![alt](../resources/arch.png)
 
 From highest level, KubeVela is composed by only two components:
 
 ### 1. User interface layer
-Including: `cli`, `dashboard`, `appfile`, they are all client side tools to provide developer facing abstractions by leveraging CUElang based parametering and templating.
+Including: `cli`, `dashboard`, `appfile`, they are all client side tools based on the CUE based abstractions mentioned above.
 ### 2. KubeVela core
 Including:
-  - [OAM Kubernetes runtime](https://github.com/crossplane/oam-kubernetes-runtime) to provide application level building blocks such as `Component` and `Application` etc.
-  - [Built-in workload and trait controllers](https://github.com/oam-dev/kubevela/tree/master/pkg/controller/v1alpha1) to implement core capabilities such as `webservice`, `route` and `rollout` etc.
+  - [OAM Kubernetes runtime](https://github.com/crossplane/oam-kubernetes-runtime) to provide application-centric building blocks such as `Component` and `Application` etc.
+  - [Built-in workload and trait controllers](https://github.com/oam-dev/kubevela/tree/master/pkg/controller/v1alpha1) to provide core capabilities such as `webservice`, `route` and `rollout` etc.
   - Capability Management: manage features of KubeVela following Capability Oriented Architecture. 
     - Every feature of KubeVela is a "addon", and it is registered by Kubernetes API resource (including CRD) leveraging OAM definition objects.
     - CRD Registry: register controllers of Kubernetes add-ons and discover them by CRD. This will enable automatically install controllers/operators when CRD is missing in the cluster.

docs/design/appfile-design.md

@@ -86,8 +86,7 @@ spec:
     name: deployments.apps
   extension:
     template: |
-      parameter: #webservice
-      #webservice: {
+      parameter: {
         // +vela:cli:enabled=true
         // +vela:cli:usage=specify commands to run in container
         // +vela:cli:short=c
@@ -152,7 +151,7 @@ kind: WorkloadDefinition | TraitDefinition
 spec:
   extension:
     template: |
-      parameter: #webservice
+      parameter: {
       ...
 ```
 
@@ -167,8 +166,7 @@ Vela allows platform builders to write bespoke templates to extend Appfile confi
 A template starts with `parameter` and its definition:
 
 ```yaml
-parameter: #webservice
-#webservice: {
+parameter: {
   // +vela:cli:enabled=true
   // +vela:cli:usage=specify commands to run in container
   // +vela:cli:short=c
@@ -178,7 +176,6 @@ parameter: #webservice
 
 Here is the takeout:
 * The `parameter` defines the user input fields and is used to render final output with user input values. These fields will be exposed to users in Appfile.
-* The definition `#webservice` is used to tell the name of the template. This name is used to correlate workload and trait types to fields in Appfile.
 
 Note that there is difference in how Workload and Trait expose parameters.
 
@@ -278,7 +275,7 @@ Here is the takeout:
 
 ### `vela up`
 
-The vela-cli will have an `up` command to provide seamless workflow experience. Provide an `vela.yml` Appfile in the same directory that you will run `vela up` and it is good to go. There is an example under `examples/testapp/` .
+The vela-cli will have an `up` command to provide seamless workflow experience. Provide an `vela.yaml` Appfile in the same directory that you will run `vela up` and it is good to go. There is an example under `examples/testapp/` .
 
 ## Examples
 

docs/design/route.md

@@ -96,7 +96,7 @@ you to give a specified ingress controller type. Currently, only nginx-ingress i
 
 The `tls` field allow you to specify a TLS for this route with an IssuerName, the IssuerName pointing to an Issuer Object
 created by cert-manager. Cert-manager and ingress controller will handle certificate creation and binding.
-If not specified, a selfsigned issuer will be created.
+If not specified, mTLS was disabled and you can only visit by http.
 
 If no rule specified, route trait will create one rule automatically and match with the port.
 

docs/developers/app-init.md

@@ -0,0 +1,94 @@
+# Initializating Application
+
+## `vela init`
+
+To initialize and deploy an application with one service, run:
+
+> If you only want to initialize without deploying the app, add `--render-only` flag
+
+```console
+$ vela  init
+Welcome to use KubeVela CLI! We're going to help you run applications through a couple of questions.
+
+Environment: default, namespace: default
+
+? What is the domain of your application service (optional):  example.com
+? What is your email (optional, used to generate certification):
+? What would you like to name your application (required):  testapp
+? Choose the workload type for your application (required, e.g., webservice):  webservice
+? What would you like to name this webservice (required):  testsvc
+? specify app image crccheck/hello-world
+? specify port for container 8000
+
+...
+✅ Application Deployed Successfully!
+  - Name: testsvc
+    Type: webservice
+    HEALTHY Ready: 1/1
+    Routes:
+
+    Last Deployment:
+      Created at: ...
+      Updated at: ...
+```
+
+Check the application:
+
+```console
+$ vela show testapp
+About:
+
+  Name:      	testapp
+  Created at:	...
+  Updated at:	...
+
+
+Environment:
+
+  Namespace:	default
+
+Services:
+
+  - Name:        	testsvc
+    WorkloadType:	webservice
+    Arguments:
+      image:        	crccheck/hello-world
+      port:         	8000
+      Traits:
+```
+
+## Deploy Multiple Services
+
+You can also use KubeVela CLI to deploy multiple services for an application.
+
+Check the available workload types.
+
+```console
+$ vela workloads
+NAME      	DESCRIPTION
+worker   	Backend worker without ports exposed
+webservice	Long running service with network routes
+```
+
+Deploy the first service named `frontend` with `Web Service` type:
+
+```console
+$ vela svc deploy frontend --app testapp -t webservice --image crccheck/hello-world
+App testapp deployed
+```
+
+> TODO auto generate a random application name, so --app testapp becomes optional
+
+Deploy the second service named `backend` with "Backend Worker" type:
+
+```console
+$ vela svc deploy backend --app testapp2 -t worker --image crccheck/hello-world
+App testapp2 deployed
+```
+
+```console
+$ vela ls
+SERVICE 	APP     	TYPE	TRAITS	STATUS 	CREATED-TIME
+frontend	testapp 	    	      	...
+backend 	testapp 	    	      	...
+```

docs/developers/cap-center.md

@@ -0,0 +1,71 @@
+# Managing Capabilities
+
+This tutorial talks about how to install capabilities (caps) from remote centers.
+
+## Add Cap Center
+
+Add and sync a remote center:
+
+```console
+$ vela cap center config my-center https://github.com/oam-dev/catalog/tree/master/registry
+successfully sync 1/1 from my-center remote center
+Successfully configured capability center my-center and sync from remote
+
+$ vela cap center sync my-center
+successfully sync 1/1 from my-center remote center
+sync finished
+```
+
+## List Cap Centers
+
+```console
+$ vela cap center ls
+NAME     	ADDRESS
+my-center	https://github.com/oam-dev/catalog/tree/master/registry
+```
+
+## [Optional] Remove Cap Center
+
+```console
+$ vela cap center remove my-center
+```
+
+## List Caps
+
+```console
+$ vela cap ls my-center
+NAME     	CENTER   	TYPE 	DEFINITION                  	STATUS     	APPLIES-TO
+kubewatch	my-center	trait	kubewatches.labs.bitnami.com	uninstalled	[]
+```
+
+## Install Cap
+
+```console
+$ vela cap install my-center/kubewatch
+Installing trait capability kubewatch
+"my-repo" has been added to your repositories
+2020/11/06 16:19:30 [debug] creating 1 resource(s)
+2020/11/06 16:19:30 [debug] CRD kubewatches.labs.bitnami.com is already present. Skipping.
+2020/11/06 16:19:37 [debug] creating 3 resource(s)
+Successfully installed chart (kubewatch) with release name (kubewatch)
+Successfully installed capability kubewatch from my-center
+```
+
+Check traits installed:
+```console
+$ vela traits
+Synchronizing capabilities from cluster⌛ ...
+Sync capabilities successfully ✅ (no changes)
+TYPE      	CATEGORY	DESCRIPTION
+kubewatch 	trait   	Add a watch for resource
+...
+```
+
+## Uninstall Cap
+
+> Note: make sure no apps are using the capability before uninstalling.
+
+```console
+$ vela cap uninstall my-center/kubewatch
+Successfully removed chart (kubewatch) with release name (kubewatch)
+```

docs/developers/check-logs.md

@@ -0,0 +1,7 @@
+# Check Logs of Container
+
+```console
+$ vela logs testapp
+```
+
+It will let you select the container to get logs from. If there is only one container it will select automatically.

docs/developers/cloud-service.md

@@ -0,0 +1,68 @@
+# Cloud service
+
+In this demo, we will add an RDS database from Alibaba Cloud to our application.
+
+## What is cloud service
+
+Cloud service refers to the managed cloud resources. For example, you can buy a PostgreSql database from a cloud vendor instead of setting up your own. Cloud service are normally outside of your Kubernetes cluster, but logically they are still part of your application. KubeVela provides application centric view of your applications. It will treat every service the same.
+
+## Crossplane
+
+Crossplane is an open source Kubernetes add-on that extends any cluster with the ability to provision and manage cloud infrastructure, services, and applications using kubectl, GitOps, or any tool that works with the Kubernetes API. The benefit of using Crossplane is it will provide centralized control plane disregard where your cluster is.
+
+KubeVela will delegate the lifecycle management of cloud service to Crossplane.
+
+## Install Crossplane (This demo uses crossplane version 0.13)
+
+You will need a Kubernetes cluster ver> 1.16 (Minikube and Kind clusters are fine).   
+Also you will need to have KubeVela installed on the cluster.   
+The folder that containes all the demo scripts are under `../../examples/kubecondemo/`. For your convience, cd to that folder first:  
+`cd ../../examples/kubecondemo/`   
+To provision a cloud resource, you need to have the Access Key and Secret to your Alibaba cloud account.
+
+* Create crossplane namespace: `kubectl create ns crossplane-system`
+* Install crossplane helm chart: `helm install crossplane  charts/crossplane/ --namespace crossplane-system`
+* Install crossplane cli: `curl -sL https://raw.githubusercontent.com/crossplane/crossplane/release-0.13/install.sh | sh`
+* Add crossplane to `PATH`:  `sudo mv kubectl-crossplane /usr/local/bin`
+* Configure cloud provider(Alibaba Cloud) 
+  * Add cloud provider: `kubectl crossplane install provider crossplane/provider-alibaba:v0.3.0`
+  * Create provider secret: `kubectl create secret generic alibaba-creds --from-literal=accessKeyId=<change here> --from-literal=accessKeySecret=<change here> -n crossplane-system`
+  * Configure the provider: `kubectl apply -f script/provider.yaml`
+* Configure infrastructure: `kubectl crossplane install configuration crossplane/getting-started-with-alibaba:v0.13`
+
+So far we have configured Crossplane on the cluster.
+
+## Import the database workload definition
+
+First, register the db workload definition:   
+`kubectl apply -f script/def_db.yaml`   
+The webservice workload is different from the default version so we have to overwrite it.   
+`kubectl apply -f cript/webservice.yaml`   
+Don't forget to update vela:   
+`vela system update`   
+
+## Apply the appfile
+
+In the Appfile, we claim an RDS instance just like other services:
+
+``` yaml
+database:
+    type: rds
+    name: alibabaRds
+    ...
+```
+
+Next, we start the application:   
+`vela up`
+
+## Verify the database status
+
+Under the hood, we can verify the status of database(usually takes >6 min to be ready):   
+`kubectl get postgresqlinstance`
+
+When the database is ready, you can see the `READY: True` output.
+
+## Access the web-ui
+
+In the Appfile we added a route trait. To access the web-ui, please check out the [route](set-route.md) documentation.
+

docs/developers/config-app.md

@@ -0,0 +1,83 @@
+# Configuring Data/Env in Application
+
+`vela` provides a `config` command to manage config data.
+
+## `vela config set`
+
+```console
+$ vela config set test a=b c=d
+reading existing config data and merging with user input
+config data saved successfully ✅
+```
+
+## `vela config get`
+
+```console
+$ vela config get test
+Data:
+  a: b
+  c: d
+```
+
+## `vela config del`
+
+```console
+$ vela config del test
+config (test) deleted successfully
+```
+
+## `vela config ls`
+
+```console
+$ vela config set test a=b
+$ vela config set test2 c=d
+$ vela config ls
+NAME
+test
+test2
+```
+
+## Configure env in application
+
+The config data can be set as the env in applications.
+
+```console
+$ vela config set demo DEMO_HELLO=helloworld
+```
+
+Save the following to `vela.yaml` in current directory:
+
+```yaml
+name: testapp
+services:
+  env-config-demo:
+    image: heroku/nodejs-hello-world
+    config: demo
+```
+
+Then run:
+```console
+$ vela up
+Parsing vela.yaml ...
+Loading templates ...
+
+Rendering configs for service (env-config-demo)...
+Writing deploy config to (.vela/deploy.yaml)
+
+Applying deploy configs ...
+Checking if app has been deployed...
+App has not been deployed, creating a new deployment...
+✅ App has been deployed 🚀🚀🚀
+    Port forward: vela port-forward testapp
+             SSH: vela exec testapp
+         Logging: vela logs testapp
+      App status: vela status testapp
+  Service status: vela status testapp --svc env-config-demo
+```
+
+Check env var:
+
+```
+$ vela exec testapp -- printenv | grep DEMO_HELLO
+DEMO_HELLO=helloworld
+```

docs/developers/config-enviroments.md

@@ -0,0 +1,70 @@
+# Setting Up Deployment Environment
+
+Before working with your application, you need to prepare a deployment environment (e.g. test, staging, prod etc) which will configure the workspace, email for certificate issuer and domain for your application.
+
+## Create environment
+
+```console
+$ vela env init demo --email my@email.com
+environment demo created, Namespace: default, Email: my@email.com
+```
+
+## Check the deployment environment metadata
+
+```console
+$ vela env ls
+NAME   	CURRENT	NAMESPACE	EMAIL                	DOMAIN
+default	       	default  	
+demo   	*      	default  	my@email.com
+```
+
+By default, the environment will use `default` namespace in K8s.
+
+## Configure changes 
+
+You could change the config by executing the environment again.
+
+```console
+$ vela env init demo --namespace demo
+environment demo created, Namespace: demo, Email: my@email.com
+```
+
+```console
+$ vela env ls
+NAME   	CURRENT	NAMESPACE	EMAIL                	DOMAIN
+default	       	default  	
+demo   	*      	demo     	my@email.com
+```
+
+**Note that the created apps won't be affected, only newly created apps will use the updated info.**
+
+## [Optional] Configure Domain if you have public IP
+
+If your K8s cluster is provisioned by cloud provider and has public IP for ingress.
+You could configure your domain in the environment, then you'll be able to visit
+your app by this domain with an mTLS supported automatically.
+
+For example, you could get the public IP from ingress service.  
+
+```console
+$ kubectl get svc -A | grep LoadBalancer
+NAME                         TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)                      AGE
+nginx-ingress-lb             LoadBalancer   172.21.2.174    123.57.10.233   80:32740/TCP,443:32086/TCP   41d
+```
+
+The fourth column is public IP. Configure 'A' record for your custom domain.
+
+```
+*.your.domain => 123.57.10.233
+``` 
+
+You could also use `123.57.10.233.xip.io` as your domain, if you don't have a custom one.
+`xip.io` will automatically route to the prefix IP `123.57.10.233`.
+
+
+```console
+$ vela env init demo --domain 123.57.10.233.xip.io
+environment demo updated, Namespace: demo, Email: my@email.com
+```
+
+

docs/developers/devex/appfile.md

@@ -0,0 +1,242 @@
+# Using Appfile for More Flexible Configuration
+
+Appfile supports more flexible options than CLI/UI to configure appliation deployment on Vela.
+A detailed design doc could be found [here](../../design/appfile-design.md).
+
+In this tutorial, we will build and deploy an example NodeJS app under [examples/testapp/](https://github.com/oam-dev/kubevela/tree/master/examples/testapp).
+
+## Prerequisites
+
+- [docker](https://docs.docker.com/get-docker/) installed on the host
+- [vela](../../install.md) installed and configured
+
+## 1. Download test app code
+
+git clone and go to the testapp directory:
+
+```console
+$ git clone https://github.com/oam-dev/kubevela.git
+$ cd kubevela/examples/testapp
+```
+
+The example contains NodeJS app code, Dockerfile to build the app.
+
+## 2. Deploy app in one command
+
+In the directory there is a [vela.yaml](../../../examples/testapp/vela.yaml) which follows Appfile format supported by Vela.
+We are going to use it to build and deploy the app.
+
+ATTENTION: change the image field in vela.yaml to something you can push to on your host:
+
+> Or you may try the local testing option introduced in the following section.
+
+```yaml
+    image: oamdev/testapp:v1
+```
+
+Run the following command:
+
+```console
+$ vela up
+Parsing vela.yaml ...
+Loading templates ...
+
+Building service (express-server)...
+Sending build context to Docker daemon  71.68kB
+Step 1/10 : FROM mhart/alpine-node:12
+ ---> 9d88359808c3
+...
+
+pushing image (oamdev/testapp:v1)...
+...
+
+Rendering configs for service (express-server)...
+Writing deploy config to (.vela/deploy.yaml)
+
+Applying deploy configs ...
+Checking if app has been deployed...
+App has not been deployed, creating a new deployment...
+✅ App has been deployed 🚀🚀🚀
+    Port forward: vela port-forward testapp
+             SSH: vela exec testapp
+         Logging: vela logs testapp
+      App status: vela status testapp
+  Service status: vela status testapp --svc express-server
+```
+
+
+Check the status of the service:
+
+```console
+$ vela status testapp
+  About:
+  
+    Name:      	testapp
+    Namespace: 	default
+    Created at:	2020-11-02 11:08:32.138484 +0800 CST
+    Updated at:	2020-11-02 11:08:32.138485 +0800 CST
+  
+  Services:
+  
+    - Name: express-server
+      Type: webservice
+      HEALTHY Ready: 1/1
+      Last Deployment:
+        Created at: 2020-11-02 11:08:33 +0800 CST
+        Updated at: 2020-11-02T11:08:32+08:00
+      Routes:
+
+```
+
+### Alternative: Local testing without pushing image remotely
+
+If you have local [kind](../../install.md#kind) cluster running, you may try the local push option without pushing image remotely.
+
+Add local option to `build`:
+
+```yaml
+    build:
+      # push image into local kind cluster without remote transfer
+      push:
+        local: kind
+
+      docker:
+        file: Dockerfile
+        context: .
+```
+
+Then deploy the app to kind:
+
+```console
+$ vela up
+```
+
+### [Optional] Check rendered manifests
+
+By default, Vela renders the final manifests in `.vela/deploy.yaml`:
+
+```yaml
+apiVersion: core.oam.dev/v1alpha2
+kind: ApplicationConfiguration
+metadata:
+  name: testapp
+  namespace: default
+spec:
+  components:
+  - componentName: express-server
+---
+apiVersion: core.oam.dev/v1alpha2
+kind: Component
+metadata:
+  name: express-server
+  namespace: default
+spec:
+  workload:
+    apiVersion: apps/v1
+    kind: Deployment
+    metadata:
+      name: express-server
+    ...
+---
+apiVersion: core.oam.dev/v1alpha2
+kind: HealthScope
+metadata:
+  name: testapp-default-health
+  namespace: default
+spec:
+  ...
+```
+
+## 3. Add routing
+
+Add routing config under `express-server`:
+
+```yaml
+servcies:
+  express-server:
+    ...
+
+    route:
+      domain: example.com
+      rules:
+        - path: /testapp
+          rewriteTarget: /
+```
+
+Apply again:
+
+```console
+$ vela up
+```
+
+Check the status until we see route trait ready:
+```console
+$ vela status testapp
+About:
+
+  Name:      	testapp
+  Namespace: 	default
+  Created at:	...
+  Updated at:	...
+
+Services:
+
+  - Name: express-server
+    Type: webservice
+    HEALTHY Ready: 1/1
+    Last Deployment:
+      Created at: ...
+      Updated at: ...
+    Routes:
+      - route: 	Visiting URL: http://example.com	IP: localhost
+```
+
+**In [kind cluster setup](../../install.md#kind)**, you can visit the service via localhost:
+
+> If not in kind cluster, replace localhost with ingress address
+
+```
+$ curl -H "Host:example.com" http://localhost/testapp
+Hello World
+```
+
+## 4. Add monitoring metrics
+
+TODO
+
+## [Optional] Configure "task" workload type
+
+By now we have deployed a *webservice* workload. We can also add a *task* workload in appfile:
+
+> Below is a simplified [k8s job example](https://kubernetes.io/docs/concepts/workloads/controllers/job/#running-an-example-job) using Vela:
+
+```yaml
+services:
+  pi:
+    image: perl 
+    cmd: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
+
+  express-server:
+    ...
+```
+
+Then deploy appfile again:
+
+```console
+$ vela up
+```
+
+## What's Next?
+
+Congratulations! You have just deployed an app using Vela.
+
+Here are some next steps that you can have more play with your app:
+
+- [Check Application Logs](../check-logs.md)
+- [Execute Commands in Container](../exec-cmd.md)
+- [Port Forward to Container](../port-forward.md)
+
+
+## References
+
+For more configuration options of built-in capabilities, check [references](../references/README.md)

docs/developers/devex/cli.md

@@ -0,0 +1,28 @@
+# KubeVela CLI
+
+Learn about general configurations for `vela` command line tool. For the usage of the CLI, please check the KubeVela's [user documentation](../../README.md) instead.
+
+### Auto-completion
+
+#### bash
+
+```console
+To load completions in your current shell session:
+$ source <(vela completion bash)
+
+To load completions for every new session, execute once:
+Linux:
+  $ vela completion bash > /etc/bash_completion.d/vela
+MacOS:
+  $ vela completion bash > /usr/local/etc/bash_completion.d/vela
+```
+
+#### zsh
+
+```console
+To load completions in your current shell session:
+$ source <(vela completion zsh)
+
+To load completions for every new session, execute once:
+$ vela completion zsh > "${fpath[1]}/_vela"
+```