app controller: reconcile workflow and create res configmap (#1788)

Co-authored-by: kinsolee <lijingzhao@forchange.tech>

.github/workflows/e2e-test.yml

@@ -0,0 +1,109 @@
+name: E2E Test
+
+on:
+  push:
+    branches:
+      - master
+      - release-*
+  workflow_dispatch: {}
+  pull_request:
+    branches:
+      - master
+      - release-*
+
+env:
+  # Common versions
+  GO_VERSION: '1.16'
+  GOLANGCI_VERSION: 'v1.38'
+  KIND_VERSION: 'v0.7.0'
+
+jobs:
+
+  detect-noop:
+    runs-on: ubuntu-20.04
+    outputs:
+      noop: ${{ steps.noop.outputs.should_skip }}
+    steps:
+      - name: Detect No-op Changes
+        id: noop
+        uses: fkirc/skip-duplicate-actions@v3.3.0
+        with:
+          github_token: ${{ secrets.GITHUB_TOKEN }}
+          paths_ignore: '["**.md", "**.mdx", "**.png", "**.jpg"]'
+          do_not_skip: '["workflow_dispatch", "schedule", "push"]'
+          concurrent_skipping: false
+
+  e2e-tests:
+    runs-on: aliyun
+    needs: detect-noop
+    if: needs.detect-noop.outputs.noop != 'true'
+
+    steps:
+      - name: Check out code into the Go module directory
+        uses: actions/checkout@v2
+
+      - name: Setup Go
+        uses: actions/setup-go@v2
+        with:
+          go-version: ${{ env.GO_VERSION }}
+
+      - name: Get dependencies
+        run: |
+          go get -v -t -d ./...
+
+      - name: Setup Kind
+        uses: engineerd/setup-kind@v0.5.0
+        with:
+          version: ${{ env.KIND_VERSION }}
+          skipClusterCreation: true
+
+      - name: Setup Kind Cluster
+        run: |
+          kind delete cluster
+          kind create cluster --image kindest/node:v1.18.15@sha256:5c1b980c4d0e0e8e7eb9f36f7df525d079a96169c8a8f20d8bd108c0d0889cc4
+          kubectl version
+          kubectl cluster-info
+
+      - name: Load Image to kind cluster
+        run: make kind-load
+
+      - name: Run Make
+        run: make
+
+      - name: Run Make Manager
+        run: make manager
+
+      - name: Prepare for e2e tests
+        run: |
+          make e2e-cleanup
+          make e2e-setup
+          helm lint ./charts/vela-core
+          helm test -n vela-system kubevela --timeout 5m
+
+      - name: Wait for e2e preparation ready
+        run: |
+          timeout 60 bash -c 'while [[ "$(curl -s -o /dev/null -w ''%{http_code}'' localhost:38081/api/components)" != "200" ]]; do sleep 5; done' || false
+
+      - name: Run api e2e tests
+        run: make e2e-api-test
+
+      - name: Run e2e tests
+        run: make e2e-test
+
+      - name: Stop kubevela, get profile
+        run: make end-e2e
+
+      - name: Upload coverage report
+        uses: codecov/codecov-action@v1
+        with:
+          token: ${{ secrets.CODECOV_TOKEN }}
+          file: /tmp/e2e-profile.out
+          flags: e2etests
+          name: codecov-umbrella
+
+      - name: Clean e2e profile
+        run: rm /tmp/e2e-profile.out
+
+      - name: Cleanup image
+        if: ${{ always() }}
+        run: make image-cleanup

.github/workflows/go.yml

@@ -13,7 +13,7 @@ on:
 
 env:
   # Common versions
-  GO_VERSION: '1.14'
+  GO_VERSION: '1.16'
   GOLANGCI_VERSION: 'v1.38'
   KIND_VERSION: 'v0.7.0'
 
@@ -33,60 +33,13 @@ jobs:
           do_not_skip: '["workflow_dispatch", "schedule", "push"]'
           concurrent_skipping: false
 
-  unit-tests:
-    runs-on: ubuntu-20.04
-    needs: detect-noop
-    if: needs.detect-noop.outputs.noop != 'true'
-
-    steps:
-      - name: Set up Go 1.14
-        uses: actions/setup-go@v1
-        with:
-          go-version: ${{ env.GO_VERSION }}
-        id: go
-
-      - name: Check out code into the Go module directory
-        uses: actions/checkout@v2
-        with:
-          submodules: true
-
-      - name: Cache Go Dependencies
-        uses: actions/cache@v2
-        with:
-          path: .work/pkg
-          key: ${{ runner.os }}-pkg-${{ hashFiles('**/go.sum') }}
-          restore-keys: ${{ runner.os }}-pkg-
-
-      - name: Install ginkgo
-        run:  |
-          sudo apt-get install -y golang-ginkgo-dev
-
-      - name: Setup Kind Cluster
-        uses: engineerd/setup-kind@v0.5.0
-        with:
-          version: ${{ env.KIND_VERSION }}
-
-      - name: install Kubebuilder
-        uses: wonderflow/kubebuilder-action@v1.1
-
-      - name: Run Make test
-        run: make test
-
-      - name: Upload coverage report
-        uses: codecov/codecov-action@v1
-        with:
-          token: ${{ secrets.CODECOV_TOKEN }}
-          file: ./coverage.txt
-          flags: unittests
-          name: codecov-umbrella
-
   compatibility-test:
     runs-on: ubuntu-20.04
     needs: detect-noop
     if: needs.detect-noop.outputs.noop != 'true'
 
     steps:
-      - name: Set up Go 1.14
+      - name: Set up Go
         uses: actions/setup-go@v1
         with:
           go-version: ${{ env.GO_VERSION }}
@@ -122,81 +75,6 @@ jobs:
       - name: Clean up testdata
         run: make compatibility-testdata-cleanup
 
-  e2e-tests:
-    runs-on: aliyun
-    needs: detect-noop
-    if: needs.detect-noop.outputs.noop != 'true'
-
-    steps:
-      - name: Check out code into the Go module directory
-        uses: actions/checkout@v2
-
-      - name: Setup Go
-        uses: actions/setup-go@v2
-        with:
-          go-version: ${{ env.GO_VERSION }}
-
-      - name: Get dependencies
-        run: |
-          go get -v -t -d ./...
-
-      - name: Setup Kind
-        uses: engineerd/setup-kind@v0.5.0
-        with:
-          version: ${{ env.KIND_VERSION }}
-          skipClusterCreation: true
-
-      - name: Setup Kind Cluster
-        run: |
-          kind delete cluster
-          kind create cluster --image kindest/node:v1.18.15@sha256:5c1b980c4d0e0e8e7eb9f36f7df525d079a96169c8a8f20d8bd108c0d0889cc4
-          kubectl version
-          kubectl cluster-info
-
-      - name: Load Image to kind cluster
-        run: make kind-load
-
-      - name: Run Make
-        run: make
-
-      - name: Run Make Manager
-        run: make manager
-
-      - name: Prepare for e2e tests
-        run: |
-          make e2e-cleanup
-          make e2e-setup
-          helm lint ./charts/vela-core
-          helm test -n vela-system kubevela --timeout 5m
-
-      - name: Wait for e2e preparation ready
-        run: |
-          timeout 60 bash -c 'while [[ "$(curl -s -o /dev/null -w ''%{http_code}'' localhost:38081/api/components)" != "200" ]]; do sleep 5; done' || false
-
-      - name: Run api e2e tests
-        run: make e2e-api-test
-
-      - name: Run e2e tests
-        run: make e2e-test
-
-      - name: Stop kubevela, get profile
-        run: make end-e2e
-
-      - name: Upload coverage report
-        uses: codecov/codecov-action@v1
-        with:
-          token: ${{ secrets.CODECOV_TOKEN }}
-          file: /tmp/e2e-profile.out
-          flags: e2etests
-          name: codecov-umbrella
-
-      - name: Clean e2e profile
-        run: rm /tmp/e2e-profile.out
-
-      - name: Cleanup image
-        if: ${{ always() }}
-        run: make image-cleanup
-
   staticcheck:
     runs-on: ubuntu-20.04
     needs: detect-noop
@@ -222,7 +100,7 @@ jobs:
 
       - name: Install StaticCheck
         run: GO111MODULE=off go get honnef.co/go/tools/cmd/staticcheck
-      
+
       - name: Static Check
         run: staticcheck ./...
 
@@ -291,10 +169,10 @@ jobs:
     if: needs.detect-noop.outputs.noop != 'true'
 
     steps:
-      - name: Set up Go 1.14
-        uses: actions/setup-go@v1
+      - name: Set up Go 1.16
+        uses: actions/setup-go@v2
         with:
-          go-version: 1.14
+          go-version: ${{ env.GO_VERSION }}
         id: go
       - name: Check out code into the Go module directory
         uses: actions/checkout@v2
@@ -302,3 +180,5 @@ jobs:
         run: make cross-build
       - name: Run compress binary
         run: make compress
+      - name: Run make reviewable
+        run: make reviewable

.github/workflows/registry.yml

@@ -128,3 +128,22 @@ jobs:
           helm repo index --url https://$BUCKET.$ENDPOINT/core $LOCAL_OSS_DIRECTORY
       - name: sync local to cloud
         run: ./ossutil --config-file .ossutilconfig sync $LOCAL_OSS_DIRECTORY oss://$BUCKET/core -f
+
+  publish-capabilities:
+    env:
+      CAPABILITY_BUCKET: kubevela-registry
+      CAPABILITY_DIR: capabilities
+      CAPABILITY_ENDPOINT: oss-cn-beijing.aliyuncs.com
+    runs-on: ubuntu-20.04
+    steps:
+      - uses: actions/checkout@master
+      - name: Install ossutil
+        run: wget http://gosspublic.alicdn.com/ossutil/1.7.0/ossutil64 && chmod +x ossutil64 && mv ossutil64 ossutil
+      - name: Configure Alibaba Cloud OSSUTIL
+        run: ./ossutil --config-file .ossutilconfig config -i ${ACCESS_KEY} -k ${ACCESS_KEY_SECRET} -e ${CAPABILITY_ENDPOINT} -c .ossutilconfig
+      - name: sync capabilities bucket to local
+        run: ./ossutil --config-file .ossutilconfig sync oss://$CAPABILITY_BUCKET $CAPABILITY_DIR
+      - name: rsync all capabilites
+        run:  rsync vela-templates/registry/auto-gen/* $CAPABILITY_DIR
+      - name: sync local to cloud
+        run: ./ossutil --config-file .ossutilconfig sync $CAPABILITY_DIR oss://$CAPABILITY_BUCKET -f

.github/workflows/release.yml

@@ -13,10 +13,10 @@ jobs:
       VELA_VERSION: ${{ github.ref }}
       GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
     steps:
-      - name: Set up Go 1.14
+      - name: Set up Go
         uses: actions/setup-go@v1
         with:
-          go-version: 1.14
+          go-version: 1.16
         id: go
       - name: Check out code into the Go module directory
         uses: actions/checkout@v2
@@ -127,7 +127,12 @@ jobs:
           asset_content_type: text/plain
       - uses: actions/setup-node@v1
         with:
-          node-version: '12.x'
+          node-version: "12.x"
+      - uses: actions/setup-python@v2
+        with:
+          python-version: "3.7"
+      - name: Clean md files
+        run: python ./hack/website/clean-md.py ./docs/en
       - name: Sync release to kubevela.io Repo
         env:
           SSH_DEPLOY_KEY: ${{ secrets.GH_PAGES_DEPLOY }}
@@ -136,4 +141,4 @@ jobs:
         run: |
           bash ./hack/website/release.sh
       - name: Update kubectl plugin version in krew-index
-        uses: rajatjindal/krew-release-bot@v0.0.38
+        uses: rajatjindal/krew-release-bot@v0.0.38

.github/workflows/unit-test.yml

@@ -0,0 +1,81 @@
+name: Unit-Test
+
+on:
+  push:
+    branches:
+      - master
+      - release-*
+  workflow_dispatch: {}
+  pull_request:
+    branches:
+      - master
+      - release-*
+
+env:
+  # Common versions
+  GO_VERSION: '1.16'
+  GOLANGCI_VERSION: 'v1.38'
+  KIND_VERSION: 'v0.7.0'
+
+jobs:
+
+  detect-noop:
+    runs-on: ubuntu-20.04
+    outputs:
+      noop: ${{ steps.noop.outputs.should_skip }}
+    steps:
+      - name: Detect No-op Changes
+        id: noop
+        uses: fkirc/skip-duplicate-actions@v3.3.0
+        with:
+          github_token: ${{ secrets.GITHUB_TOKEN }}
+          paths_ignore: '["**.md", "**.mdx", "**.png", "**.jpg"]'
+          do_not_skip: '["workflow_dispatch", "schedule", "push"]'
+          concurrent_skipping: false
+
+  unit-tests:
+    runs-on: ubuntu-20.04
+    needs: detect-noop
+    if: needs.detect-noop.outputs.noop != 'true'
+
+    steps:
+      - name: Set up Go
+        uses: actions/setup-go@v1
+        with:
+          go-version: ${{ env.GO_VERSION }}
+        id: go
+
+      - name: Check out code into the Go module directory
+        uses: actions/checkout@v2
+        with:
+          submodules: true
+
+      - name: Cache Go Dependencies
+        uses: actions/cache@v2
+        with:
+          path: .work/pkg
+          key: ${{ runner.os }}-pkg-${{ hashFiles('**/go.sum') }}
+          restore-keys: ${{ runner.os }}-pkg-
+
+      - name: Install ginkgo
+        run:  |
+          sudo apt-get install -y golang-ginkgo-dev
+
+      - name: Setup Kind Cluster
+        uses: engineerd/setup-kind@v0.5.0
+        with:
+          version: ${{ env.KIND_VERSION }}
+
+      - name: install Kubebuilder
+        uses: wonderflow/kubebuilder-action@v1.1
+
+      - name: Run Make test
+        run: make test
+
+      - name: Upload coverage report
+        uses: codecov/codecov-action@v1
+        with:
+          token: ${{ secrets.CODECOV_TOKEN }}
+          file: ./coverage.txt
+          flags: unittests
+          name: codecov-umbrella

CONTRIBUTING.md

@@ -13,12 +13,34 @@ contributing to `kubevela` or build a PoC (Proof of Concept).
 
 ### Prerequisites
 
-1. Golang version 1.13+
+1. Golang version 1.16+
 2. Kubernetes version v1.16+ with `~/.kube/config` configured.
 3. ginkgo 1.14.0+ (just for [E2E test](./CONTRIBUTING.md#e2e-test))
 4. golangci-lint 1.31.0+, it will install automatically if you run `make`, you can [install it manually](https://golangci-lint.run/usage/install/#local-installation) if the installation is too slow.
+5. kubebuilder v2.3.0+
 
-We also recommend you to learn about KubeVela's [design](https://kubevela.io/docs/concepts) before dive into its code.
+<details>
+  <summary>Install Kubebuilder manually</summary>
+
+linux:
+```
+wget https://github.com/kubernetes-sigs/kubebuilder/releases/download/v2.3.1/kubebuilder_2.3.1_linux_amd64.tar.gz
+tar -zxvf  kubebuilder_2.3.1_linux_amd64.tar.gz
+mkdir -p /usr/local/kubebuilder/bin
+sudo mv kubebuilder_2.3.1_linux_amd64/bin/* /usr/local/kubebuilder/bin
+```
+
+macOS:
+```
+wget https://github.com/kubernetes-sigs/kubebuilder/releases/download/v2.3.1/kubebuilder_2.3.1_darwin_amd64.tar.gz
+tar -zxvf  kubebuilder_2.3.1_darwin_amd64.tar.gz
+mkdir -p /usr/local/kubebuilder/bin
+sudo mv kubebuilder_2.3.1_darwin_amd64/bin/* /usr/local/kubebuilder/bin
+```
+
+</details>
+
+We also recommend you to learn about KubeVela's [design](https://kubevela.io/docs/concepts) before diving into its code.
 
 ### Build
 

Dockerfile

@@ -1,5 +1,5 @@
 # Build the manager binary
-FROM --platform=${BUILDPLATFORM:-linux/amd64} golang:1.14-alpine as builder
+FROM --platform=${BUILDPLATFORM:-linux/amd64} golang:1.16-alpine as builder
 
 WORKDIR /workspace
 # Copy the Go Modules manifests

Makefile

@@ -66,21 +66,16 @@ doc-gen:
 	rm -r docs/en/cli/*
 	go run hack/docgen/gen.go
 
+PWD := $(shell pwd)
 docs-build:
-ifneq ($(wildcard git-page),)
-	rm -rf git-page
-endif
-	sh ./hack/website/test-build.sh
+	docker run -it -v $(PWD)/docs/sidebars.js:/workspace/kubevela.io/sidebars.js \
+	 -v $(PWD)/docs/en:/workspace/kubevela.io/docs \
+	 oamdev/vela-webtool:v1 -t build
 
 docs-start:
-ifeq ($(wildcard git-page),)
-	git clone --single-branch --depth 1 https://github.com/oam-dev/kubevela.io.git git-page
-endif
-	rm -r git-page/docs
-	rm git-page/sidebars.js
-	cat docs/sidebars.js > git-page/sidebars.js
-	cp -R docs/en git-page/docs
-	cd git-page && yarn install && yarn start
+	docker run -it -p 3000:3000 -v $(PWD)/docs/sidebars.js:/workspace/kubevela.io/sidebars.js \
+	 -v $(PWD)/docs/en:/workspace/kubevela.io/docs \
+	 oamdev/vela-webtool:v1 -t start
 
 api-gen:
 	swag init -g references/apiserver/route.go --output references/apiserver/docs
@@ -92,6 +87,7 @@ generate-source:
 
 cross-build:
 	rm -rf _bin
+	go get github.com/mitchellh/gox@v0.4.0
 	go run hack/chart/generate.go
 	$(GOBUILD_ENV) $(GOX) -ldflags $(LDFLAGS) -parallel=2 -output="_bin/vela/{{.OS}}-{{.Arch}}/vela" -osarch='$(TARGETS)' ./references/cmd/cli
 	$(GOBUILD_ENV) $(GOX) -ldflags $(LDFLAGS) -parallel=2 -output="_bin/kubectl-vela/{{.OS}}-{{.Arch}}/kubectl-vela" -osarch='$(TARGETS)' ./cmd/plugin
@@ -122,8 +118,9 @@ run: fmt vet
 # Run go fmt against code
 fmt: goimports installcue
 	go fmt ./...
-	$(GOIMPORTS) -local github.com/oam-dev/kubevela -w ./pkg ./cmd
-	$(CUE) fmt ./hack/vela-templates/cue/*
+	$(GOIMPORTS) -local github.com/oam-dev/kubevela -w $$(go list -f {{.Dir}} ./...)
+	$(CUE) fmt ./vela-templates/internal/cue/*
+	$(CUE) fmt ./vela-templates/registry/cue/*
 
 # Run go vet against code
 vet:
@@ -232,12 +229,12 @@ core-uninstall: manifests
 	kubectl delete -f charts/vela-core/crds/
 
 # Generate manifests e.g. CRD, RBAC etc.
-manifests: kustomize
+manifests: installcue kustomize
 	go generate $(foreach t,pkg apis,./$(t)/...)
 	# TODO(yangsoon): kustomize will merge all CRD into a whole file, it may not work if we want patch more than one CRD in this way
 	$(KUSTOMIZE) build config/crd -o config/crd/base/core.oam.dev_applications.yaml
 	mv config/crd/base/* charts/vela-core/crds
-	./hack/vela-templates/gen_definitions.sh
+	./vela-templates/gen_definitions.sh
 	./hack/crd/cleanup.sh
 
 GOLANGCILINT_VERSION ?= v1.31.0

README.md

@@ -20,7 +20,7 @@ KubeVela is a modern application platform that makes deploying and managing appl
 
 **Application Centric** - Leveraging Open Application Model (OAM), KubeVela introduces consistent yet higher level API to capture a full deployment of microservices on top of hybrid environments. Placement strategy and patch, traffic shifting and rolling update are all declared at application level. No infrastructure level concern, simply deploy.
 
-**Natively Extensible** - KubeVela uses [CUE](https://github.com/cuelang/cue) to glue capabilities (e.g. workload types, operational behaviors, and cloud services) provided by runtime infrastructure and expose them to users via self-service API. When users' needs grow, these API can naturally expand in programmable approach. No restriction, fully flexible.
+**Natively Extensible** - KubeVela uses [CUE](https://github.com/cuelang/cue) as super glue to assemble capabilities (e.g. workload types, operational behaviors, and cloud services) provided by runtime infrastructures and expose them to users via application-centric APIs. When users' needs grow, these APIs can naturally expand in programmable approach. No restriction, fully flexible.
 
 **Runtime Agnostic** - KubeVela is built with Kubernetes as control plane but adaptable to any runtime as data-plane. It can deploy (and manage) diverse workload types such as container, cloud functions, databases, or even EC2 instances across hybrid environments. Also, this means KubeVela seamlessly works with any Kubernetes compatible CI/CD or GitOps tools via declarative API.
 
@@ -52,5 +52,9 @@ Full documentation is available on the [KubeVela website](https://kubevela.io/).
 ## Contributing
 Check out [CONTRIBUTING](./CONTRIBUTING.md) to see how to develop with KubeVela.
 
+## Report Vulnerability
+
+Security is a first priority thing for us at KubeVela. If you come across a related issue, please send email to security@mail.kubevela.io .
+
 ## Code of Conduct
 KubeVela adopts [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md).

SECURITY.md

@@ -0,0 +1,20 @@
+# Security Policy
+
+## Reporting a Vulnerability
+
+If you've found a security issue that you'd like to disclose confidentially please send email to security@mail.kubevela.io .
+
+### Who Reads Email Sent to security@mail.kubevela.io?
+
+Only a restricted and carefully chosen group of KubeVela maintainers will have access to material sent to the security@mail.kubevela.io address.
+No outside users can subscribe to this list.
+
+### What to Send to security@mail.kubevela.io
+
+Please provide as much information about your system and the issue as possible when contacting the list.
+
+## How We Respond
+
+Email sent to security@mail.kubevela.io is read and acknowledged with a non-automated response within three working days.
+For issues that are complicated and require significant attention,
+we will open an investigation and will provide you with a mechanism to check the status of our progress at any time.

apis/core.oam.dev/common/types.go

@@ -163,6 +163,8 @@ const (
 	ApplicationRollingOut ApplicationPhase = "rollingOut"
 	// ApplicationRendering means the app is rendering
 	ApplicationRendering ApplicationPhase = "rendering"
+	// ApplicationRunningWorkflow means the app is running workflow
+	ApplicationRunningWorkflow ApplicationPhase = "runningWorkflow"
 	// ApplicationRunning means the app finished rendering and applied result to the cluster
 	ApplicationRunning ApplicationPhase = "running"
 	// ApplicationHealthChecking means the app finished rendering and applied result to the cluster, but still unhealthy
@@ -203,6 +205,14 @@ type RawComponent struct {
 	Raw runtime.RawExtension `json:"raw"`
 }
 
+// WorkflowStepStatus record the status of a workflow step
+type WorkflowStepStatus struct {
+	Name        string                         `json:"name,omitempty"`
+	Type        string                         `json:"type,omitempty"`
+	Phase       WorkflowStepPhase              `json:"phase,omitempty"`
+	ResourceRef runtimev1alpha1.TypedReference `json:"resourceRef,omitempty"`
+}
+
 // AppStatus defines the observed state of Application
 type AppStatus struct {
 	// INSERT ADDITIONAL STATUS FIELD - define observed state of cluster
@@ -222,13 +232,30 @@ type AppStatus struct {
 	// ResourceTracker record the status of the ResourceTracker
 	ResourceTracker *runtimev1alpha1.TypedReference `json:"resourceTracker,omitempty"`
 
+	// Workflow record the status of workflow steps
+	Workflow []WorkflowStepStatus `json:"workflow,omitempty"`
+
 	// LatestRevision of the application configuration it generates
 	// +optional
 	LatestRevision *Revision `json:"latestRevision,omitempty"`
 }
 
+// WorkflowStepPhase describes the phase of a workflow step.
+type WorkflowStepPhase string
+
+const (
+	// WorkflowStepPhaseSucceeded will make the controller run the next step.
+	WorkflowStepPhaseSucceeded WorkflowStepPhase = "succeeded"
+	// WorkflowStepPhaseFailed will make the controller stop the workflow and report error in `message`.
+	WorkflowStepPhaseFailed WorkflowStepPhase = "failed"
+	// WorkflowStepPhaseStopped will make the controller stop the workflow.
+	WorkflowStepPhaseStopped WorkflowStepPhase = "stopped"
+	// WorkflowStepPhaseRunning will make the controller continue the workflow.
+	WorkflowStepPhaseRunning WorkflowStepPhase = "running"
+)
+
 // DefinitionType describes the type of DefinitionRevision.
-// +kubebuilder:validation:Enum=Component;Trait
+// +kubebuilder:validation:Enum=Component;Trait;Policy;WorkflowStep
 type DefinitionType string
 
 const (
@@ -237,6 +264,12 @@ const (
 
 	// TraitType represents DefinitionRevision refer to type TraitDefinition
 	TraitType DefinitionType = "Trait"
+
+	// PolicyType represents DefinitionRevision refer to type PolicyDefinition
+	PolicyType DefinitionType = "Policy"
+
+	// WorkflowStepType represents DefinitionRevision refer to type WorkflowStepDefinition
+	WorkflowStepType DefinitionType = "WorkflowStep"
 )
 
 // AppRolloutStatus defines the observed state of AppRollout

apis/core.oam.dev/common/zz_generated.deepcopy.go

@@ -62,6 +62,11 @@ func (in *AppStatus) DeepCopyInto(out *AppStatus) {
 		*out = new(v1alpha1.TypedReference)
 		**out = **in
 	}
+	if in.Workflow != nil {
+		in, out := &in.Workflow, &out.Workflow
+		*out = make([]WorkflowStepStatus, len(*in))
+		copy(*out, *in)
+	}
 	if in.LatestRevision != nil {
 		in, out := &in.LatestRevision, &out.LatestRevision
 		*out = new(Revision)
@@ -338,6 +343,22 @@ func (in *Terraform) DeepCopy() *Terraform {
 	return out
 }
 
+// DeepCopyInto is an autogenerated deepcopy function, copying the receiver, writing into out. in must be non-nil.
+func (in *WorkflowStepStatus) DeepCopyInto(out *WorkflowStepStatus) {
+	*out = *in
+	out.ResourceRef = in.ResourceRef
+}
+
+// DeepCopy is an autogenerated deepcopy function, copying the receiver, creating a new WorkflowStepStatus.
+func (in *WorkflowStepStatus) DeepCopy() *WorkflowStepStatus {
+	if in == nil {
+		return nil
+	}
+	out := new(WorkflowStepStatus)
+	in.DeepCopyInto(out)
+	return out
+}
+
 // DeepCopyInto is an autogenerated deepcopy function, copying the receiver, writing into out. in must be non-nil.
 func (in *WorkloadGVK) DeepCopyInto(out *WorkloadGVK) {
 	*out = *in

apis/core.oam.dev/v1alpha2/zz_generated.deepcopy.go

@@ -22,9 +22,10 @@ package v1alpha2
 
 import (
 	"github.com/crossplane/crossplane-runtime/apis/core/v1alpha1"
+	"k8s.io/apimachinery/pkg/runtime"
+
 	"github.com/oam-dev/kubevela/apis/core.oam.dev/common"
 	standard_oam_devv1alpha1 "github.com/oam-dev/kubevela/apis/standard.oam.dev/v1alpha1"
-	"k8s.io/apimachinery/pkg/runtime"
 )
 
 // DeepCopyInto is an autogenerated deepcopy function, copying the receiver, writing into out. in must be non-nil.

apis/core.oam.dev/v1beta1/application_types.go

@@ -50,10 +50,43 @@ type ApplicationComponent struct {
 	Scopes map[string]string `json:"scopes,omitempty"`
 }
 
+// AppPolicy defines a global policy for all components in the app.
+type AppPolicy struct {
+	// Name is the unique name of the policy.
+	Name string `json:"name"`
+
+	Type string `json:"type"`
+	// +kubebuilder:pruning:PreserveUnknownFields
+	Properties runtime.RawExtension `json:"properties,omitempty"`
+}
+
+// WorkflowStep defines how to execute a workflow step.
+type WorkflowStep struct {
+	// Name is the unique name of the workflow step.
+	Name string `json:"name"`
+
+	Type string `json:"type"`
+
+	// +kubebuilder:pruning:PreserveUnknownFields
+	Properties runtime.RawExtension `json:"properties,omitempty"`
+}
+
 // ApplicationSpec is the spec of Application
 type ApplicationSpec struct {
 	Components []ApplicationComponent `json:"components"`
 
+	// Policies defines the global policies for all components in the app, e.g. security, metrics, gitops,
+	// multi-cluster placement rules, etc.
+	// Policies are applied after components are rendered and before workflow steps are executed.
+	Policies []AppPolicy `json:"policies,omitempty"`
+
+	// Workflow defines how to customize the control logic.
+	// If workflow is specified, Vela won't apply any resource, but provide rendered output in AppRevision.
+	// Workflow steps are executed in array order, and each step:
+	// - will have a context in annotation.
+	// - should mark "finish" phase in status.conditions.
+	Workflow []WorkflowStep `json:"workflow,omitempty"`
+
 	// TODO(wonderflow): we should have application level scopes supported here
 
 	// RolloutPlan is the details on how to rollout the resources

apis/core.oam.dev/v1beta1/applicationrevision_types.go

@@ -17,6 +17,7 @@
 package v1beta1
 
 import (
+	corev1 "k8s.io/api/core/v1"
 	metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
 	"k8s.io/apimachinery/pkg/runtime"
 
@@ -50,6 +51,9 @@ type ApplicationRevisionSpec struct {
 	// +kubebuilder:validation:EmbeddedResource
 	// +kubebuilder:pruning:PreserveUnknownFields
 	ApplicationConfiguration runtime.RawExtension `json:"applicationConfiguration"`
+
+	// ResourcesConfigMap references the ConfigMap that's generated to contain all final rendered resources.
+	ResourcesConfigMap corev1.LocalObjectReference `json:"resourcesConfigMap,omitempty"`
 }
 
 // +kubebuilder:object:root=true

apis/core.oam.dev/v1beta1/definitionrevision_types.go

@@ -38,6 +38,12 @@ type DefinitionRevisionSpec struct {
 
 	// TraitDefinition records the snapshot of the created/modified TraitDefinition
 	TraitDefinition TraitDefinition `json:"traitDefinition,omitempty"`
+
+	// PolicyDefinition records the snapshot of the created/modified PolicyDefinition
+	PolicyDefinition PolicyDefinition `json:"policyDefinition,omitempty"`
+
+	// WorkflowStepDefinition records the snapshot of the created/modified WorkflowStepDefinition
+	WorkflowStepDefinition WorkflowStepDefinition `json:"workflowStepDefinition,omitempty"`
 }
 
 // +kubebuilder:object:root=true

apis/core.oam.dev/v1beta1/policy_definition.go

@@ -0,0 +1,77 @@
+/*
+ Copyright 2021. The KubeVela Authors.
+
+ 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 v1beta1
+
+import (
+	runtimev1alpha1 "github.com/crossplane/crossplane-runtime/apis/core/v1alpha1"
+	metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
+
+	"github.com/oam-dev/kubevela/apis/core.oam.dev/common"
+)
+
+// PolicyDefinitionSpec defines the desired state of PolicyDefinition
+type PolicyDefinitionSpec struct {
+	// Reference to the CustomResourceDefinition that defines this trait kind.
+	Reference common.DefinitionReference `json:"definitionRef,omitempty"`
+
+	// Schematic defines the data format and template of the encapsulation of the policy definition
+	// +optional
+	Schematic *common.Schematic `json:"schematic,omitempty"`
+}
+
+// PolicyDefinitionStatus is the status of PolicyDefinition
+type PolicyDefinitionStatus struct {
+	// ConditionedStatus reflects the observed status of a resource
+	runtimev1alpha1.ConditionedStatus `json:",inline"`
+
+	// LatestRevision of the component definition
+	// +optional
+	LatestRevision *common.Revision `json:"latestRevision,omitempty"`
+}
+
+// SetConditions set condition for PolicyDefinition
+func (d *PolicyDefinition) SetConditions(c ...runtimev1alpha1.Condition) {
+	d.Status.SetConditions(c...)
+}
+
+// GetCondition gets condition from PolicyDefinition
+func (d *PolicyDefinition) GetCondition(conditionType runtimev1alpha1.ConditionType) runtimev1alpha1.Condition {
+	return d.Status.GetCondition(conditionType)
+}
+
+// +kubebuilder:object:root=true
+
+// PolicyDefinition is the Schema for the policydefinitions API
+// +kubebuilder:resource:scope=Namespaced,categories={oam},shortName=policy
+// +kubebuilder:storageversion
+// +kubebuilder:subresource:status
+type PolicyDefinition struct {
+	metav1.TypeMeta   `json:",inline"`
+	metav1.ObjectMeta `json:"metadata,omitempty"`
+
+	Spec   PolicyDefinitionSpec   `json:"spec,omitempty"`
+	Status PolicyDefinitionStatus `json:"status,omitempty"`
+}
+
+// +kubebuilder:object:root=true
+
+// PolicyDefinitionList contains a list of PolicyDefinition
+type PolicyDefinitionList struct {
+	metav1.TypeMeta `json:",inline"`
+	metav1.ListMeta `json:"metadata,omitempty"`
+	Items           []PolicyDefinition `json:"items"`
+}

apis/core.oam.dev/v1beta1/register.go

@@ -61,6 +61,22 @@ var (
 	TraitDefinitionGroupVersionKind = SchemeGroupVersion.WithKind(TraitDefinitionKind)
 )
 
+// PolicyDefinition type metadata.
+var (
+	PolicyDefinitionKind             = reflect.TypeOf(PolicyDefinition{}).Name()
+	PolicyDefinitionGroupKind        = schema.GroupKind{Group: Group, Kind: PolicyDefinitionKind}.String()
+	PolicyDefinitionKindAPIVersion   = PolicyDefinitionKind + "." + SchemeGroupVersion.String()
+	PolicyDefinitionGroupVersionKind = SchemeGroupVersion.WithKind(PolicyDefinitionKind)
+)
+
+// WorkflowStepDefinition type metadata.
+var (
+	WorkflowStepDefinitionKind             = reflect.TypeOf(WorkflowStepDefinition{}).Name()
+	WorkflowStepDefinitionGroupKind        = schema.GroupKind{Group: Group, Kind: WorkflowStepDefinitionKind}.String()
+	WorkflowStepDefinitionKindAPIVersion   = WorkflowStepDefinitionKind + "." + SchemeGroupVersion.String()
+	WorkflowStepDefinitionGroupVersionKind = SchemeGroupVersion.WithKind(WorkflowStepDefinitionKind)
+)
+
 // DefinitionRevision type metadata.
 var (
 	DefinitionRevisionKind             = reflect.TypeOf(DefinitionRevision{}).Name()
@@ -129,6 +145,8 @@ func init() {
 	SchemeBuilder.Register(&ComponentDefinition{}, &ComponentDefinitionList{})
 	SchemeBuilder.Register(&WorkloadDefinition{}, &WorkloadDefinitionList{})
 	SchemeBuilder.Register(&TraitDefinition{}, &TraitDefinitionList{})
+	SchemeBuilder.Register(&PolicyDefinition{}, &PolicyDefinitionList{})
+	SchemeBuilder.Register(&WorkflowStepDefinition{}, &WorkflowStepDefinitionList{})
 	SchemeBuilder.Register(&DefinitionRevision{}, &DefinitionRevisionList{})
 	SchemeBuilder.Register(&ScopeDefinition{}, &ScopeDefinitionList{})
 	SchemeBuilder.Register(&Application{}, &ApplicationList{})

apis/core.oam.dev/v1beta1/workflow_step_definition.go

@@ -0,0 +1,77 @@
+/*
+ Copyright 2021. The KubeVela Authors.
+
+ 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 v1beta1
+
+import (
+	runtimev1alpha1 "github.com/crossplane/crossplane-runtime/apis/core/v1alpha1"
+	metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
+
+	"github.com/oam-dev/kubevela/apis/core.oam.dev/common"
+)
+
+// WorkflowStepDefinitionSpec defines the desired state of WorkflowStepDefinition
+type WorkflowStepDefinitionSpec struct {
+	// Reference to the CustomResourceDefinition that defines this trait kind.
+	Reference common.DefinitionReference `json:"definitionRef,omitempty"`
+
+	// Schematic defines the data format and template of the encapsulation of the workflow step definition
+	// +optional
+	Schematic *common.Schematic `json:"schematic,omitempty"`
+}
+
+// WorkflowStepDefinitionStatus is the status of WorkflowStepDefinition
+type WorkflowStepDefinitionStatus struct {
+	// ConditionedStatus reflects the observed status of a resource
+	runtimev1alpha1.ConditionedStatus `json:",inline"`
+
+	// LatestRevision of the component definition
+	// +optional
+	LatestRevision *common.Revision `json:"latestRevision,omitempty"`
+}
+
+// SetConditions set condition for WorkflowStepDefinition
+func (d *WorkflowStepDefinition) SetConditions(c ...runtimev1alpha1.Condition) {
+	d.Status.SetConditions(c...)
+}
+
+// GetCondition gets condition from WorkflowStepDefinition
+func (d *WorkflowStepDefinition) GetCondition(conditionType runtimev1alpha1.ConditionType) runtimev1alpha1.Condition {
+	return d.Status.GetCondition(conditionType)
+}
+
+// +kubebuilder:object:root=true
+
+// WorkflowStepDefinition is the Schema for the workflowstepdefinitions API
+// +kubebuilder:resource:scope=Namespaced,categories={oam},shortName=workflowstep
+// +kubebuilder:storageversion
+// +kubebuilder:subresource:status
+type WorkflowStepDefinition struct {
+	metav1.TypeMeta   `json:",inline"`
+	metav1.ObjectMeta `json:"metadata,omitempty"`
+
+	Spec   WorkflowStepDefinitionSpec   `json:"spec,omitempty"`
+	Status WorkflowStepDefinitionStatus `json:"status,omitempty"`
+}
+
+// +kubebuilder:object:root=true
+
+// WorkflowStepDefinitionList contains a list of WorkflowStepDefinition
+type WorkflowStepDefinitionList struct {
+	metav1.TypeMeta `json:",inline"`
+	metav1.ListMeta `json:"metadata,omitempty"`
+	Items           []WorkflowStepDefinition `json:"items"`
+}

apis/core.oam.dev/v1beta1/zz_generated.deepcopy.go

@@ -21,9 +21,10 @@ limitations under the License.
 package v1beta1
 
 import (
+	"k8s.io/apimachinery/pkg/runtime"
+
 	"github.com/oam-dev/kubevela/apis/core.oam.dev/common"
 	"github.com/oam-dev/kubevela/apis/standard.oam.dev/v1alpha1"
-	"k8s.io/apimachinery/pkg/runtime"
 )
 
 // DeepCopyInto is an autogenerated deepcopy function, copying the receiver, writing into out. in must be non-nil.
@@ -135,6 +136,22 @@ func (in *AppDeploymentStatus) DeepCopy() *AppDeploymentStatus {
 	return out
 }
 
+// DeepCopyInto is an autogenerated deepcopy function, copying the receiver, writing into out. in must be non-nil.
+func (in *AppPolicy) DeepCopyInto(out *AppPolicy) {
+	*out = *in
+	in.Properties.DeepCopyInto(&out.Properties)
+}
+
+// DeepCopy is an autogenerated deepcopy function, copying the receiver, creating a new AppPolicy.
+func (in *AppPolicy) DeepCopy() *AppPolicy {
+	if in == nil {
+		return nil
+	}
+	out := new(AppPolicy)
+	in.DeepCopyInto(out)
+	return out
+}
+
 // DeepCopyInto is an autogenerated deepcopy function, copying the receiver, writing into out. in must be non-nil.
 func (in *AppRevision) DeepCopyInto(out *AppRevision) {
 	*out = *in
@@ -424,6 +441,7 @@ func (in *ApplicationRevisionSpec) DeepCopyInto(out *ApplicationRevisionSpec) {
 		}
 	}
 	in.ApplicationConfiguration.DeepCopyInto(&out.ApplicationConfiguration)
+	out.ResourcesConfigMap = in.ResourcesConfigMap
 }
 
 // DeepCopy is an autogenerated deepcopy function, copying the receiver, creating a new ApplicationRevisionSpec.
@@ -446,6 +464,20 @@ func (in *ApplicationSpec) DeepCopyInto(out *ApplicationSpec) {
 			(*in)[i].DeepCopyInto(&(*out)[i])
 		}
 	}
+	if in.Policies != nil {
+		in, out := &in.Policies, &out.Policies
+		*out = make([]AppPolicy, len(*in))
+		for i := range *in {
+			(*in)[i].DeepCopyInto(&(*out)[i])
+		}
+	}
+	if in.Workflow != nil {
+		in, out := &in.Workflow, &out.Workflow
+		*out = make([]WorkflowStep, len(*in))
+		for i := range *in {
+			(*in)[i].DeepCopyInto(&(*out)[i])
+		}
+	}
 	if in.RolloutPlan != nil {
 		in, out := &in.RolloutPlan, &out.RolloutPlan
 		*out = new(v1alpha1.RolloutPlan)
@@ -808,6 +840,8 @@ func (in *DefinitionRevisionSpec) DeepCopyInto(out *DefinitionRevisionSpec) {
 	*out = *in
 	in.ComponentDefinition.DeepCopyInto(&out.ComponentDefinition)
 	in.TraitDefinition.DeepCopyInto(&out.TraitDefinition)
+	in.PolicyDefinition.DeepCopyInto(&out.PolicyDefinition)
+	in.WorkflowStepDefinition.DeepCopyInto(&out.WorkflowStepDefinition)
 }
 
 // DeepCopy is an autogenerated deepcopy function, copying the receiver, creating a new DefinitionRevisionSpec.
@@ -921,6 +955,107 @@ func (in *PlacementStatus) DeepCopy() *PlacementStatus {
 	return out
 }
 
+// DeepCopyInto is an autogenerated deepcopy function, copying the receiver, writing into out. in must be non-nil.
+func (in *PolicyDefinition) DeepCopyInto(out *PolicyDefinition) {
+	*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 PolicyDefinition.
+func (in *PolicyDefinition) DeepCopy() *PolicyDefinition {
+	if in == nil {
+		return nil
+	}
+	out := new(PolicyDefinition)
+	in.DeepCopyInto(out)
+	return out
+}
+
+// DeepCopyObject is an autogenerated deepcopy function, copying the receiver, creating a new runtime.Object.
+func (in *PolicyDefinition) 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 *PolicyDefinitionList) DeepCopyInto(out *PolicyDefinitionList) {
+	*out = *in
+	out.TypeMeta = in.TypeMeta
+	in.ListMeta.DeepCopyInto(&out.ListMeta)
+	if in.Items != nil {
+		in, out := &in.Items, &out.Items
+		*out = make([]PolicyDefinition, len(*in))
+		for i := range *in {
+			(*in)[i].DeepCopyInto(&(*out)[i])
+		}
+	}
+}
+
+// DeepCopy is an autogenerated deepcopy function, copying the receiver, creating a new PolicyDefinitionList.
+func (in *PolicyDefinitionList) DeepCopy() *PolicyDefinitionList {
+	if in == nil {
+		return nil
+	}
+	out := new(PolicyDefinitionList)
+	in.DeepCopyInto(out)
+	return out
+}
+
+// DeepCopyObject is an autogenerated deepcopy function, copying the receiver, creating a new runtime.Object.
+func (in *PolicyDefinitionList) 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 *PolicyDefinitionSpec) DeepCopyInto(out *PolicyDefinitionSpec) {
+	*out = *in
+	out.Reference = in.Reference
+	if in.Schematic != nil {
+		in, out := &in.Schematic, &out.Schematic
+		*out = new(common.Schematic)
+		(*in).DeepCopyInto(*out)
+	}
+}
+
+// DeepCopy is an autogenerated deepcopy function, copying the receiver, creating a new PolicyDefinitionSpec.
+func (in *PolicyDefinitionSpec) DeepCopy() *PolicyDefinitionSpec {
+	if in == nil {
+		return nil
+	}
+	out := new(PolicyDefinitionSpec)
+	in.DeepCopyInto(out)
+	return out
+}
+
+// DeepCopyInto is an autogenerated deepcopy function, copying the receiver, writing into out. in must be non-nil.
+func (in *PolicyDefinitionStatus) DeepCopyInto(out *PolicyDefinitionStatus) {
+	*out = *in
+	in.ConditionedStatus.DeepCopyInto(&out.ConditionedStatus)
+	if in.LatestRevision != nil {
+		in, out := &in.LatestRevision, &out.LatestRevision
+		*out = new(common.Revision)
+		**out = **in
+	}
+}
+
+// DeepCopy is an autogenerated deepcopy function, copying the receiver, creating a new PolicyDefinitionStatus.
+func (in *PolicyDefinitionStatus) DeepCopy() *PolicyDefinitionStatus {
+	if in == nil {
+		return nil
+	}
+	out := new(PolicyDefinitionStatus)
+	in.DeepCopyInto(out)
+	return out
+}
+
 // DeepCopyInto is an autogenerated deepcopy function, copying the receiver, writing into out. in must be non-nil.
 func (in *ResourceTracker) DeepCopyInto(out *ResourceTracker) {
 	*out = *in
@@ -1276,6 +1411,123 @@ func (in *WeightedTarget) DeepCopy() *WeightedTarget {
 	return out
 }
 
+// DeepCopyInto is an autogenerated deepcopy function, copying the receiver, writing into out. in must be non-nil.
+func (in *WorkflowStep) DeepCopyInto(out *WorkflowStep) {
+	*out = *in
+	in.Properties.DeepCopyInto(&out.Properties)
+}
+
+// DeepCopy is an autogenerated deepcopy function, copying the receiver, creating a new WorkflowStep.
+func (in *WorkflowStep) DeepCopy() *WorkflowStep {
+	if in == nil {
+		return nil
+	}
+	out := new(WorkflowStep)
+	in.DeepCopyInto(out)
+	return out
+}
+
+// DeepCopyInto is an autogenerated deepcopy function, copying the receiver, writing into out. in must be non-nil.
+func (in *WorkflowStepDefinition) DeepCopyInto(out *WorkflowStepDefinition) {
+	*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 WorkflowStepDefinition.
+func (in *WorkflowStepDefinition) DeepCopy() *WorkflowStepDefinition {
+	if in == nil {
+		return nil
+	}
+	out := new(WorkflowStepDefinition)
+	in.DeepCopyInto(out)
+	return out
+}
+
+// DeepCopyObject is an autogenerated deepcopy function, copying the receiver, creating a new runtime.Object.
+func (in *WorkflowStepDefinition) 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 *WorkflowStepDefinitionList) DeepCopyInto(out *WorkflowStepDefinitionList) {
+	*out = *in
+	out.TypeMeta = in.TypeMeta
+	in.ListMeta.DeepCopyInto(&out.ListMeta)
+	if in.Items != nil {
+		in, out := &in.Items, &out.Items
+		*out = make([]WorkflowStepDefinition, len(*in))
+		for i := range *in {
+			(*in)[i].DeepCopyInto(&(*out)[i])
+		}
+	}
+}
+
+// DeepCopy is an autogenerated deepcopy function, copying the receiver, creating a new WorkflowStepDefinitionList.
+func (in *WorkflowStepDefinitionList) DeepCopy() *WorkflowStepDefinitionList {
+	if in == nil {
+		return nil
+	}
+	out := new(WorkflowStepDefinitionList)
+	in.DeepCopyInto(out)
+	return out
+}
+
+// DeepCopyObject is an autogenerated deepcopy function, copying the receiver, creating a new runtime.Object.
+func (in *WorkflowStepDefinitionList) 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 *WorkflowStepDefinitionSpec) DeepCopyInto(out *WorkflowStepDefinitionSpec) {
+	*out = *in
+	out.Reference = in.Reference
+	if in.Schematic != nil {
+		in, out := &in.Schematic, &out.Schematic
+		*out = new(common.Schematic)
+		(*in).DeepCopyInto(*out)
+	}
+}
+
+// DeepCopy is an autogenerated deepcopy function, copying the receiver, creating a new WorkflowStepDefinitionSpec.
+func (in *WorkflowStepDefinitionSpec) DeepCopy() *WorkflowStepDefinitionSpec {
+	if in == nil {
+		return nil
+	}
+	out := new(WorkflowStepDefinitionSpec)
+	in.DeepCopyInto(out)
+	return out
+}
+
+// DeepCopyInto is an autogenerated deepcopy function, copying the receiver, writing into out. in must be non-nil.
+func (in *WorkflowStepDefinitionStatus) DeepCopyInto(out *WorkflowStepDefinitionStatus) {
+	*out = *in
+	in.ConditionedStatus.DeepCopyInto(&out.ConditionedStatus)
+	if in.LatestRevision != nil {
+		in, out := &in.LatestRevision, &out.LatestRevision
+		*out = new(common.Revision)
+		**out = **in
+	}
+}
+
+// DeepCopy is an autogenerated deepcopy function, copying the receiver, creating a new WorkflowStepDefinitionStatus.
+func (in *WorkflowStepDefinitionStatus) DeepCopy() *WorkflowStepDefinitionStatus {
+	if in == nil {
+		return nil
+	}
+	out := new(WorkflowStepDefinitionStatus)
+	in.DeepCopyInto(out)
+	return out
+}
+
 // DeepCopyInto is an autogenerated deepcopy function, copying the receiver, writing into out. in must be non-nil.
 func (in *WorkloadDefinition) DeepCopyInto(out *WorkloadDefinition) {
 	*out = *in

apis/types/capability.go

@@ -22,6 +22,9 @@ import (
 	"cuelang.org/go/cue"
 	"github.com/google/go-cmp/cmp"
 	"github.com/spf13/pflag"
+	"k8s.io/apimachinery/pkg/runtime"
+
+	"github.com/oam-dev/kubevela/apis/core.oam.dev/common"
 )
 
 // Source record the source of Capability
@@ -62,6 +65,10 @@ type Capability struct {
 
 	// Terraform
 	TerraformConfiguration string `json:"terraformConfiguration,omitempty"`
+
+	// KubeTemplate
+	KubeTemplate  runtime.RawExtension   `json:"kubetemplate,omitempty"`
+	KubeParameter []common.KubeParameter `json:"kubeparameter,omitempty"`
 }
 
 // Chart defines all necessary information to install a whole chart
@@ -92,6 +99,10 @@ const (
 	TypeTrait CapType = "trait"
 	// TypeScope represent OAM Scope
 	TypeScope CapType = "scope"
+	// TypeWorkflowStep represent OAM Workflow
+	TypeWorkflowStep CapType = "workflowstep"
+	// TypePolicy represent OAM Policy
+	TypePolicy CapType = "policy"
 )
 
 // CapabilityConfigMapNamePrefix is the prefix for capability ConfigMap name
@@ -123,6 +134,7 @@ type Parameter struct {
 	Required bool        `json:"required,omitempty"`
 	Default  interface{} `json:"default,omitempty"`
 	Usage    string      `json:"usage,omitempty"`
+	Ignore   bool        `json:"ignore,omitempty"`
 	Type     cue.Kind    `json:"type,omitempty"`
 	Alias    string      `json:"alias,omitempty"`
 	JSONType string      `json:"jsonType,omitempty"`

apis/types/event.go

@@ -27,6 +27,7 @@ const (
 
 	ReasonFailedParse       = "FailedParse"
 	ReasonFailedRender      = "FailedRender"
+	ReasonFailedWorkflow    = "FailedWorkflow"
 	ReasonFailedApply       = "FailedApply"
 	ReasonFailedHealthCheck = "FailedHealthCheck"
 	ReasonFailedGC          = "FailedGC"

apis/types/types.go

@@ -29,6 +29,8 @@ const (
 	DefaultEnvName = "default"
 	// DefaultAppNamespace defines the default K8s namespace for Apps created by KubeVela
 	DefaultAppNamespace = "default"
+	// AutoDetectWorkloadDefinition defines the default workload type for ComponentDefinition which doesn't specify a workload
+	AutoDetectWorkloadDefinition = "autodetects.core.oam.dev"
 )
 
 const (
@@ -65,5 +67,5 @@ const (
 	// TypeSystem defines one category
 	TypeSystem = "System"
 	// TypePlugin defines one category used in Kubectl Plugin
-	TypePlugin = "Debug and Test"
+	TypePlugin = "Plugin Command"
 )

apis/types/workflow.go

@@ -0,0 +1,29 @@
+/*
+Copyright 2021 The KubeVela Authors.
+
+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 types
+
+import (
+	corev1 "k8s.io/api/core/v1"
+)
+
+// WorkflowContext is the workflow context to pass into workflow objects.
+type WorkflowContext struct {
+	AppName           string                      `json:"appName,omitempty"`
+	AppRevision       string                      `json:"appRevision,omitempty"`
+	WorkflowIndex     int                         `json:"workflowIndex"`
+	ResourceConfigMap corev1.LocalObjectReference `json:"resourceConfigMap,omitempty"`
+}

charts/vela-core/crds/core.oam.dev_applicationrevisions.yaml

@@ -542,6 +542,40 @@ spec:
                       status:
                         description: ApplicationPhase is a label for the condition of a application at the current time
                         type: string
+                      workflow:
+                        description: Workflow record the status of workflow steps
+                        items:
+                          description: WorkflowStepStatus record the status of a workflow step
+                          properties:
+                            name:
+                              type: string
+                            phase:
+                              description: WorkflowStepPhase describes the phase of a workflow step.
+                              type: string
+                            resourceRef:
+                              description: A TypedReference refers to an object by Name, Kind, and APIVersion. It is commonly used to reference cluster-scoped objects or objects where the namespace is already known.
+                              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
+                            type:
+                              type: string
+                          type: object
+                        type: array
                     type: object
                 type: object
               applicationConfiguration:
@@ -1294,6 +1328,24 @@ spec:
                           - type
                           type: object
                         type: array
+                      policies:
+                        description: Policies defines the global policies for all components in the app, e.g. security, metrics, gitops, multi-cluster placement rules, etc. Policies are applied after components are rendered and before workflow steps are executed.
+                        items:
+                          description: AppPolicy defines a global policy for all components in the app.
+                          properties:
+                            name:
+                              description: Name is the unique name of the policy.
+                              type: string
+                            properties:
+                              type: object
+                              x-kubernetes-preserve-unknown-fields: true
+                            type:
+                              type: string
+                          required:
+                          - name
+                          - type
+                          type: object
+                        type: array
                       rolloutPlan:
                         description: RolloutPlan is the details on how to rollout the resources The controller simply replace the old resources with the new one if there is no rollout plan involved
                         properties:
@@ -1512,6 +1564,24 @@ spec:
                             format: int32
                             type: integer
                         type: object
+                      workflow:
+                        description: 'Workflow defines how to customize the control logic. If workflow is specified, Vela won''t apply any resource, but provide rendered output in AppRevision. Workflow steps are executed in array order, and each step: - will have a context in annotation. - should mark "finish" phase in status.conditions.'
+                        items:
+                          description: WorkflowStep defines how to execute a workflow step.
+                          properties:
+                            name:
+                              description: Name is the unique name of the workflow step.
+                              type: string
+                            properties:
+                              type: object
+                              x-kubernetes-preserve-unknown-fields: true
+                            type:
+                              type: string
+                          required:
+                          - name
+                          - type
+                          type: object
+                        type: array
                     required:
                     - components
                     type: object
@@ -1747,6 +1817,40 @@ spec:
                       status:
                         description: ApplicationPhase is a label for the condition of a application at the current time
                         type: string
+                      workflow:
+                        description: Workflow record the status of workflow steps
+                        items:
+                          description: WorkflowStepStatus record the status of a workflow step
+                          properties:
+                            name:
+                              type: string
+                            phase:
+                              description: WorkflowStepPhase describes the phase of a workflow step.
+                              type: string
+                            resourceRef:
+                              description: A TypedReference refers to an object by Name, Kind, and APIVersion. It is commonly used to reference cluster-scoped objects or objects where the namespace is already known.
+                              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
+                            type:
+                              type: string
+                          type: object
+                        type: array
                     type: object
                 type: object
               applicationConfiguration:
@@ -1984,6 +2088,13 @@ spec:
                   - raw
                   type: object
                 type: array
+              resourcesConfigMap:
+                description: ResourcesConfigMap references the ConfigMap that's generated to contain all final rendered resources.
+                properties:
+                  name:
+                    description: 'Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names TODO: Add other useful fields. apiVersion, kind, uid?'
+                    type: string
+                type: object
               scopeDefinitions:
                 additionalProperties:
                   description: A ScopeDefinition registers a kind of Kubernetes custom resource as a valid OAM scope kind by referencing its CustomResourceDefinition. The CRD is used to validate the schema of the scope when it is embedded in an OAM ApplicationConfiguration.

charts/vela-core/crds/core.oam.dev_applications.yaml

@@ -554,6 +554,40 @@ spec:
               status:
                 description: ApplicationPhase is a label for the condition of a application at the current time
                 type: string
+              workflow:
+                description: Workflow record the status of workflow steps
+                items:
+                  description: WorkflowStepStatus record the status of a workflow step
+                  properties:
+                    name:
+                      type: string
+                    phase:
+                      description: WorkflowStepPhase describes the phase of a workflow step.
+                      type: string
+                    resourceRef:
+                      description: A TypedReference refers to an object by Name, Kind, and APIVersion. It is commonly used to reference cluster-scoped objects or objects where the namespace is already known.
+                      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
+                    type:
+                      type: string
+                  type: object
+                type: array
             type: object
         type: object
     served: true
@@ -631,6 +665,24 @@ spec:
                   - type
                   type: object
                 type: array
+              policies:
+                description: Policies defines the global policies for all components in the app, e.g. security, metrics, gitops, multi-cluster placement rules, etc. Policies are applied after components are rendered and before workflow steps are executed.
+                items:
+                  description: AppPolicy defines a global policy for all components in the app.
+                  properties:
+                    name:
+                      description: Name is the unique name of the policy.
+                      type: string
+                    properties:
+                      type: object
+                      x-kubernetes-preserve-unknown-fields: true
+                    type:
+                      type: string
+                  required:
+                  - name
+                  - type
+                  type: object
+                type: array
               rolloutPlan:
                 description: RolloutPlan is the details on how to rollout the resources The controller simply replace the old resources with the new one if there is no rollout plan involved
                 properties:
@@ -849,6 +901,24 @@ spec:
                     format: int32
                     type: integer
                 type: object
+              workflow:
+                description: 'Workflow defines how to customize the control logic. If workflow is specified, Vela won''t apply any resource, but provide rendered output in AppRevision. Workflow steps are executed in array order, and each step: - will have a context in annotation. - should mark "finish" phase in status.conditions.'
+                items:
+                  description: WorkflowStep defines how to execute a workflow step.
+                  properties:
+                    name:
+                      description: Name is the unique name of the workflow step.
+                      type: string
+                    properties:
+                      type: object
+                      x-kubernetes-preserve-unknown-fields: true
+                    type:
+                      type: string
+                  required:
+                  - name
+                  - type
+                  type: object
+                type: array
             required:
             - components
             type: object
@@ -1084,6 +1154,40 @@ spec:
               status:
                 description: ApplicationPhase is a label for the condition of a application at the current time
                 type: string
+              workflow:
+                description: Workflow record the status of workflow steps
+                items:
+                  description: WorkflowStepStatus record the status of a workflow step
+                  properties:
+                    name:
+                      type: string
+                    phase:
+                      description: WorkflowStepPhase describes the phase of a workflow step.
+                      type: string
+                    resourceRef:
+                      description: A TypedReference refers to an object by Name, Kind, and APIVersion. It is commonly used to reference cluster-scoped objects or objects where the namespace is already known.
+                      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
+                    type:
+                      type: string
+                  type: object
+                type: array
             type: object
         type: object
     served: true

charts/vela-core/crds/core.oam.dev_definitionrevisions.yaml

@@ -264,7 +264,171 @@ spec:
                 enum:
                 - Component
                 - Trait
+                - Policy
+                - WorkflowStep
                 type: string
+              policyDefinition:
+                description: PolicyDefinition records the snapshot of the created/modified PolicyDefinition
+                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: PolicyDefinitionSpec defines the desired state of PolicyDefinition
+                    properties:
+                      definitionRef:
+                        description: Reference to the CustomResourceDefinition that defines this trait kind.
+                        properties:
+                          name:
+                            description: Name of the referenced CustomResourceDefinition.
+                            type: string
+                          version:
+                            description: Version indicate which version should be used if CRD has multiple versions by default it will use the first one if not specified
+                            type: string
+                        required:
+                        - name
+                        type: object
+                      schematic:
+                        description: Schematic defines the data format and template of the encapsulation of the policy definition
+                        properties:
+                          cue:
+                            description: CUE defines the encapsulation in CUE format
+                            properties:
+                              template:
+                                description: Template defines the abstraction template data of the capability, it will replace the old CUE template in extension field. Template is a required field if CUE is defined in Capability Definition.
+                                type: string
+                            required:
+                            - template
+                            type: object
+                          helm:
+                            description: A Helm represents resources used by a Helm module
+                            properties:
+                              release:
+                                description: Release records a Helm release used by a Helm module workload.
+                                type: object
+                                x-kubernetes-preserve-unknown-fields: true
+                              repository:
+                                description: HelmRelease records a Helm repository used by a Helm module workload.
+                                type: object
+                                x-kubernetes-preserve-unknown-fields: true
+                            required:
+                            - release
+                            - repository
+                            type: object
+                          kube:
+                            description: Kube defines the encapsulation in raw Kubernetes resource format
+                            properties:
+                              parameters:
+                                description: Parameters defines configurable parameters
+                                items:
+                                  description: A KubeParameter defines a configurable parameter of a component.
+                                  properties:
+                                    description:
+                                      description: Description of this parameter.
+                                      type: string
+                                    fieldPaths:
+                                      description: "FieldPaths specifies an array of fields within this workload that will be overwritten by the value of this parameter. \tAll fields must be of the same type. Fields are specified as JSON field paths without a leading dot, for example 'spec.replicas'."
+                                      items:
+                                        type: string
+                                      type: array
+                                    name:
+                                      description: Name of this parameter
+                                      type: string
+                                    required:
+                                      default: false
+                                      description: Required specifies whether or not a value for this parameter must be supplied when authoring an Application.
+                                      type: boolean
+                                    type:
+                                      description: 'ValueType indicates the type of the parameter value, and only supports basic data types: string, number, boolean.'
+                                      enum:
+                                      - string
+                                      - number
+                                      - boolean
+                                      type: string
+                                  required:
+                                  - fieldPaths
+                                  - name
+                                  - type
+                                  type: object
+                                type: array
+                              template:
+                                description: Template defines the raw Kubernetes resource
+                                type: object
+                                x-kubernetes-preserve-unknown-fields: true
+                            required:
+                            - template
+                            type: object
+                          terraform:
+                            description: Terraform is the struct to describe cloud resources managed by Hashicorp Terraform
+                            properties:
+                              configuration:
+                                description: Configuration is Terraform Configuration
+                                type: string
+                              type:
+                                default: hcl
+                                description: Type specifies which Terraform configuration it is, HCL or JSON syntax
+                                enum:
+                                - hcl
+                                - json
+                                type: string
+                            required:
+                            - configuration
+                            type: object
+                        type: object
+                    type: object
+                  status:
+                    description: PolicyDefinitionStatus is the status of PolicyDefinition
+                    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
+                      latestRevision:
+                        description: LatestRevision of the component definition
+                        properties:
+                          name:
+                            type: string
+                          revision:
+                            format: int64
+                            type: integer
+                          revisionHash:
+                            description: RevisionHash record the hash value of the spec of ApplicationRevision object.
+                            type: string
+                        required:
+                        - name
+                        - revision
+                        type: object
+                    type: object
+                type: object
               revision:
                 description: Revision record revision number of DefinitionRevision
                 format: int64
@@ -470,6 +634,168 @@ spec:
                         type: object
                     type: object
                 type: object
+              workflowStepDefinition:
+                description: WorkflowStepDefinition records the snapshot of the created/modified WorkflowStepDefinition
+                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: WorkflowStepDefinitionSpec defines the desired state of WorkflowStepDefinition
+                    properties:
+                      definitionRef:
+                        description: Reference to the CustomResourceDefinition that defines this trait kind.
+                        properties:
+                          name:
+                            description: Name of the referenced CustomResourceDefinition.
+                            type: string
+                          version:
+                            description: Version indicate which version should be used if CRD has multiple versions by default it will use the first one if not specified
+                            type: string
+                        required:
+                        - name
+                        type: object
+                      schematic:
+                        description: Schematic defines the data format and template of the encapsulation of the workflow step definition
+                        properties:
+                          cue:
+                            description: CUE defines the encapsulation in CUE format
+                            properties:
+                              template:
+                                description: Template defines the abstraction template data of the capability, it will replace the old CUE template in extension field. Template is a required field if CUE is defined in Capability Definition.
+                                type: string
+                            required:
+                            - template
+                            type: object
+                          helm:
+                            description: A Helm represents resources used by a Helm module
+                            properties:
+                              release:
+                                description: Release records a Helm release used by a Helm module workload.
+                                type: object
+                                x-kubernetes-preserve-unknown-fields: true
+                              repository:
+                                description: HelmRelease records a Helm repository used by a Helm module workload.
+                                type: object
+                                x-kubernetes-preserve-unknown-fields: true
+                            required:
+                            - release
+                            - repository
+                            type: object
+                          kube:
+                            description: Kube defines the encapsulation in raw Kubernetes resource format
+                            properties:
+                              parameters:
+                                description: Parameters defines configurable parameters
+                                items:
+                                  description: A KubeParameter defines a configurable parameter of a component.
+                                  properties:
+                                    description:
+                                      description: Description of this parameter.
+                                      type: string
+                                    fieldPaths:
+                                      description: "FieldPaths specifies an array of fields within this workload that will be overwritten by the value of this parameter. \tAll fields must be of the same type. Fields are specified as JSON field paths without a leading dot, for example 'spec.replicas'."
+                                      items:
+                                        type: string
+                                      type: array
+                                    name:
+                                      description: Name of this parameter
+                                      type: string
+                                    required:
+                                      default: false
+                                      description: Required specifies whether or not a value for this parameter must be supplied when authoring an Application.
+                                      type: boolean
+                                    type:
+                                      description: 'ValueType indicates the type of the parameter value, and only supports basic data types: string, number, boolean.'
+                                      enum:
+                                      - string
+                                      - number
+                                      - boolean
+                                      type: string
+                                  required:
+                                  - fieldPaths
+                                  - name
+                                  - type
+                                  type: object
+                                type: array
+                              template:
+                                description: Template defines the raw Kubernetes resource
+                                type: object
+                                x-kubernetes-preserve-unknown-fields: true
+                            required:
+                            - template
+                            type: object
+                          terraform:
+                            description: Terraform is the struct to describe cloud resources managed by Hashicorp Terraform
+                            properties:
+                              configuration:
+                                description: Configuration is Terraform Configuration
+                                type: string
+                              type:
+                                default: hcl
+                                description: Type specifies which Terraform configuration it is, HCL or JSON syntax
+                                enum:
+                                - hcl
+                                - json
+                                type: string
+                            required:
+                            - configuration
+                            type: object
+                        type: object
+                    type: object
+                  status:
+                    description: WorkflowStepDefinitionStatus is the status of WorkflowStepDefinition
+                    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
+                      latestRevision:
+                        description: LatestRevision of the component definition
+                        properties:
+                          name:
+                            type: string
+                          revision:
+                            format: int64
+                            type: integer
+                          revisionHash:
+                            description: RevisionHash record the hash value of the spec of ApplicationRevision object.
+                            type: string
+                        required:
+                        - name
+                        - revision
+                        type: object
+                    type: object
+                type: object
             required:
             - definitionType
             - revision

charts/vela-core/crds/core.oam.dev_policydefinitions.yaml

@@ -0,0 +1,195 @@
+
+---
+apiVersion: apiextensions.k8s.io/v1
+kind: CustomResourceDefinition
+metadata:
+  annotations:
+    controller-gen.kubebuilder.io/version: v0.2.4
+  name: policydefinitions.core.oam.dev
+spec:
+  group: core.oam.dev
+  names:
+    categories:
+    - oam
+    kind: PolicyDefinition
+    listKind: PolicyDefinitionList
+    plural: policydefinitions
+    shortNames:
+    - policy
+    singular: policydefinition
+  scope: Namespaced
+  versions:
+  - name: v1beta1
+    schema:
+      openAPIV3Schema:
+        description: PolicyDefinition is the Schema for the policydefinitions 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: PolicyDefinitionSpec defines the desired state of PolicyDefinition
+            properties:
+              definitionRef:
+                description: Reference to the CustomResourceDefinition that defines this trait kind.
+                properties:
+                  name:
+                    description: Name of the referenced CustomResourceDefinition.
+                    type: string
+                  version:
+                    description: Version indicate which version should be used if CRD has multiple versions by default it will use the first one if not specified
+                    type: string
+                required:
+                - name
+                type: object
+              schematic:
+                description: Schematic defines the data format and template of the encapsulation of the policy definition
+                properties:
+                  cue:
+                    description: CUE defines the encapsulation in CUE format
+                    properties:
+                      template:
+                        description: Template defines the abstraction template data of the capability, it will replace the old CUE template in extension field. Template is a required field if CUE is defined in Capability Definition.
+                        type: string
+                    required:
+                    - template
+                    type: object
+                  helm:
+                    description: A Helm represents resources used by a Helm module
+                    properties:
+                      release:
+                        description: Release records a Helm release used by a Helm module workload.
+                        type: object
+                        x-kubernetes-preserve-unknown-fields: true
+                      repository:
+                        description: HelmRelease records a Helm repository used by a Helm module workload.
+                        type: object
+                        x-kubernetes-preserve-unknown-fields: true
+                    required:
+                    - release
+                    - repository
+                    type: object
+                  kube:
+                    description: Kube defines the encapsulation in raw Kubernetes resource format
+                    properties:
+                      parameters:
+                        description: Parameters defines configurable parameters
+                        items:
+                          description: A KubeParameter defines a configurable parameter of a component.
+                          properties:
+                            description:
+                              description: Description of this parameter.
+                              type: string
+                            fieldPaths:
+                              description: "FieldPaths specifies an array of fields within this workload that will be overwritten by the value of this parameter. \tAll fields must be of the same type. Fields are specified as JSON field paths without a leading dot, for example 'spec.replicas'."
+                              items:
+                                type: string
+                              type: array
+                            name:
+                              description: Name of this parameter
+                              type: string
+                            required:
+                              default: false
+                              description: Required specifies whether or not a value for this parameter must be supplied when authoring an Application.
+                              type: boolean
+                            type:
+                              description: 'ValueType indicates the type of the parameter value, and only supports basic data types: string, number, boolean.'
+                              enum:
+                              - string
+                              - number
+                              - boolean
+                              type: string
+                          required:
+                          - fieldPaths
+                          - name
+                          - type
+                          type: object
+                        type: array
+                      template:
+                        description: Template defines the raw Kubernetes resource
+                        type: object
+                        x-kubernetes-preserve-unknown-fields: true
+                    required:
+                    - template
+                    type: object
+                  terraform:
+                    description: Terraform is the struct to describe cloud resources managed by Hashicorp Terraform
+                    properties:
+                      configuration:
+                        description: Configuration is Terraform Configuration
+                        type: string
+                      type:
+                        default: hcl
+                        description: Type specifies which Terraform configuration it is, HCL or JSON syntax
+                        enum:
+                        - hcl
+                        - json
+                        type: string
+                    required:
+                    - configuration
+                    type: object
+                type: object
+            type: object
+          status:
+            description: PolicyDefinitionStatus is the status of PolicyDefinition
+            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
+              latestRevision:
+                description: LatestRevision of the component definition
+                properties:
+                  name:
+                    type: string
+                  revision:
+                    format: int64
+                    type: integer
+                  revisionHash:
+                    description: RevisionHash record the hash value of the spec of ApplicationRevision object.
+                    type: string
+                required:
+                - name
+                - revision
+                type: object
+            type: object
+        type: object
+    served: true
+    storage: true
+    subresources:
+      status: {}
+status:
+  acceptedNames:
+    kind: ""
+    plural: ""
+  conditions: []
+  storedVersions: []

charts/vela-core/crds/core.oam.dev_workflowstepdefinitions.yaml

@@ -0,0 +1,195 @@
+
+---
+apiVersion: apiextensions.k8s.io/v1
+kind: CustomResourceDefinition
+metadata:
+  annotations:
+    controller-gen.kubebuilder.io/version: v0.2.4
+  name: workflowstepdefinitions.core.oam.dev
+spec:
+  group: core.oam.dev
+  names:
+    categories:
+    - oam
+    kind: WorkflowStepDefinition
+    listKind: WorkflowStepDefinitionList
+    plural: workflowstepdefinitions
+    shortNames:
+    - workflowstep
+    singular: workflowstepdefinition
+  scope: Namespaced
+  versions:
+  - name: v1beta1
+    schema:
+      openAPIV3Schema:
+        description: WorkflowStepDefinition is the Schema for the workflowstepdefinitions 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: WorkflowStepDefinitionSpec defines the desired state of WorkflowStepDefinition
+            properties:
+              definitionRef:
+                description: Reference to the CustomResourceDefinition that defines this trait kind.
+                properties:
+                  name:
+                    description: Name of the referenced CustomResourceDefinition.
+                    type: string
+                  version:
+                    description: Version indicate which version should be used if CRD has multiple versions by default it will use the first one if not specified
+                    type: string
+                required:
+                - name
+                type: object
+              schematic:
+                description: Schematic defines the data format and template of the encapsulation of the workflow step definition
+                properties:
+                  cue:
+                    description: CUE defines the encapsulation in CUE format
+                    properties:
+                      template:
+                        description: Template defines the abstraction template data of the capability, it will replace the old CUE template in extension field. Template is a required field if CUE is defined in Capability Definition.
+                        type: string
+                    required:
+                    - template
+                    type: object
+                  helm:
+                    description: A Helm represents resources used by a Helm module
+                    properties:
+                      release:
+                        description: Release records a Helm release used by a Helm module workload.
+                        type: object
+                        x-kubernetes-preserve-unknown-fields: true
+                      repository:
+                        description: HelmRelease records a Helm repository used by a Helm module workload.
+                        type: object
+                        x-kubernetes-preserve-unknown-fields: true
+                    required:
+                    - release
+                    - repository
+                    type: object
+                  kube:
+                    description: Kube defines the encapsulation in raw Kubernetes resource format
+                    properties:
+                      parameters:
+                        description: Parameters defines configurable parameters
+                        items:
+                          description: A KubeParameter defines a configurable parameter of a component.
+                          properties:
+                            description:
+                              description: Description of this parameter.
+                              type: string
+                            fieldPaths:
+                              description: "FieldPaths specifies an array of fields within this workload that will be overwritten by the value of this parameter. \tAll fields must be of the same type. Fields are specified as JSON field paths without a leading dot, for example 'spec.replicas'."
+                              items:
+                                type: string
+                              type: array
+                            name:
+                              description: Name of this parameter
+                              type: string
+                            required:
+                              default: false
+                              description: Required specifies whether or not a value for this parameter must be supplied when authoring an Application.
+                              type: boolean
+                            type:
+                              description: 'ValueType indicates the type of the parameter value, and only supports basic data types: string, number, boolean.'
+                              enum:
+                              - string
+                              - number
+                              - boolean
+                              type: string
+                          required:
+                          - fieldPaths
+                          - name
+                          - type
+                          type: object
+                        type: array
+                      template:
+                        description: Template defines the raw Kubernetes resource
+                        type: object
+                        x-kubernetes-preserve-unknown-fields: true
+                    required:
+                    - template
+                    type: object
+                  terraform:
+                    description: Terraform is the struct to describe cloud resources managed by Hashicorp Terraform
+                    properties:
+                      configuration:
+                        description: Configuration is Terraform Configuration
+                        type: string
+                      type:
+                        default: hcl
+                        description: Type specifies which Terraform configuration it is, HCL or JSON syntax
+                        enum:
+                        - hcl
+                        - json
+                        type: string
+                    required:
+                    - configuration
+                    type: object
+                type: object
+            type: object
+          status:
+            description: WorkflowStepDefinitionStatus is the status of WorkflowStepDefinition
+            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
+              latestRevision:
+                description: LatestRevision of the component definition
+                properties:
+                  name:
+                    type: string
+                  revision:
+                    format: int64
+                    type: integer
+                  revisionHash:
+                    description: RevisionHash record the hash value of the spec of ApplicationRevision object.
+                    type: string
+                required:
+                - name
+                - revision
+                type: object
+            type: object
+        type: object
+    served: true
+    storage: true
+    subresources:
+      status: {}
+status:
+  acceptedNames:
+    kind: ""
+    plural: ""
+  conditions: []
+  storedVersions: []

charts/vela-core/templates/admission-webhooks/mutatingWebhookConfiguration.yaml

@@ -115,5 +115,30 @@ webhooks:
           - UPDATE
         resources:
           - podspecworkloads
+  - clientConfig:
+      caBundle: Cg==
+      service:
+        name: {{ template "kubevela.name" . }}-webhook
+        namespace: {{ .Release.Namespace }}
+        path: /mutating-core-oam-dev-v1beta1-componentdefinitions
+    {{- if .Values.admissionWebhooks.patch.enabled  }}
+    failurePolicy: Ignore
+    {{- else }}
+    failurePolicy: Fail
+    {{- end }}
+    name: mutating.core.oam-dev.v1beta1.componentdefinitions
+    sideEffects: None
+    admissionReviewVersions:
+      - v1beta1
+    rules:
+      - apiGroups:
+          - core.oam.dev
+        apiVersions:
+          - v1beta1
+        operations:
+          - CREATE
+          - UPDATE
+        resources:
+          - componentdefinitions
 
 {{- end -}}

charts/vela-core/templates/admission-webhooks/validatingWebhookConfiguration.yaml

@@ -163,4 +163,30 @@ webhooks:
           - UPDATE
         resources:
           - applications
+  - clientConfig:
+      caBundle: Cg==
+      service:
+        name: {{ template "kubevela.name" . }}-webhook
+        namespace: {{ .Release.Namespace }}
+        path: /validating-core-oam-dev-v1beta1-componentdefinitions
+    {{- if .Values.admissionWebhooks.patch.enabled  }}
+    failurePolicy: Ignore
+    {{- else }}
+    failurePolicy: Fail
+    {{- end }}
+    name: validating.core.oam-dev.v1beta1.componentdefinitions
+    sideEffects: None
+    admissionReviewVersions:
+      - v1beta1
+    rules:
+      - apiGroups:
+          - core.oam.dev
+        apiVersions:
+          - v1beta1
+        operations:
+          - CREATE
+          - UPDATE
+        resources:
+          - componentdefinitions
+          
 {{- end -}}

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

@@ -0,0 +1,10 @@
+apiVersion: core.oam.dev/v1beta1
+kind: WorkloadDefinition
+metadata:
+  annotations:
+    definition.oam.dev/description: "autodetects.core.oam.dev is the default workload type of ComponentDefinition"
+  name: autodetects.core.oam.dev
+  namespace: {{.Values.systemDefinitionNamespace}}
+spec:
+  definitionRef:
+    name: autodetects.core.oam.dev

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

@@ -9,7 +9,6 @@ metadata:
 spec:
   appliesToWorkloads:
     - deployments.apps
-  podDisruptive: true
   schematic:
     cue:
       template: |-

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

@@ -8,8 +8,7 @@ metadata:
   namespace: {{.Values.systemDefinitionNamespace}}
 spec:
   appliesToWorkloads:
-    - webservice
-    - worker
+    - deployments.apps
   schematic:
     cue:
       template: |

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

@@ -0,0 +1,36 @@
+# Code generated by KubeVela templates. DO NOT EDIT.
+apiVersion: core.oam.dev/v1beta1
+kind: TraitDefinition
+metadata:
+  annotations:
+    definition.oam.dev/description: "Expose port to enable web traffic for your component."
+  name: expose
+  namespace: {{.Values.systemDefinitionNamespace}}
+spec:
+  appliesToWorkloads:
+    - deployments.apps
+  podDisruptive: false
+  schematic:
+    cue:
+      template: |
+        outputs: service: {
+        	apiVersion: "v1"
+        	kind:       "Service"
+        	metadata:
+        		name: context.name
+        	spec: {
+        		selector:
+        			"app.oam.dev/component": context.name
+        		ports: [
+        			for p in parameter.port {
+        				port:       p
+        				targetPort: p
+        			},
+        		]
+        	}
+        }
+        parameter: {
+        	// +usage=Specify the exposion ports
+        	port: [...int]
+        }
+        

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

@@ -24,8 +24,7 @@ spec:
     healthPolicy: |
       isHealth: len(context.outputs.service.spec.clusterIP) > 0
   appliesToWorkloads:
-    - webservice
-    - worker
+    - deployments.apps
   podDisruptive: false
   schematic:
     cue:

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

@@ -9,7 +9,6 @@ metadata:
 spec:
   appliesToWorkloads:
     - deployments.apps
-  podDisruptive: true
   schematic:
     cue:
       template: |-

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

@@ -8,8 +8,7 @@ metadata:
   namespace: {{.Values.systemDefinitionNamespace}}
 spec:
   appliesToWorkloads:
-    - webservice
-    - worker
+    - deployments.apps
   podDisruptive: false
   schematic:
     cue:

charts/vela-core/templates/defwithtemplate/service-binding.yaml

@@ -0,0 +1,46 @@
+# Code generated by KubeVela templates. DO NOT EDIT.
+apiVersion: core.oam.dev/v1beta1
+kind: TraitDefinition
+metadata:
+  annotations:
+    definition.oam.dev/description: "Binding secrets of cloud resources to component env"
+  name: service-binding
+  namespace: {{.Values.systemDefinitionNamespace}}
+spec:
+  appliesToWorkloads:
+    - webservice
+    - worker
+  schematic:
+    cue:
+      template: |
+        patch: {
+        	spec: template: spec: {
+        		// +patchKey=name
+        		containers: [{
+        			name: context.name
+        			// +patchKey=name
+        			env: [
+        				for envName, v in parameter.envMappings {
+        					name: envName
+        					valueFrom: {
+        						secretKeyRef: {
+        							name: v.secret
+        							if v["key"] != _|_ {
+        								key: v.key
+        							}
+        							if v["key"] == _|_ {
+        								key: envName
+        							}
+        						}
+        					}
+        				},
+        			]
+        		}]
+        	}
+        }
+        
+        parameter: {
+        	// +usage=The mapping of environment variables to secret
+        	envMappings: [string]: [string]: string
+        }
+        

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

@@ -9,7 +9,6 @@ metadata:
 spec:
   appliesToWorkloads:
     - deployments.apps
-  podDisruptive: true
   schematic:
     cue:
       template: |-

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

@@ -29,10 +29,77 @@ spec:
         				if parameter["cmd"] != _|_ {
         					command: parameter.cmd
         				}
+        
+        				if parameter["env"] != _|_ {
+        					env: parameter.env
+        				}
+        
+        				if parameter["cpu"] != _|_ {
+        					resources: {
+        						limits:
+        							cpu: parameter.cpu
+        						requests:
+        							cpu: parameter.cpu
+        					}
+        				}
+        
+        				if parameter["memory"] != _|_ {
+        					resources: {
+        						limits:
+        							memory: parameter.memory
+        						requests:
+        							memory: parameter.memory
+        					}
+        				}
+        
+        				if parameter["volumes"] != _|_ {
+        					volumeMounts: [ for v in parameter.volumes {
+        						{
+        							mountPath: v.mountPath
+        							name:      v.name
+        						}}]
+        				}
         			}]
+        
+        		if parameter["volumes"] != _|_ {
+        			volumes: [ for v in parameter.volumes {
+        				{
+        					name: v.name
+        					if v.type == "pvc" {
+        						persistentVolumeClaim: {
+        							claimName: v.claimName
+        						}
+        					}
+        					if v.type == "configMap" {
+        						configMap: {
+        							defaultMode: v.defaultMode
+        							name:        v.cmName
+        							if v.items != _|_ {
+        								items: v.items
+        							}
+        						}
+        					}
+        					if v.type == "secret" {
+        						secret: {
+        							defaultMode: v.defaultMode
+        							secretName:  v.secretName
+        							if v.items != _|_ {
+        								items: v.items
+        							}
+        						}
+        					}
+        					if v.type == "emptyDir" {
+        						emptyDir: {
+        							medium: v.medium
+        						}
+        					}
+        				}}]
         		}
+        
         	}
         }
+        }
+        
         parameter: {
         	// +usage=Specify number of tasks to run in parallel
         	// +short=c
@@ -47,5 +114,109 @@ spec:
         
         	// +usage=Commands to run in the container
         	cmd?: [...string]
+        
+        	// +usage=Define arguments by using environment variables
+        	env?: [...{
+        		// +usage=Environment variable name
+        		name: string
+        		// +usage=The value of the environment variable
+        		value?: string
+        		// +usage=Specifies a source the value of this var should come from
+        		valueFrom?: {
+        			// +usage=Selects a key of a secret in the pod's namespace
+        			secretKeyRef: {
+        				// +usage=The name of the secret in the pod's namespace to select from
+        				name: string
+        				// +usage=The key of the secret to select from. Must be a valid secret key
+        				key: string
+        			}
+        		}
+        	}]
+        
+        	// +usage=Number of CPU units for the service, like `0.5` (0.5 CPU core), `1` (1 CPU core)
+        	cpu?: string
+        
+        	// +usage=Specifies the attributes of the memory resource required for the container.
+        	memory?: string
+        
+        	// +usage=Declare volumes and volumeMounts
+        	volumes?: [...{
+        		name:      string
+        		mountPath: string
+        		// +usage=Specify volume type, options: "pvc","configMap","secret","emptyDir"
+        		type: "pvc" | "configMap" | "secret" | "emptyDir"
+        		if type == "pvc" {
+        			claimName: string
+        		}
+        		if type == "configMap" {
+        			defaultMode: *420 | int
+        			cmName:      string
+        			items?: [...{
+        				key:  string
+        				path: string
+        				mode: *511 | int
+        			}]
+        		}
+        		if type == "secret" {
+        			defaultMode: *420 | int
+        			secretName:  string
+        			items?: [...{
+        				key:  string
+        				path: string
+        				mode: *511 | int
+        			}]
+        		}
+        		if type == "emptyDir" {
+        			medium: *"" | "Memory"
+        		}
+        	}]
+        
+        	// +usage=Instructions for assessing whether the container is alive.
+        	livenessProbe?: #HealthProbe
+        
+        	// +usage=Instructions for assessing whether the container is in a suitable state to serve traffic.
+        	readinessProbe?: #HealthProbe
+        }
+        
+        #HealthProbe: {
+        
+        	// +usage=Instructions for assessing container health by executing a command. Either this attribute or the httpGet attribute or the tcpSocket attribute MUST be specified. This attribute is mutually exclusive with both the httpGet attribute and the tcpSocket attribute.
+        	exec?: {
+        		// +usage=A command to be executed inside the container to assess its health. Each space delimited token of the command is a separate array element. Commands exiting 0 are considered to be successful probes, whilst all other exit codes are considered failures.
+        		command: [...string]
+        	}
+        
+        	// +usage=Instructions for assessing container health by executing an HTTP GET request. Either this attribute or the exec attribute or the tcpSocket attribute MUST be specified. This attribute is mutually exclusive with both the exec attribute and the tcpSocket attribute.
+        	httpGet?: {
+        		// +usage=The endpoint, relative to the port, to which the HTTP GET request should be directed.
+        		path: string
+        		// +usage=The TCP socket within the container to which the HTTP GET request should be directed.
+        		port: int
+        		httpHeaders?: [...{
+        			name:  string
+        			value: string
+        		}]
+        	}
+        
+        	// +usage=Instructions for assessing container health by probing a TCP socket. Either this attribute or the exec attribute or the httpGet attribute MUST be specified. This attribute is mutually exclusive with both the exec attribute and the httpGet attribute.
+        	tcpSocket?: {
+        		// +usage=The TCP socket within the container that should be probed to assess container health.
+        		port: int
+        	}
+        
+        	// +usage=Number of seconds after the container is started before the first probe is initiated.
+        	initialDelaySeconds: *0 | int
+        
+        	// +usage=How often, in seconds, to execute the probe.
+        	periodSeconds: *10 | int
+        
+        	// +usage=Number of seconds after which the probe times out.
+        	timeoutSeconds: *1 | int
+        
+        	// +usage=Minimum consecutive successes for the probe to be considered successful after having failed.
+        	successThreshold: *1 | int
+        
+        	// +usage=Number of consecutive failures required to determine the container is not alive (liveness probe) or not ready (readiness probe).
+        	failureThreshold: *3 | int
         }
         

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

@@ -37,6 +37,9 @@ spec:
         				containers: [{
         					name:  context.name
         					image: parameter.image
+        					ports: [{
+        						containerPort: parameter.port
+        					}]
         
         					if parameter["cmd"] != _|_ {
         						command: parameter.cmd
@@ -50,10 +53,6 @@ spec:
         						env: context.config
         					}
         
-        					ports: [{
-        						containerPort: parameter.port
-        					}]
-        
         					if parameter["cpu"] != _|_ {
         						resources: {
         							limits:
@@ -63,6 +62,15 @@ spec:
         						}
         					}
         
+        					if parameter["memory"] != _|_ {
+        						resources: {
+        							limits:
+        								memory: parameter.memory
+        							requests:
+        								memory: parameter.memory
+        						}
+        					}
+        
         					if parameter["volumes"] != _|_ {
         						volumeMounts: [ for v in parameter.volumes {
         							{
@@ -70,6 +78,15 @@ spec:
         								name:      v.name
         							}}]
         					}
+        
+        					if parameter["livenessProbe"] != _|_ {
+        						livenessProbe: parameter.livenessProbe
+        					}
+        
+        					if parameter["readinessProbe"] != _|_ {
+        						readinessProbe: parameter.readinessProbe
+        					}
+        
         				}]
         
         			if parameter["volumes"] != _|_ {
@@ -107,20 +124,25 @@ spec:
         					}}]
         			}
         		}
-        		}
         	}
         }
+        }
         parameter: {
         	// +usage=Which image would you like to use for your service
         	// +short=i
         	image: string
         
-        	// +usage=Commands to run in the container
-        	cmd?: [...string]
-        
         	// +usage=Which port do you want customer traffic sent to
         	// +short=p
         	port: *80 | int
+        
+        	// +ignore
+        	// +usage=If addRevisionLabel is true, the appRevision label will be added to the underlying pods
+        	addRevisionLabel: *false | bool
+        
+        	// +usage=Commands to run in the container
+        	cmd?: [...string]
+        
         	// +usage=Define arguments by using environment variables
         	env?: [...{
         		// +usage=Environment variable name
@@ -138,11 +160,12 @@ spec:
         			}
         		}
         	}]
+        
         	// +usage=Number of CPU units for the service, like `0.5` (0.5 CPU core), `1` (1 CPU core)
         	cpu?: string
         
-        	// If addRevisionLabel is true, the appRevision label will be added to the underlying pods 
-        	addRevisionLabel: *false | bool
+        	// +usage=Specifies the attributes of the memory resource required for the container.
+        	memory?: string
         
         	// +usage=Declare volumes and volumeMounts
         	volumes?: [...{
@@ -175,5 +198,53 @@ spec:
         			medium: *"" | "Memory"
         		}
         	}]
+        
+        	// +usage=Instructions for assessing whether the container is alive.
+        	livenessProbe?: #HealthProbe
+        
+        	// +usage=Instructions for assessing whether the container is in a suitable state to serve traffic.
+        	readinessProbe?: #HealthProbe
+        }
+        
+        #HealthProbe: {
+        
+        	// +usage=Instructions for assessing container health by executing a command. Either this attribute or the httpGet attribute or the tcpSocket attribute MUST be specified. This attribute is mutually exclusive with both the httpGet attribute and the tcpSocket attribute.
+        	exec?: {
+        		// +usage=A command to be executed inside the container to assess its health. Each space delimited token of the command is a separate array element. Commands exiting 0 are considered to be successful probes, whilst all other exit codes are considered failures.
+        		command: [...string]
+        	}
+        
+        	// +usage=Instructions for assessing container health by executing an HTTP GET request. Either this attribute or the exec attribute or the tcpSocket attribute MUST be specified. This attribute is mutually exclusive with both the exec attribute and the tcpSocket attribute.
+        	httpGet?: {
+        		// +usage=The endpoint, relative to the port, to which the HTTP GET request should be directed.
+        		path: string
+        		// +usage=The TCP socket within the container to which the HTTP GET request should be directed.
+        		port: int
+        		httpHeaders?: [...{
+        			name:  string
+        			value: string
+        		}]
+        	}
+        
+        	// +usage=Instructions for assessing container health by probing a TCP socket. Either this attribute or the exec attribute or the httpGet attribute MUST be specified. This attribute is mutually exclusive with both the exec attribute and the httpGet attribute.
+        	tcpSocket?: {
+        		// +usage=The TCP socket within the container that should be probed to assess container health.
+        		port: int
+        	}
+        
+        	// +usage=Number of seconds after the container is started before the first probe is initiated.
+        	initialDelaySeconds: *0 | int
+        
+        	// +usage=How often, in seconds, to execute the probe.
+        	periodSeconds: *10 | int
+        
+        	// +usage=Number of seconds after which the probe times out.
+        	timeoutSeconds: *1 | int
+        
+        	// +usage=Minimum consecutive successes for the probe to be considered successful after having failed.
+        	successThreshold: *1 | int
+        
+        	// +usage=Number of consecutive failures required to determine the container is not alive (liveness probe) or not ready (readiness probe).
+        	failureThreshold: *3 | int
         }
         

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

@@ -36,6 +36,28 @@ spec:
         						command: parameter.cmd
         					}
         
+        					if parameter["env"] != _|_ {
+        						env: parameter.env
+        					}
+        
+        					if parameter["cpu"] != _|_ {
+        						resources: {
+        							limits:
+        								cpu: parameter.cpu
+        							requests:
+        								cpu: parameter.cpu
+        						}
+        					}
+        
+        					if parameter["memory"] != _|_ {
+        						resources: {
+        							limits:
+        								memory: parameter.memory
+        							requests:
+        								memory: parameter.memory
+        						}
+        					}
+        
         					if parameter["volumes"] != _|_ {
         						volumeMounts: [ for v in parameter.volumes {
         							{
@@ -43,53 +65,88 @@ spec:
         								name:      v.name
         							}}]
         					}
+        
+        					if parameter["livenessProbe"] != _|_ {
+        						livenessProbe: parameter.livenessProbe
+        					}
+        
+        					if parameter["readinessProbe"] != _|_ {
+        						readinessProbe: parameter.readinessProbe
+        					}
+        
         				}]
         
-        				if parameter["volumes"] != _|_ {
-        					volumes: [ for v in parameter.volumes {
-        						{
-        							name: v.name
-        							if v.type == "pvc" {
-        								persistentVolumeClaim: {
-        									claimName: v.claimName
+        			if parameter["volumes"] != _|_ {
+        				volumes: [ for v in parameter.volumes {
+        					{
+        						name: v.name
+        						if v.type == "pvc" {
+        							persistentVolumeClaim: {
+        								claimName: v.claimName
+        							}
+        						}
+        						if v.type == "configMap" {
+        							configMap: {
+        								defaultMode: v.defaultMode
+        								name:        v.cmName
+        								if v.items != _|_ {
+        									items: v.items
         								}
         							}
-        							if v.type == "configMap" {
-        								configMap: {
-        									defaultMode: v.defaultMode
-        									name:        v.cmName
-        									if v.items != _|_ {
-        										items: v.items
-        									}
+        						}
+        						if v.type == "secret" {
+        							secret: {
+        								defaultMode: v.defaultMode
+        								secretName:  v.secretName
+        								if v.items != _|_ {
+        									items: v.items
         								}
         							}
-        							if v.type == "secret" {
-        								secret: {
-        									defaultMode: v.defaultMode
-        									secretName:  v.secretName
-        									if v.items != _|_ {
-        										items: v.items
-        									}
-        								}
+        						}
+        						if v.type == "emptyDir" {
+        							emptyDir: {
+        								medium: v.medium
         							}
-        							if v.type == "emptyDir" {
-        								emptyDir: {
-        									medium: v.medium
-        								}
-        							}
-        						}}]
-        				}
+        						}
+        					}}]
         			}
         		}
         	}
         }
+        }
         
         parameter: {
         	// +usage=Which image would you like to use for your service
         	// +short=i
         	image: string
+        
         	// +usage=Commands to run in the container
         	cmd?: [...string]
+        
+        	// +usage=Define arguments by using environment variables
+        	env?: [...{
+        		// +usage=Environment variable name
+        		name: string
+        		// +usage=The value of the environment variable
+        		value?: string
+        		// +usage=Specifies a source the value of this var should come from
+        		valueFrom?: {
+        			// +usage=Selects a key of a secret in the pod's namespace
+        			secretKeyRef: {
+        				// +usage=The name of the secret in the pod's namespace to select from
+        				name: string
+        				// +usage=The key of the secret to select from. Must be a valid secret key
+        				key: string
+        			}
+        		}
+        	}]
+        
+        	// +usage=Number of CPU units for the service, like `0.5` (0.5 CPU core), `1` (1 CPU core)
+        	cpu?: string
+        
+        	// +usage=Specifies the attributes of the memory resource required for the container.
+        	memory?: string
+        
         	// +usage=Declare volumes and volumeMounts
         	volumes?: [...{
         		name:      string
@@ -121,5 +178,53 @@ spec:
         			medium: *"" | "Memory"
         		}
         	}]
+        
+        	// +usage=Instructions for assessing whether the container is alive.
+        	livenessProbe?: #HealthProbe
+        
+        	// +usage=Instructions for assessing whether the container is in a suitable state to serve traffic.
+        	readinessProbe?: #HealthProbe
+        }
+        
+        #HealthProbe: {
+        
+        	// +usage=Instructions for assessing container health by executing a command. Either this attribute or the httpGet attribute or the tcpSocket attribute MUST be specified. This attribute is mutually exclusive with both the httpGet attribute and the tcpSocket attribute.
+        	exec?: {
+        		// +usage=A command to be executed inside the container to assess its health. Each space delimited token of the command is a separate array element. Commands exiting 0 are considered to be successful probes, whilst all other exit codes are considered failures.
+        		command: [...string]
+        	}
+        
+        	// +usage=Instructions for assessing container health by executing an HTTP GET request. Either this attribute or the exec attribute or the tcpSocket attribute MUST be specified. This attribute is mutually exclusive with both the exec attribute and the tcpSocket attribute.
+        	httpGet?: {
+        		// +usage=The endpoint, relative to the port, to which the HTTP GET request should be directed.
+        		path: string
+        		// +usage=The TCP socket within the container to which the HTTP GET request should be directed.
+        		port: int
+        		httpHeaders?: [...{
+        			name:  string
+        			value: string
+        		}]
+        	}
+        
+        	// +usage=Instructions for assessing container health by probing a TCP socket. Either this attribute or the exec attribute or the httpGet attribute MUST be specified. This attribute is mutually exclusive with both the exec attribute and the httpGet attribute.
+        	tcpSocket?: {
+        		// +usage=The TCP socket within the container that should be probed to assess container health.
+        		port: int
+        	}
+        
+        	// +usage=Number of seconds after the container is started before the first probe is initiated.
+        	initialDelaySeconds: *0 | int
+        
+        	// +usage=How often, in seconds, to execute the probe.
+        	periodSeconds: *10 | int
+        
+        	// +usage=Number of seconds after which the probe times out.
+        	timeoutSeconds: *1 | int
+        
+        	// +usage=Minimum consecutive successes for the probe to be considered successful after having failed.
+        	successThreshold: *1 | int
+        
+        	// +usage=Number of consecutive failures required to determine the container is not alive (liveness probe) or not ready (readiness probe).
+        	failureThreshold: *3 | int
         }
         

charts/vela-core/templates/kubevela-controller.yaml

@@ -177,4 +177,4 @@ spec:
       {{- with .Values.tolerations }}
       tolerations:
     {{- toYaml . | nindent 8 }}
-  {{- end }}
+  {{- end }}

charts/vela-core/values.yaml

@@ -78,6 +78,8 @@ admissionWebhooks:
   certManager:
     enabled: false
 
+#Enable debug logs for development purpose
+logDebug: false
 
 #If non-empty, write log files in this path
 logFilePath: ""

cmd/core/main.go

@@ -36,7 +36,7 @@ import (
 	oamcontroller "github.com/oam-dev/kubevela/pkg/controller/core.oam.dev"
 	oamv1alpha2 "github.com/oam-dev/kubevela/pkg/controller/core.oam.dev/v1alpha2"
 	"github.com/oam-dev/kubevela/pkg/controller/utils"
-	"github.com/oam-dev/kubevela/pkg/dsl/definition"
+	"github.com/oam-dev/kubevela/pkg/cue/packages"
 	"github.com/oam-dev/kubevela/pkg/oam"
 	"github.com/oam-dev/kubevela/pkg/oam/discoverymapper"
 	"github.com/oam-dev/kubevela/pkg/utils/common"
@@ -172,10 +172,10 @@ func main() {
 		os.Exit(1)
 	}
 	controllerArgs.DiscoveryMapper = dm
-	pd, err := definition.NewPackageDiscover(mgr.GetConfig())
+	pd, err := packages.NewPackageDiscover(mgr.GetConfig())
 	if err != nil {
 		klog.Error(err, "Failed to create CRD discovery for CUE package client")
-		if !definition.IsCUEParseErr(err) {
+		if !packages.IsCUEParseErr(err) {
 			os.Exit(1)
 		}
 	}

design/api/vela-plugin-registry-reference.md

@@ -0,0 +1,33 @@
+# KubeVela Plugin Registry Reference
+
+## registry interface intro
+
+`Registry` interface definitions have two methods: `GetCap` and `ListCaps`. Here "Cap" can represent trait or component definition
+
+```go
+// Registry define a registry stores trait & component defs
+type Registry interface {
+	GetCap(addonName string) (types.Capability, []byte, error)
+	ListCaps() ([]types.Capability, error)
+}
+```
+
+Now we have implemented:`GithubRegistry`, `LocalRegistry` and `OssRegistry`, which represent three types of registry source. 
+
+To create a `Registry` object you should and must call `NewRegistry()`. 
+
+### Helper type or function
+
+You could use `RegistryFile` to convert `[]byte` (easily got from all kinds of source) to `Capability`. Here is `RegistryFile`'s definition.
+
+```go
+// RegistryFile describes a file item in registry
+type RegistryFile struct {
+	data []byte // file content
+	name string // file's name
+}
+```
+
+## Registry vs Capcenter
+
+How they differ from each other? `Capcenter` is a type for vela CLI. It has some function to sync content from remote and local `~/.vela` directory and apply some `ComponentDefinition` or `TraitDefinition` to the cluster. In the contrast, `Registry` is a type for kubectl vela plugin, which focuses on cluster directly. In one word, `Registry` has no local operations. They share some basic function.

design/vela-core/workflow_policy.md

@@ -0,0 +1,345 @@
+# Application-Level Policies and Customized Control-Logic Workflow Design
+
+## Background
+
+The current model consists of mainly Components and Traits. While this enables the Application object to plug-in operational capabilities, it is still no flexible enough. Specifically, it has the following limitations:
+
+- The current control logic could not be customized. Once the Vela controller renders final k8s resources, it simply applies them without any extension points. In some scenarios, users want to do more complex operations like:
+  - Blue-green upgrade old-new app revisions.
+  - User interaction like manual approval/rollback.
+  - Distributing workloads across multiple clusters.
+  - Enforcing policies and auditting.
+  - Pushing finalized k8s resources to Git for GitOps (via Flux/Argo) without applying the resources in Vela.
+- There is no application-level config, but only per-component config. In some scenarios, users want to have app-level policies like:
+  - Security: RBAC rules, audit settings, secret backend types.
+  - Insights: app delivery lead time, frequence, MTTR.
+
+## Proposal
+
+To resolve the aforementioned problems, we propose to add app-level policies and customizable workflow to Application API:
+
+```yaml
+kind: Application
+spec:
+  componnets: ...
+
+  # Policies are rendered after components are rendered but before workflow are started
+  policies:
+    - type: security
+      properties:
+        rbac: ...
+        audit: enabled
+        secretBackend: vault
+
+    - type: deployment-insights
+      properties:
+        leadTime: enabled
+        frequency: enabled
+        mttr: enabled
+
+  # workflow is used to customize the control logic.
+  # If workflow is specified, Vela won't apply any resource, but provide rendered resources in a ConfigMap, referenced via AppRevision.
+  # workflow steps are executed in array order, and each step:
+  # - will have a context in annotation.
+  # - should mark "finish" phase in status.conditions.
+  workflow:
+  
+    # blue-green rollout
+    - type: blue-green-rollout
+      stage: post-render # stage could be pre/post-render. Default is post-render.
+      properties:
+        partition: "50%"
+
+    # traffic shift
+    - type: traffic-shift
+      properties:
+        partition: "50%"
+
+    # promote/rollback
+    - type: rollout-promotion
+      propertie:
+        manualApproval: true
+        rollbackIfNotApproved: true
+```
+
+This also implicates we will add two Definition CRDs -- `PolicyDefinition` and `WorkflowStepDefinition`:
+
+```yaml
+apiVersion: core.oam.dev/v1beta1
+kind: WorkflowStepDefinition
+metadata:
+  name: gitops
+spec:
+  schematic:
+    cue:
+      template: |
+        output: {
+          kind: GitOps
+          spec:
+            source:
+              repoURL: parameter.source
+              branch: parameter.branch
+            ...
+        }
+        parameters: {
+          source: string
+          branch: string
+        }
+
+---
+apiVersion: core.oam.dev/v1beta1
+kind: PolicyDefinition
+spec:
+  schematic:
+    cue:
+      template: ...
+```
+
+## Technical Details
+
+To support policies and workflow, the application controller will be modified as the following:
+
+- Before rendering the components, the controller will first execute the `stage: pre-render` steps.
+- App controller will put rendered resources (including Components, Traits, Policies) into a ConfigMap, and reference the ConfigMap name in AppRevision as below:
+
+  ```yaml
+  kind: ApplicationRevision
+  spec:
+    ...
+    resourcesConfigMap:
+      name: my-app-v1-resources
+  ---
+
+  kind: ConfigMap
+  metadata:
+    name: my-app-v1-resources
+  data: 
+    resources: |
+      {
+        "apiVersion": "apps/v1",
+        "kind": "Deployment",
+        "metadata": {
+            "name": "mysvc"
+        },
+        "spec": {
+            "replicas": 1
+        }
+      }
+      ...more json-marshalled resources...
+  ```
+- If workflow is specified, the controller will then apply the ApplicationRevision, but skip applying ApplicationContext. In this way, the resources won't be applied by Vela controller.
+- The controller will then reconcile the workflow step by step. Each workflow step will be recorded in the Application.status:
+  ```yaml
+  kind: Application
+  status:
+    workflow:
+    - type: rollout-promotion
+      phase: running # succeeded | failed | stopped
+      resourceRef:
+        kind: Rollout
+        name: ...
+  ```
+- Note that each workflow step must be idempotent, which means it should be able to process an object that are already submitted and processed. A non-idempotent example would be a controller that keeps appending item to an array field.
+
+Each workflow step has the following interactions with the app controller:
+- The controller will apply the workflow object with annotation `app.oam.dev/workflow-context`. This annotation will pass in the context marshalled in json defined as the following:
+  ```go
+  type WorkflowContext struct {
+    AppName string
+    AppRevisionName string
+    WorkflowIndex int
+  }
+  ```
+- The controller will wait for the workflow object's `status.conditions` to have this condition:
+
+  ```yaml
+  conditions:
+    - type: workflow-progress
+      status: 'True'
+      reason: 'Succeeded'
+      message: '{"observedGeneration":1}'
+  ```
+
+  The reason could be one of the following:
+  - `Succeeded`: This will make the controller run the next step. The observed generation number should be written in `message` since Vela will check it to detect the newer decision on spec change.
+  - `Stopped`: This will make the controller stop the workflow.
+  - `Failed`: This will make the controller stop the workflow. The error should be reported in `message`.
+
+## Use Cases
+
+In this section we will walk through how we implement workflow solutions for the following use cases.
+
+### Case 1: Multi-cluster
+
+In this case, users want to distribute workflow to multiple clusters. The dispatcher implementation is flexible and could be based on [open-cluster-management](https://open-cluster-management.io/) or other methods.
+
+```yaml
+workflow:
+  - type: open-cluster-management
+    properties:
+      placement:
+        - clusterSelector:
+            region: east
+          replicas: "70%"
+        - clusterSelector:
+            region: west
+          replicas: "20%"
+```
+
+The process goes as:
+
+- During infra setup, the Cluster objects are applied and agents are setup in each cluster to manage lifecycle of k8s clusters.
+- Once the Application is applied, the OCM controller can retrieve all rendered resources from AppRevision. It will apply a ManifestWork object including all resources. Then the OCM agent will execute the workload creation in each cluster.
+
+### Case 2: Blue-green rollout
+
+In this case, users want to rollout a new version of the application components in a blue-green rolling upgrade style.
+
+```yaml
+workflow:
+  # blue-green rollout
+  - type: blue-green-rollout
+    properties:
+      partition: "50%"
+
+  # traffic shift
+  - type: traffic-shift
+    properties:
+      partition: "50%"
+
+  # promote/rollback
+  - type: rollout-promotion
+    propertie:
+      manualApproval: true
+      rollbackIfNotApproved: true
+```
+
+The process goes as:
+
+- By default, each modification of the Application object will generate an AppRevision object. The rollout controller will get the current revision from the context and retrieve the previous revision via kube API.
+- Then the rollout controller will do the operation to rollings replicas between two revisions (the actual behavior depends on the workload type, e.g. Deployment or CloneSet).
+- Once the rollover is done, the rollout controller can shift partial traffic to the new revision too.
+- The rollout controller will wait for the manual approval. In this case, it is in the status of Rollout object:
+  ```yaml
+  kind: Rollout
+  status:
+    pause: true # change this to false
+  ```
+
+  The reference to the rollout object will be in the Application object:
+  ```yaml
+  apiVersion: core.oam.dev/v1beta1
+  kind: Application
+  status:
+    workflow:
+    - type: rollout-promotion
+      resourceRef:
+        kind: Rollout
+        name: ...
+  ```
+
+### Case 3: Data Passing
+
+In this case, users want to deploy a database component first, wait the database to be up and ready, and then deploy the application with database connection secret.
+
+```yaml
+components:
+  - name: my-db
+    type: mysql
+    properties:
+
+  - name: my-app
+    type: webservice
+
+
+workflow:
+  - type: apply-component 
+    properties:
+      name: my-db
+
+  # Wait for the MySQL object's status.connSecret to have value.
+  - type: conditional-wait
+    properties:
+      resourceRef:
+        apiVersion: database.example.org/v1alpha1
+        kind: MySQLInstance
+        name: my-db
+      conditions:
+        - field: status.connSecret
+          op: NotEmpty
+
+  # Patch my-app Deployment object's field with the secret name
+  # emitted from MySQL object. And then apply my-app component.
+  - type: apply-component 
+    properties:
+      name: my-app
+      patch:
+        to:
+          field: spec.containers[0].envFrom[0].secretRef.name
+        valueFrom:
+          apiVersion: database.example.org/v1alpha1
+          kind: MySQLInstance
+          name: my-db
+          field: status.connSecret
+
+```
+
+### Case 4: GitOps rollout
+
+In this case, users just want Vela to provide final k8s resources and push them to Git, and then integrate with ArgoCD/Flux to do final rollout. Users will setup a GitOps workflow like below:
+
+```yaml
+workflow:
+- type: gitops # This part configures how to push resources to Git repo
+  properties:
+    gitRepo: git-repo-url
+    branch: branch
+    credentials: ...
+```
+
+The process goes as:
+
+- Everytime an Appliation event is triggered, the GitOps workflow controller will push the rendered resources to a Git repo. This will trigger ArgoCD/Flux to do continuous deployment.
+
+### Case 5: Template-based rollout
+
+In this case, a template for Application object has already been defined. Instead of writing the `spec.components`, users will reference the template and provide parameters/patch to it.
+
+```yaml
+workflow:
+  - type: helm-template
+    stage: pre-render
+    properties:
+      source: git-repo-url
+      path: chart/folder/path
+      parameters:
+        image: my-image
+        replicas: 3
+---
+workflow:
+  - type: kustomize-patch
+    stage: pre-render
+    properties:
+      source: git-repo-url
+      path: base/folder/path
+      patch:
+        spec:
+          components:
+            - name: instance
+              properties:
+                image: prod-image
+```
+
+The process goes as:
+
+- On creating the application, app controller will apply the HelmTemplate/KustomizePatch objects, and wait for its status.
+- The HelmTemplate/KustomizePatch controller would read the template from specified source, render the final config. It will compare the config with the Application object -- if there is difference, it will write back to the Application object per se.
+- The update of Application will trigger another event, the app controller will apply the HelmTemplate/KustomizePatch objects with new context. But this time, the HelmTemplate/KustomizePatch controller will find no diff after the rendering. So it will skip this time.
+
+## Considerations
+
+### Comparison with Argo Workflow/Tekton
+
+The workflow defined here are k8s resource based and very simple one direction workflow. It's mainly used to customize Vela control logic to do more complex deployment operations.
+
+While Argo Workflow/Tekton shares similar idea to provide workflow functionalities, they are container based and provide more complex features like parameters sharing (using volumes and sidecars). More importantly, these projects couldn't satisfy our needs. Otherwise we can just use them in our implementation.

docs/README.md

@@ -54,19 +54,29 @@ When you add or modify the docs, these three files(`docs/en/`, `docs/en/resource
 
 [comment]: <> (TODO: ADD how to translate into Chinese or other language here.)
    
-## Local Development
+## Preview Website
 
-You can preview the website locally with the `node` and `yarn` installed.
-Every time you modify the files under the docs, you need to re-run the following command, it will not sync automatically:
+You can preview the website locally with docker container. Every time you modify the files under the docs or sidebars.js, 
+it will sync automatically:
 
 ```shell
 make docs-start
 ```
 
-## Build in Local
+## Build Website
 
 You can build Kubevela website in local to test the correctness of docs, only run the following cmd:
 
 ```shell
 make docs-build
+```
+
+If you don't want to use docker to preview and build the website, we provide simple scripts in the `hack/website` to help you develop and debug locally.
+
+```
+# preview the website
+bash hack/website/docs-start.sh
+
+# build the website 
+bash hack/website/test-build.sh
 ```

docs/en/advanced-install.mdx

@@ -1,6 +1,8 @@
 ---
 title:  Other Install Topics
 ---
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
 
 ## Install KubeVela with cert-manager
 
@@ -47,7 +49,44 @@ REVISION: 1
 NOTES:
 Welcome to use the KubeVela! Enjoy your shipping application journey!
 ```
+## Install Kubectl Vela Plugin
 
+Install vela kubectl plugin can help you to ship applications more easily!
+
+<Tabs
+className="unique-tabs"
+defaultValue="krew"
+values={[
+{label: 'Krew', value: 'krew'},
+{label: 'Script', value: 'script'},
+]}>
+<TabItem value="krew">
+
+1. [Install and set up](https://krew.sigs.k8s.io/docs/user-guide/setup/install/) Krew on your machine.
+2. Discover plugins available on Krew:
+```shell
+kubectl krew update
+```
+3. install kubectl vela:
+```shell script
+kubectl krew install vela
+```
+
+</TabItem>
+<TabItem value="script">
+
+**macOS/Linux**
+```shell script
+curl -fsSl https://kubevela.io/script/install-kubectl-vela.sh | bash
+```
+
+You can also download the binary from [release pages ( >= v1.0.3)](https://github.com/oam-dev/kubevela/releases) manually.
+Kubectl will discover it from your system path automatically.
+
+</TabItem>
+</Tabs>
+
+For more usage please reference [kubectl plugin](./developers/references/kubectl-plugin).
 ## Upgrade
 
 ### Step 1. Update Helm repo

docs/en/cli/vela_cap_center_config.md

@@ -15,7 +15,7 @@ vela cap center config <centerName> <centerURL> [flags]
 ### Examples
 
 ```
-vela cap center config mycenter https://github.com/oam-dev/catalog/cap-center
+vela cap center config mycenter https://github.com/oam-dev/catalog/tree/master/registry
 ```
 
 ### Options
@@ -35,4 +35,4 @@ vela cap center config mycenter https://github.com/oam-dev/catalog/cap-center
 
 * [vela cap center](vela_cap_center)	 - Manage Capability Center
 
-###### Auto generated by spf13/cobra on 20-Mar-2021
+###### Auto generated by spf13/cobra on 6-May-2021

docs/en/cli/vela_system_cue-packages.md

@@ -30,6 +30,6 @@ vela system cue-packages
 
 ### SEE ALSO
 
-* [vela system](vela_system.md)	 - System management utilities
+* [vela system](vela_system)	 - System management utilities
 
 ###### Auto generated by spf13/cobra on 2-May-2021

docs/en/cli/vela_system_live-diff.md

@@ -34,6 +34,6 @@ vela live-diff -f app-v2.yaml -r app-v1 --context 10
 
 ### SEE ALSO
 
-* [vela system](vela_system.md)	 - System management utilities
+* [vela system](vela_system)	 - System management utilities
 
 ###### Auto generated by spf13/cobra on 2-May-2021

docs/en/concepts.md

@@ -43,5 +43,4 @@ Before releasing an application to production, it's important to test the code i
 
 Here are some recommended next steps:
 
-- Learn KubeVela's [core concepts](./concepts)
 - Learn how to [deploy an application](end-user/application) in detail and understand how it works.

docs/en/developers/cap-center.md

@@ -11,11 +11,16 @@ KubeVela is able to discover OAM definition files in this repo automatically and
 Add and sync a capability center in KubeVela:
 
 ```bash
-$ vela cap center config my-center https://github.com/oam-dev/catalog/tree/master/registry
+vela cap center config my-center https://github.com/oam-dev/catalog/tree/master/registry
+```
+```console
 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
+```
+```bash
+vela cap center sync my-center
+```
+```console
 successfully sync 1/1 from my-center remote center
 sync finished
 ```
@@ -27,7 +32,9 @@ Now, this capability center `my-center` is ready to use.
 You are allowed to add more capability centers and list them.
 
 ```bash
-$ vela cap center ls
+vela cap center ls
+```
+```console
 NAME     	ADDRESS
 my-center	https://github.com/oam-dev/catalog/tree/master/registry
 ```
@@ -37,7 +44,7 @@ my-center	https://github.com/oam-dev/catalog/tree/master/registry
 Or, remove one.
 
 ```bash
-$ vela cap center remove my-center
+vela cap center remove my-center
 ```
 
 ## List all available capabilities in capability center
@@ -45,7 +52,9 @@ $ vela cap center remove my-center
 Or, list all available capabilities in certain center.
 
 ```bash
-$ vela cap ls my-center
+vela cap ls my-center
+```
+```console
 NAME               	CENTER   	TYPE               	DEFINITION                    	STATUS     	APPLIES-TO
 clonesetservice    	my-center	componentDefinition	clonesets.apps.kruise.io      	uninstalled	[]
 ```
@@ -63,7 +72,9 @@ helm install kruise https://github.com/openkruise/kruise/releases/download/v0.7.
 Install `clonesetservice` component from `my-center`.
 
 ```bash
-$ vela cap install my-center/clonesetservice
+vela cap install my-center/clonesetservice
+```
+```console
 Installing component capability clonesetservice
 Successfully installed capability clonesetservice from my-center
 ```
@@ -73,7 +84,9 @@ Successfully installed capability clonesetservice from my-center
 Let's check the `clonesetservice` appears in your platform firstly:
 
 ```bash
-$ vela components
+vela components
+```
+```console
 NAME           	NAMESPACE  	WORKLOAD                	DESCRIPTION
 clonesetservice	vela-system	clonesets.apps.kruise.io	Describes long-running, scalable, containerized services
                	           	                        	that have a stable network endpoint to receive external
@@ -85,7 +98,7 @@ clonesetservice	vela-system	clonesets.apps.kruise.io	Describes long-running, sca
 Great! Now let's deploy an app via Appfile.
 
 ```bash
-$ cat << EOF > vela.yaml
+cat << EOF > vela.yaml
 name: testapp
 services:
   testsvc:
@@ -96,7 +109,9 @@ EOF
 ```
 
 ```bash
-$ vela up
+vela up
+```
+```console
 Parsing vela appfile ...
 Load Template ...
 
@@ -118,7 +133,9 @@ Updating:  core.oam.dev/v1alpha2, Kind=HealthScope in default
 then you can Get a cloneset in your environment.
 
 ```shell
-$ kubectl get clonesets.apps.kruise.io
+kubectl get clonesets.apps.kruise.io
+```
+```console
 NAME      DESIRED   UPDATED   UPDATED_READY   READY   TOTAL   AGE
 testsvc   1         1         1               1       1       46s
 ```
@@ -128,6 +145,8 @@ testsvc   1         1         1               1       1       46s
 > NOTE: make sure no apps are using the capability before uninstalling.
 
 ```bash
-$ vela cap uninstall my-center/clonesetservice
+vela cap uninstall my-center/clonesetservice
+```
+```console
 Successfully uninstalled capability clonesetservice
 ```

docs/en/developers/check-logs.md

@@ -3,7 +3,7 @@ title:  Check Application Logs
 ---
 
 ```bash
-$ vela logs testapp
+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/en/developers/config-app.md

@@ -7,7 +7,9 @@ title:  Configuring data/env in Application
 ## `vela config set`
 
 ```bash
-$ vela config set test a=b c=d
+vela config set test a=b c=d
+```
+```console
 reading existing config data and merging with user input
 config data saved successfully ✅
 ```
@@ -15,7 +17,9 @@ config data saved successfully ✅
 ## `vela config get`
 
 ```bash
-$ vela config get test
+vela config get test
+```
+```console
 Data:
   a: b
   c: d
@@ -24,16 +28,20 @@ Data:
 ## `vela config del`
 
 ```bash
-$ vela config del test
+vela config del test
+```
+```console
 config (test) deleted successfully
 ```
 
 ## `vela config ls`
 
 ```bash
-$ vela config set test a=b
-$ vela config set test2 c=d
-$ vela config ls
+vela config set test a=b
+vela config set test2 c=d
+vela config ls
+```
+```console
 NAME
 test
 test2
@@ -44,7 +52,7 @@ test2
 The config data can be set as the env in applications.
 
 ```bash
-$ vela config set demo DEMO_HELLO=helloworld
+vela config set demo DEMO_HELLO=helloworld
 ```
 
 Save the following to `vela.yaml` in current directory:
@@ -59,7 +67,9 @@ services:
 
 Then run:
 ```bash
-$ vela up
+vela up
+```
+```console
 Parsing vela.yaml ...
 Loading templates ...
 
@@ -80,6 +90,8 @@ App has not been deployed, creating a new deployment...
 Check env var:
 
 ```
-$ vela exec testapp -- printenv | grep DEMO_HELLO
+vela exec testapp -- printenv | grep DEMO_HELLO
+```
+```console
 DEMO_HELLO=helloworld
 ```

docs/en/developers/config-enviroments.md

@@ -8,14 +8,18 @@ A typical set of deployment environment is `test`, `staging`, `prod`, etc.
 ## Create environment
 
 ```bash
-$ vela env init demo --email my@email.com
+vela env init demo --email my@email.com
+```
+```console
 environment demo created, Namespace: default, Email: my@email.com
 ```
 
 ## Check the deployment environment metadata
 
 ```bash
-$ vela env ls
+vela env ls
+```
+```console
 NAME   	CURRENT	NAMESPACE	EMAIL                	DOMAIN
 default	       	default  	
 demo   	*      	default  	my@email.com
@@ -28,12 +32,16 @@ By default, the environment will use `default` namespace in K8s.
 You could change the config by executing the environment again.
 
 ```bash
-$ vela env init demo --namespace demo
+vela env init demo --namespace demo
+```
+```console
 environment demo created, Namespace: demo, Email: my@email.com
 ```
 
 ```bash
-$ vela env ls
+vela env ls
+```
+```console
 NAME   	CURRENT	NAMESPACE	EMAIL                	DOMAIN
 default	       	default  	
 demo   	*      	demo     	my@email.com
@@ -50,7 +58,9 @@ your app by this domain with an mTLS supported automatically.
 For example, you could get the public IP from ingress service.  
 
 ```bash
-$ kubectl get svc -A | grep LoadBalancer
+kubectl get svc -A | grep LoadBalancer
+```
+```console
 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
 ```
@@ -66,7 +76,9 @@ You could also use `123.57.10.233.xip.io` as your domain, if you don't have a cu
 
 
 ```bash
-$ vela env init demo --domain 123.57.10.233.xip.io
+vela env init demo --domain 123.57.10.233.xip.io
+```
+```console
 environment demo updated, Namespace: demo, Email: my@email.com
 ```
 
@@ -87,7 +99,9 @@ servcies:
 ```
 
 ```
-$ curl http://123.57.10.233.xip.io/testapp
+curl http://123.57.10.233.xip.io/testapp
+```
+```console
 Hello World
 ```
 

docs/en/developers/exec-cmd.md

@@ -4,7 +4,7 @@ title:  Execute Commands in Container
 
 Run: 
 ```
-$ vela exec testapp -- /bin/sh
+vela exec testapp -- /bin/sh
 ```
 
 This open a shell within the container of testapp.

docs/en/developers/learn-appfile.md

@@ -88,8 +88,8 @@ In the following workflow, we will build and deploy an example NodeJS app under
 git clone and go to the testapp directory:
 
 ```bash
-$ git clone https://github.com/oam-dev/kubevela.git
-$ cd kubevela/docs/examples/testapp
+git clone https://github.com/oam-dev/kubevela.git
+cd kubevela/docs/examples/testapp
 ```
 
 The example contains NodeJS app code, Dockerfile to build the app.
@@ -108,7 +108,9 @@ We are going to use it to build and deploy the app.
 Run the following command:
 
 ```bash
-$ vela up
+vela up
+```
+```console
 Parsing vela.yaml ...
 Loading templates ...
 
@@ -139,7 +141,9 @@ App has not been deployed, creating a new deployment...
 Check the status of the service:
 
 ```bash
-$ vela status testapp
+vela status testapp
+```
+```console
   About:
   
     Name:       testapp
@@ -179,7 +183,7 @@ Add local option to `build`:
 Then deploy the app to kind:
 
 ```bash
-$ vela up
+vela up
 ```
 
 <details><summary>(Advanced) Check rendered manifests</summary>
@@ -237,7 +241,7 @@ services:
 Then deploy Appfile again to update the application:
 
 ```bash
-$ vela up
+vela up
 ```
 
 Congratulations! You have just deployed an app using `Appfile`.

docs/en/developers/port-forward.md

@@ -5,7 +5,9 @@ title:  Port Forwarding
 Once your web services of the application deployed, you can access it locally via `port-forward`. 
 
 ```bash
-$ vela ls
+vela ls
+```
+```console
 NAME  	        APP  	WORKLOAD  	  TRAITS	STATUS 	    CREATED-TIME
 express-server	testapp	webservice	      	    Deployed	2020-09-18 22:42:04 +0800 CST
 ```
@@ -13,11 +15,13 @@ express-server	testapp	webservice	      	    Deployed	2020-09-18 22:42:04 +0800
 It will directly open browser for you.
 
 ```bash
-$ vela port-forward testapp
+vela port-forward testapp
+```
+```console
 Forwarding from 127.0.0.1:8080 -> 80
 Forwarding from [::1]:8080 -> 80
 
 Forward successfully! Opening browser ...
 Handling connection for 8080
 Handling connection for 8080
-```
+```

docs/en/developers/references/devex/faq.md

@@ -30,7 +30,9 @@ Also, KubeVela is by design a Kubernetes controller (i.e. works on server side),
 Occasionally you might hit the issue as below. It happens when the last KubeVela release deletion hasn't completed.
 
 ```
-$ vela install
+vela install
+```
+```console
 - Installing Vela Core Chart:
 install chart vela-core, version 0.1.0, desc : A Helm chart for Kube Vela core, contains 35 file
 Failed to install the chart with error: serviceaccounts "cert-manager-cainjector" is forbidden: unable to create new content in namespace cert-manager because it is being terminated
@@ -44,7 +46,9 @@ Error: failed to create resource: serviceaccounts "cert-manager-cainjector" is f
 Take a break and try again in a few seconds.
 
 ```
-$ vela install
+vela install
+```
+```console
 - Installing Vela Core Chart:
 Vela system along with OAM runtime already exist.
 Automatically discover capabilities successfully ✅ Add(0) Update(0) Delete(8)
@@ -65,7 +69,9 @@ TYPE       	CATEGORY	DESCRIPTION
 And manually apply all WorkloadDefinition and TraitDefinition manifests to have all capabilities back.
 
 ```
-$ kubectl apply -f charts/vela-core/templates/defwithtemplate
+kubectl apply -f charts/vela-core/templates/defwithtemplate
+```
+```console
 traitdefinition.core.oam.dev/autoscale created
 traitdefinition.core.oam.dev/scaler created
 traitdefinition.core.oam.dev/metrics created
@@ -74,8 +80,11 @@ traitdefinition.core.oam.dev/route created
 workloaddefinition.core.oam.dev/task created
 workloaddefinition.core.oam.dev/webservice created
 workloaddefinition.core.oam.dev/worker created
-
-$ vela workloads
+```
+```
+vela workloads
+```
+```console
 Automatically discover capabilities successfully ✅ Add(8) Update(0) Delete(0)
 
 TYPE       	CATEGORY	DESCRIPTION
@@ -99,7 +108,9 @@ worker    	Long-running scalable backend worker without network endpoint
 Occasionally you might hit the issue as below. It happens when there is an old OAM Kubernetes Runtime release, or you applied `ScopeDefinition` before.
 
 ```
-$ vela install
+vela install
+```
+```console
   - Installing Vela Core Chart:
   install chart vela-core, version 0.1.0, desc : A Helm chart for Kube Vela core, contains 35 file
   Failed to install the chart with error: ScopeDefinition "healthscopes.core.oam.dev" in namespace "" exists and cannot be imported into the current release: invalid ownership metadata; annotation validation error: key "meta.helm.sh/release-name" must equal "kubevela": current value is "oam"; annotation validation error: key "meta.helm.sh/release-namespace" must equal "vela-system": current value is "oam-system"
@@ -113,10 +124,15 @@ $ vela install
 Delete `ScopeDefinition` "healthscopes.core.oam.dev" and try again.
 
 ```
-$ kubectl delete ScopeDefinition "healthscopes.core.oam.dev"
+kubectl delete ScopeDefinition "healthscopes.core.oam.dev"
+```
+```console
 scopedefinition.core.oam.dev "healthscopes.core.oam.dev" deleted
-
-$ vela install
+```
+```
+vela install
+```
+```console
 - Installing Vela Core Chart:
 install chart vela-core, version 0.1.0, desc : A Helm chart for Kube Vela core, contains 35 file
 Successfully installed the chart, status: deployed, last deployed time = 2020-12-03 16:26:41.491426 +0800 CST m=+4.026069452
@@ -141,7 +157,9 @@ TYPE       	CATEGORY	DESCRIPTION
 When you look into the logs of Pod kubevela-vela-core and found the issue as below.
 
 ```
-$ kubectl get pod -n vela-system -l app.kubernetes.io/name=vela-core
+kubectl get pod -n vela-system -l app.kubernetes.io/name=vela-core
+```
+```console
 NAME                                 READY   STATUS    RESTARTS   AGE
 kubevela-vela-core-f8b987775-wjg25   0/1     -         0          35m
 ```
@@ -152,7 +170,7 @@ kubevela-vela-core-f8b987775-wjg25   0/1     -         0          35m
 You can use github container registry instead.
 
 ```
-$ docker pull ghcr.io/oam-dev/kubevela/vela-core:latest
+docker pull ghcr.io/oam-dev/kubevela/vela-core:latest
 ```
 
 ### Warning: Namespace cert-manager exists
@@ -161,7 +179,9 @@ If you hit the issue as below, an `cert-manager` release might exist whose names
 with KubeVela.
 
 ```
-$ vela install
+vela install
+```
+```console
 - Installing Vela Core Chart:
 install chart vela-core, version 0.1.0, desc : A Helm chart for Kube Vela core, contains 35 file
 Failed to install the chart with error: Namespace "cert-manager" in namespace "" exists and cannot be imported into the current release: invalid ownership metadata; label validation error: missing key "app.kubernetes.io/managed-by": must be set to "Helm"; annotation validation error: missing key "meta.helm.sh/release-name": must be set to "kubevela"; annotation validation error: missing key "meta.helm.sh/release-namespace": must be set to "vela-system"
@@ -180,13 +200,21 @@ Try these steps to fix the problem.
 - Install KubeVela again
 
 ```
-$ helm delete cert-manager -n cert-manager
+helm delete cert-manager -n cert-manager
+```
+```console
 release "cert-manager" uninstalled
-
-$ kubectl delete ns cert-manager
+```
+```
+kubectl delete ns cert-manager
+```
+```console
 namespace "cert-manager" deleted
-
-$ vela install
+```
+```
+vela install
+```
+```console
 - Installing Vela Core Chart:
 install chart vela-core, version 0.1.0, desc : A Helm chart for Kube Vela core, contains 35 file
 Successfully installed the chart, status: deployed, last deployed time = 2020-12-04 10:46:46.782617 +0800 CST m=+4.248889379
@@ -249,12 +277,17 @@ is enabled with command `kubectl top nodes` or `kubectl top pods`.
 If the output is similar as below, the metrics is enabled.
 
 ```shell
-$ kubectl top nodes
+kubectl top nodes
+```
+```console
 NAME                     CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
 cn-hongkong.10.0.1.237   288m         7%     5378Mi          78%
 cn-hongkong.10.0.1.238   351m         8%     5113Mi          74%
-
-$ kubectl top pods
+```
+```
+kubectl top pods
+```
+```console
 NAME                          CPU(cores)   MEMORY(bytes)
 php-apache-65f444bf84-cjbs5   0m           1Mi
 wordpress-55c59ccdd5-lf59d    1m           66Mi
@@ -279,7 +312,7 @@ Please refer to [metrics server debug guide](https://help.aliyun.com/document_de
 Install metrics server as below, or you can install the [latest version](https://github.com/kubernetes-sigs/metrics-server#installation).
 
 ```shell
-$ kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.3.7/components.yaml
+kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.3.7/components.yaml
 ```
 
 Also add the following part under `.spec.template.spec.containers` in the yaml file loaded by `kubectl edit deploy -n kube-system metrics-server`.
@@ -297,7 +330,7 @@ command:
 Enable it with following command.
 
 ```shell
-$ minikube addons enable metrics-server
+minikube addons enable metrics-server
 ```
 
 

docs/en/developers/references/kubectl-plugin.mdx

@@ -0,0 +1,41 @@
+---
+title: Kubectl plugin
+---
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+Install vela kubectl plugin can help you to ship applications more easily!
+
+## Installation
+
+See [advanced-install](../../advanced-install#install-kubectl-vela-plugin)
+
+## Usage
+
+```shell
+$ kubectl vela -h
+A Highly Extensible Platform Engine based on Kubernetes and Open Application Model.
+
+Usage:
+  kubectl vela [flags]
+  kubectl vela [command]
+
+Available Commands:
+
+    comp        Show components in capability registry
+    dry-run     Dry Run an application, and output the K8s resources as
+                result to stdout, only CUE template supported for now
+    live-diff   Dry-run an application, and do diff on a specific app
+                revison. The provided capability definitions will be used
+                during Dry-run. If any capabilities used in the app are not
+                found in the provided ones, it will try to find from
+                cluster.
+    show        Show the reference doc for a workload type or trait
+    trait       Show traits in capability registry
+    version     Prints out build version information
+
+Flags:
+  -h, --help   help for vela
+
+Use "kubectl vela [command] --help" for more information about a command.
+```

docs/en/end-user/application.md

@@ -14,6 +14,8 @@ Let's check the available components in fresh new KubeVela.
 
 ```shell
 kubectl get comp -n vela-system
+```
+```console
 NAME              WORKLOAD-KIND   DESCRIPTION                        
 task              Job             Describes jobs that run code or a script to completion.                                                                                          
 webservice        Deployment      Describes long-running, scalable, containerized services that have a stable network endpoint to receive external network traffic from customers. 
@@ -23,7 +25,9 @@ worker            Deployment      Describes long-running, scalable, containerize
 To show the specification for given component, you could use `vela show`. 
 
 ```shell
-$ kubectl vela show webservice
+kubectl vela show webservice
+```
+```console
 # Properties
 +------------------+----------------------------------------------------------------------------------+-----------------------+----------+---------+
 |       NAME       |                                   DESCRIPTION                                    |         TYPE          | REQUIRED | DEFAULT |
@@ -73,7 +77,9 @@ spec:
 Traits are platform provided features that could *overlay* a given component with extra operational behaviors.
 
 ```shell
-$ kubectl get trait -n vela-system
+kubectl get trait -n vela-system
+```
+```console
 NAME                                       APPLIES-TO            DESCRIPTION                                     
 cpuscaler                                  [webservice worker]   Automatically scale the component based on CPU usage.
 ingress                                    [webservice worker]   Enable public web traffic for the component.
@@ -84,7 +90,9 @@ sidecar                                    [webservice worker]   Inject a sideca
 Let's check the specification of `sidecar` trait.
 
 ```shell
-$ kubectl vela show sidecar
+kubectl vela show sidecar
+```
+```console
 # Properties
 +---------+-----------------------------------------+----------+----------+---------+
 |  NAME   |               DESCRIPTION               |   TYPE   | REQUIRED | DEFAULT |
@@ -137,14 +145,18 @@ spec:
 ## Step 4: Deploy the Application
 
 ```shell
-$ kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/master/docs/examples/enduser/sample.yaml
+kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/master/docs/examples/enduser/sample.yaml
+```
+```console
 application.core.oam.dev/website created
 ```
 
 You'll get the application becomes `running`.
 
 ```shell
-$ kubectl get application
+kubectl get application
+```
+```console
 NAME        COMPONENT   TYPE         PHASE     HEALTHY   STATUS   AGE
 website     frontend    webservice   running   true               4m54s
 ```
@@ -152,7 +164,9 @@ website     frontend    webservice   running   true               4m54s
 Check the details of the application.
 
 ```shell
-$ kubectl get app website -o yaml
+kubectl get app website -o yaml
+```
+```console
 apiVersion: core.oam.dev/v1beta1
 kind: Application
 metadata:
@@ -212,7 +226,9 @@ Specifically:
 When updating an application entity, KubeVela will create a new revision for this change.
 
 ```shell
-$ kubectl get apprev -l app.oam.dev/name=website
+kubectl get apprev -l app.oam.dev/name=website
+```
+```console
 NAME           AGE
 website-v1     35m
 ```

docs/en/end-user/components/cloud-services.md

@@ -15,7 +15,9 @@ The cloud services will be consumed by the application via [Service Binding Trai
 Check the parameters of cloud resource components and trait.
 
 ```shell
-$ kubectl vela show alibaba-rds
+kubectl vela show alibaba-rds
+```
+```console
 # Properties
 +----------------------------+-------------------------------------------------------------------------+-----------------------------------------------------------+----------+---------+
 |            NAME            |                               DESCRIPTION                               |                           TYPE                            | REQUIRED | DEFAULT |
@@ -34,8 +36,11 @@ $ kubectl vela show alibaba-rds
 | namespace | The secret namespace which the cloud resource connection will be written to | string | false    |         |
 +-----------+-----------------------------------------------------------------------------+--------+----------+---------+
 
-
-$ kubectl vela show service-binding
+```
+```shell
+kubectl vela show service-binding
+```
+```console
 # Properties
 +-------------+------------------------------------------------+------------------+----------+---------+
 |    NAME     |                  DESCRIPTION                   |       TYPE       | REQUIRED | DEFAULT |
@@ -106,8 +111,9 @@ spec:
 Check the parameters of cloud service component:
 
 ```shell
-$ kubectl vela show alibaba-rds
-
+kubectl vela show alibaba-rds
+```
+```console
 # Properties
 +---------------+------------------------------------------------+--------+----------+--------------------+
 |     NAME      |                  DESCRIPTION                   |  TYPE  | REQUIRED |      DEFAULT       |
@@ -172,11 +178,16 @@ spec:
 Deploy and verify the application (by either provider is OK).
 
 ```shell
-$ kubectl get application
+kubectl get application
+```
+```console
 NAME     AGE
 webapp   46m
-
-$ kubectl port-forward deployment/express-server 80:80
+```
+```shell
+kubectl port-forward deployment/express-server 80:80
+```
+```console
 Forwarding from 127.0.0.1:80 -> 80
 Forwarding from [::1]:80 -> 80
 Handling connection for 80

docs/en/end-user/components/more.md

@@ -4,6 +4,48 @@ title:  Want More?
 
 Components in KubeVela are designed to be brought by users.
 
+## 1. Get from capability center
+
+KubeVela allows you to explore capabilities maintained by platform team.
+There are two commands in kubectl vela plugin: `comp` and `trait`.
+
+In case you haven't installed kubectl vela plugin: see [this](../../developers/references/kubectl-plugin#install-kubectl-vela-plugin).
+### 1. list
+
+For example, let's try to list all available components in a registry:
+
+```shell
+$ kubectl vela comp --discover
+Showing components from registry: https://registry.kubevela.net
+NAME              	REGITSRY	DEFINITION                 	
+cloneset          	default	    clonesets.apps.kruise.io
+kruise-statefulset	default	    statefulsets.apps.kruise.io
+openfaas          	default	    functions.openfaas.com
+````
+Note that the `--discover` flag means show all components not in your cluster.
+
+### 2. install
+Then you can install a component like:
+
+```shell
+$ kubectl vela comp get cloneset
+Installing component capability cloneset
+Successfully install trait: cloneset                                                                                                 
+```
+
+### 3.verify
+
+```shell
+$ kubectl get componentdefinition  -n vela-system
+NAME         WORKLOAD-KIND   DESCRIPTION
+cloneset     CloneSet        Describes long-running, scalable, containerized services that have a stable network endpoint to receive external network traffic from customers. It was implemented by OpenKruise Cloneset.
+...(other componentDefinition)
+
+```
+
+By default, the two commands will retrieve capabilities from [repo](https://registry.kubevela.net) maintained by KubeVela.
+
+## 2. Designed by yourself 
 Check below documentations about how to bring your own components to the system in various approaches.
 
 - [Helm](../../platform-engineers/helm/component) - Helm chart is a natural form of component, note that you need to have a valid Helm repository (e.g. GitHub repo or a Helm hub) to host the chart in this case.

docs/en/end-user/debug.md

@@ -35,6 +35,8 @@ spec:
 
 ```shell
 kubectl vela dry-run -f app.yaml
+```
+```console
 ---
 # Application(vela-app) -- Comopnent(express-server)
 ---
@@ -124,7 +126,9 @@ Assume you have just deployed the application in dry-run section.
 Then you can list the revisions of the Application.
 
 ```shell
-$ kubectl get apprev -l app.oam.dev/name=vela-app
+kubectl get apprev -l app.oam.dev/name=vela-app
+```
+```console
 NAME          AGE
 vela-app-v1   50s
 ```
@@ -373,4 +377,4 @@ while you just want to focus on the changed ones.
 +         path: /
 ```
 
-</details>
+</details>

docs/en/end-user/scopes/advanced-rollout.md

@@ -0,0 +1,238 @@
+---
+title: Advanced Rollout Plan
+---
+
+The rollout plan feature in KubeVela is essentially provided by `AppRollout` API.
+
+## AppRollout
+
+Below is an example for rolling update an application from v1 to v2 in three batches. The
+first batch contains only 1 pod while the rest of the batches split the rest.
+
+```yaml
+apiVersion: core.oam.dev/v1beta1
+kind: AppRollout
+metadata:
+  name: rolling-example
+spec:
+  sourceAppRevisionName: test-rolling-v1
+  targetAppRevisionName: test-rolling-v2
+  componentList:
+    - metrics-provider
+  rolloutPlan:
+    rolloutStrategy: "IncreaseFirst"
+    rolloutBatches:
+      - replicas: 1
+      - replicas: 50%
+      - replicas: 50%
+    batchPartition: 1
+```
+
+## Basic Usage
+
+1. Deploy application
+    ```yaml
+    apiVersion: core.oam.dev/v1beta1
+    kind: Application
+    metadata:
+      name: test-rolling
+      annotations:
+        "app.oam.dev/rolling-components": "metrics-provider"
+        "app.oam.dev/rollout-template": "true"
+    spec:
+      components:
+        - name: metrics-provider
+          type: worker
+          properties:
+            cmd:
+              - ./podinfo
+              - stress-cpu=1
+            image: stefanprodan/podinfo:4.0.6
+            port: 8080
+            replicas: 5
+    ```
+    Verify AppRevision `test-rolling-v1` have generated
+    ```shell
+    $ kubectl get apprev test-rolling-v1
+    NAME              AGE
+    test-rolling-v1   9s
+    ```
+
+2. Attach the following rollout plan to upgrade the application to v1
+    ```yaml
+    apiVersion: core.oam.dev/v1beta1
+    kind: AppRollout
+    metadata:
+      name: rolling-example
+    spec:
+      # application (revision) reference
+      targetAppRevisionName: test-rolling-v1
+      componentList:
+        - metrics-provider
+      rolloutPlan:
+        rolloutStrategy: "IncreaseFirst"
+        rolloutBatches:
+          - replicas: 10%
+          - replicas: 40%
+          - replicas: 50%
+        targetSize: 5
+    ```
+    User can check the status of the ApplicationRollout and wait for the rollout to complete.
+
+3. User can continue to modify the application image tag and apply.This will generate new AppRevision `test-rolling-v2`
+    ```yaml
+    apiVersion: core.oam.dev/v1beta1
+    kind: Application
+    metadata:
+      name: test-rolling
+      annotations:
+        "app.oam.dev/rolling-components": "metrics-provider"
+        "app.oam.dev/rollout-template": "true"
+    spec:
+      components:
+        - name: metrics-provider
+          type: worker
+          properties:
+            cmd:
+              - ./podinfo
+              - stress-cpu=1
+            image: stefanprodan/podinfo:5.0.2
+            port: 8080
+            replicas: 5
+    ```
+
+    Verify AppRevision `test-rolling-v2` have generated
+    ```shell
+    $ kubectl get apprev test-rolling-v2
+    NAME              AGE
+    test-rolling-v2   7s
+    ```
+
+4. Apply the application rollout that upgrade the application from v1 to v2
+    ```yaml
+    apiVersion: core.oam.dev/v1beta1
+    kind: AppRollout
+    metadata:
+      name: rolling-example
+    spec:
+      # application (revision) reference
+      sourceAppRevisionName: test-rolling-v1
+      targetAppRevisionName: test-rolling-v2
+      componentList:
+        - metrics-provider
+      rolloutPlan:
+        rolloutStrategy: "IncreaseFirst"
+        rolloutBatches:
+          - replicas: 1
+          - replicas: 2
+          - replicas: 2
+    ```
+    User can check the status of the ApplicationRollout and see the rollout completes, and the
+    ApplicationRollout's "Rolling State" becomes `rolloutSucceed`
+
+## Advanced Usage
+
+Using `AppRollout` separately can enable some advanced use case.
+
+### Revert
+
+5. Apply the application rollout that revert the application from v2 to v1
+
+    ```yaml
+    apiVersion: core.oam.dev/v1beta1
+      kind: AppRollout
+      metadata:
+        name: rolling-example
+      spec:
+        # application (revision) reference
+        sourceAppRevisionName: test-rolling-v2
+        targetAppRevisionName: test-rolling-v1
+        componentList:
+          - metrics-provider
+        rolloutPlan:
+          rolloutStrategy: "IncreaseFirst"
+          rolloutBatches:
+            - replicas: 1
+            - replicas: 2
+            - replicas: 2
+    ```
+
+### Skip Revision Rollout
+
+6. User can apply this yaml continue to modify the application image tag.This will generate new AppRevision `test-rolling-v3`
+    ```yaml
+      apiVersion: core.oam.dev/v1beta1
+      kind: Application
+      metadata:
+        name: test-rolling
+        annotations:
+          "app.oam.dev/rolling-components": "metrics-provider"
+          "app.oam.dev/rollout-template": "true"
+      spec:
+        components:
+          - name: metrics-provider
+            type: worker
+            properties:
+              cmd:
+                - ./podinfo
+                - stress-cpu=1
+              image: stefanprodan/podinfo:5.2.0
+              port: 8080
+              replicas: 5
+    ```
+
+    Verify AppRevision `test-rolling-v3` have generated
+    ```shell
+    $ kubectl get apprev test-rolling-v3
+    NAME              AGE
+    test-rolling-v3   7s
+    ```
+
+7. Apply the application rollout that rollout the application from v1 to v3
+    ```yaml
+    apiVersion: core.oam.dev/v1beta1
+      kind: AppRollout
+      metadata:
+        name: rolling-example
+      spec:
+        # application (revision) reference
+        sourceAppRevisionName: test-rolling-v1
+        targetAppRevisionName: test-rolling-v3
+        componentList:
+          - metrics-provider
+        rolloutPlan:
+          rolloutStrategy: "IncreaseFirst"
+          rolloutBatches:
+            - replicas: 1
+            - replicas: 2
+            - replicas: 2
+    ```
+
+## More Details About `AppRollout`
+
+### Design Principles and Goals
+
+There are several attempts at solving rollout problem in the cloud native community. However, none
+of them provide a true rolling style upgrade. For example, flagger supports Blue/Green, Canary
+and A/B testing. Therefore, we decide to add support for batch based rolling upgrade as
+our first style to support in KubeVela.
+
+We design KubeVela rollout solutions with the following principles in mind
+- First, we want all flavors of rollout controllers share the same core rollout
+  related logic. The trait and application related logic can be easily encapsulated into its own
+  package.
+- Second, the core rollout related logic is easily extensible to support different type of
+  workloads, i.e. Deployment, CloneSet, Statefulset, DaemonSet or even customized workloads.
+- Thirdly, the core rollout related logic has a well documented state machine that
+  does state transition explicitly.
+- Finally, the controllers can support all the rollout/upgrade needs of an application running
+  in a production environment including Blue/Green, Canary and A/B testing.
+
+### State Transition
+Here is the high level state transition graph
+
+![](../../resources/approllout-status-transition.jpg)
+
+### Roadmap
+
+Our recent roadmap for rollout plan is [here](./roadmap).

docs/en/end-user/scopes/appdeploy.md

@@ -0,0 +1,240 @@
+---
+title: Placement
+---
+
+## Introduction
+
+In this section, we will introduce how to use KubeVela to place application across multiple clusters with traffic management enabled. For traffic management, KubeVela currently allows you to split the traffic onto both the old and new revisions during rolling update and verify the new version while preserving service availability.
+
+### AppDeployment
+
+The `AppDeployment` API in KubeVela is provided to satisfy such requirements. Here's an overview of the API:
+
+```yaml
+apiVersion: core.oam.dev/v1beta1
+kind: AppDeployment
+metadata:
+  name: sample-appdeploy
+spec:
+  traffic:
+    hosts:
+      - example.com
+
+    http:
+      - match:
+          # match any requests to 'example.com/example-app'
+          - uri:
+              prefix: "/example-app"
+
+        # split traffic 50/50 on v1/v2 versions of the app
+        weightedTargets:
+          - revisionName: example-app-v1
+            componentName: testsvc
+            port: 80
+            weight: 50
+          - revisionName: example-app-v2
+            componentName: testsvc
+            port: 80
+            weight: 50
+
+  appRevisions:
+    - # Name of the AppRevision.
+      # Each modification to Application would generate a new AppRevision.
+      revisionName: example-app-v1
+
+      # Cluster specific workload placement config
+      placement:
+        - clusterSelector:
+            # You can select Clusters by name or labels.
+            # If multiple clusters is selected, one will be picked via a unique hashing algorithm.
+            labels:
+              tier: production
+            name: prod-cluster-1
+
+          distribution:
+            replicas: 5
+
+        - # If no clusterSelector is given, it will use the host cluster in which this CR exists
+          distribution:
+            replicas: 5
+
+    - revisionName: example-app-v2
+      placement:
+        - clusterSelector:
+            labels:
+              tier: production
+            name: prod-cluster-1
+          distribution:
+            replicas: 5
+        - distribution:
+            replicas: 5
+```
+
+### Cluster
+
+The clusters selected in the `placement` part from above is defined in Cluster CRD. Here's what it looks like:
+
+```yaml
+apiVersion: core.oam.dev/v1beta1
+kind: Cluster
+metadata:
+  name: prod-cluster-1
+  labels:
+    tier: production
+spec:
+  kubeconfigSecretRef:
+    name: kubeconfig-cluster-1 # the secret name
+```
+
+The secret must contain the kubeconfig credentials in `config` field:
+
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+  name: kubeconfig-cluster-1
+data:
+  config: ... # kubeconfig data
+```
+
+## Quickstart
+
+Here's a step-by-step tutorial for you to try out. All of the yaml files are from [`docs/examples/appdeployment/`](https://github.com/oam-dev/kubevela/tree/master/docs/examples/appdeployment).
+You must run all commands in that directory.
+
+1. Create an Application
+
+   ```bash
+   cat <<EOF | kubectl apply -f -
+   apiVersion: core.oam.dev/v1beta1
+   kind: Application
+   metadata:
+     name: example-app
+     annotations:
+       app.oam.dev/revision-only: "true"
+   spec:
+     components:
+       - name: testsvc
+         type: webservice
+         properties:
+           addRevisionLabel: true
+           image: crccheck/hello-world
+           port: 8000
+   EOF
+   ```
+
+   This will create `example-app-v1` AppRevision. Check it:
+
+   ```bash
+   kubectl get applicationrevisions.core.oam.dev
+   ```
+   ```console
+   NAME             AGE
+   example-app-v1   116s
+   ```
+
+   > Note: with `app.oam.dev/revision-only: "true"` annotation, above `Application` resource won't create any pod instances and leave the real deployment process to `AppDeployment`.
+
+1. Then use the above AppRevision to create an AppDeployment.
+
+   ```bash
+   kubectl apply -f appdeployment-1.yaml
+   ```
+
+   > Note: in order to AppDeployment to work, your workload object must have a `spec.replicas` field for scaling.
+
+1. Now you can check that there will 1 deployment and 2 pod instances deployed
+
+   ```bash
+   kubectl get deploy
+   ```
+   ```console
+   NAME         READY   UP-TO-DATE   AVAILABLE   AGE
+   testsvc-v1   2/2     2            0           27s
+   ```
+
+1. Update Application properties:
+
+   ```bash
+   cat <<EOF | kubectl apply -f -
+   apiVersion: core.oam.dev/v1beta1
+   kind: Application
+   metadata:
+     name: example-app
+     annotations:
+       app.oam.dev/revision-only: "true"
+   spec:
+     components:
+       - name: testsvc
+         type: webservice
+         properties:
+           addRevisionLabel: true
+           image: nginx
+           port: 80
+   EOF
+   ```
+
+   This will create a new `example-app-v2` AppRevision. Check it:
+
+   ```bash
+   kubectl get applicationrevisions.core.oam.dev
+   ```
+   ```console
+   NAME
+   example-app-v1
+   example-app-v2
+   ```
+
+1. Then use the two AppRevisions to update the AppDeployment:
+
+   ```bash
+   kubectl apply -f appdeployment-2.yaml
+   ```
+
+   (Optional) If you have Istio installed, you can apply the AppDeployment with traffic split:
+
+   ```bash
+   # set up gateway if not yet
+   kubectl apply -f gateway.yaml
+
+   kubectl apply -f appdeployment-2-traffic.yaml
+   ```
+
+   Note that for traffic split to work, your must set the following pod labels in workload cue templates (see [webservice.cue](https://github.com/oam-dev/kubevela/blob/master/hack/vela-templates/cue/webservice.cue)):
+
+   ```shell
+   "app.oam.dev/component": context.name
+   "app.oam.dev/appRevision": context.appRevision
+   ```
+
+1. Now you can check that there will 1 deployment and 1 pod per revision.
+
+   ```bash
+   kubectl get deploy
+   ```
+   ```console
+   NAME         READY   UP-TO-DATE   AVAILABLE   AGE
+   testsvc-v1   1/1     1            1           2m14s
+   testsvc-v2   1/1     1            1           8s
+   ```
+
+   (Optional) To verify traffic split:
+
+   ```bash
+   # run this in another terminal
+   kubectl -n istio-system port-forward service/istio-ingressgateway 8080:80
+   ```
+   ```console
+   Forwarding from 127.0.0.1:8080 -> 8080
+   Forwarding from [::1]:8080 -> 8080
+
+   # The command should return pages of either docker whale or nginx in 50/50
+   $ curl -H "Host: example-app.example.com" http://localhost:8080/
+   ```
+
+1. Cleanup:
+
+   ```bash
+   kubectl delete appdeployments.core.oam.dev --all
+   kubectl delete applications.core.oam.dev --all
+   ```

docs/en/end-user/scopes/health.md

@@ -37,7 +37,7 @@ spec:
 ```
 3. Check the reference of the aggregated health probe (`status.service.scopes`).
 ```shell
-$ kubectl get app vela-app -o yaml
+kubectl get app vela-app -o yaml
 ```
 ```yaml
 apiVersion: core.oam.dev/v1beta1
@@ -57,7 +57,7 @@ status:
 ```
 4.Check health scope detail.
 ```shell
-$ kubectl get healthscope health-check -o yaml
+kubectl get healthscope health-check -o yaml
 ```
 ```yaml
 apiVersion: core.oam.dev/v1alpha2

docs/en/end-user/scopes/rollout-plan.md

@@ -62,5 +62,10 @@ spec:
 User can check the status of the application and see the rollout completes, and the
 application's `status.rollout.rollingState` becomes `rolloutSucceed`.
 
+## Advanced Usage
+
+If you want to control and rollout the specific application revisions, or do revert, please refer to [Advanced Usage](advanced-rollout) to learn more details.
+
+
 
 

docs/en/end-user/traits/annotations-and-labels.md

@@ -38,7 +38,9 @@ kubectl apply -f myapp.yaml
 On runtime cluster, check the workload has been created successfully.
 
 ```bash
-$ kubectl get deployments
+kubectl get deployments
+```
+```console
 NAME             READY   UP-TO-DATE   AVAILABLE   AGE
 express-server   1/1     1            1           15s
 ```
@@ -46,13 +48,17 @@ express-server   1/1     1            1           15s
 Check the `labels`.
 
 ```bash
-$ kubectl get deployments express-server -o jsonpath='{.spec.template.metadata.labels}'
+kubectl get deployments express-server -o jsonpath='{.spec.template.metadata.labels}'
+```
+```console
 {"app.oam.dev/component":"express-server","release": "stable"}
 ```
 
 Check the `annotations`.
 
 ```bash
-$ kubectl get deployments express-server -o jsonpath='{.spec.template.metadata.annotations}'
+kubectl get deployments express-server -o jsonpath='{.spec.template.metadata.annotations}'
+```
+```console
 {"description":"web application"}
 ```

docs/en/end-user/traits/ingress.md

@@ -7,7 +7,9 @@ title: Ingress
 The `ingress` trait exposes a component to public Internet via a valid domain.
 
 ```shell
-$ kubectl vela show ingress
+kubectl vela show ingress
+```
+```console
 # Properties
 +--------+------------------------------------------------------------------------------+----------------+----------+---------+
 |  NAME  |                                 DESCRIPTION                                  |      TYPE      | REQUIRED | DEFAULT |
@@ -41,14 +43,18 @@ spec:
 ```
 
 ```bash
-$ kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/master/docs/examples/vela-app.yaml
+kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/master/docs/examples/vela-app.yaml
+```
+```console
 application.core.oam.dev/first-vela-app created
 ```
 
 Check the status until we see `status` is `running` and services are `healthy`:
 
 ```bash
-$ kubectl get application first-vela-app -w
+kubectl get application first-vela-app -w
+```
+```console
 NAME             COMPONENT        TYPE         PHASE            HEALTHY   STATUS   AGE
 first-vela-app   express-server   webservice   healthChecking                      14s
 first-vela-app   express-server   webservice   running          true               42s
@@ -57,7 +63,9 @@ first-vela-app   express-server   webservice   running          true
 Check the trait detail for the its visiting url:
 
 ```shell
-$ kubectl get application first-vela-app -o yaml
+kubectl get application first-vela-app -o yaml
+```
+```console
 apiVersion: core.oam.dev/v1beta1
 kind: Application
 metadata:
@@ -79,7 +87,9 @@ spec:
 Then you will be able to visit this application via its domain.
 
 ```
-$ curl -H "Host:testsvc.example.com" http://<your ip address>/
+curl -H "Host:testsvc.example.com" http://<your ip address>/
+```
+```console
 <xmp>
 Hello World
 

docs/en/end-user/traits/more.md

@@ -4,4 +4,56 @@ title:  Want More?
 
 Traits in KubeVela are designed as modularized building blocks, they are fully customizable and pluggable.
 
-Check [this documentation](../../platform-engineers/cue/trait) about how to design and enable your own traits in KubeVela platform.
+## 1. Get from capability canter
+
+KubeVela allows you to explore capabilities maintained by platform team. There are two commands in kubectl vela
+plugin: `comp` and `trait`.
+
+In case you haven't installed kubectl vela plugin: see [this](../../developers/references/kubectl-plugin#install-kubectl-vela-plugin).
+
+### 1. list
+
+For example, let's try to list all available traits in registry:
+
+```shell
+$ kubectl vela trait --discover
+Showing traits from registry: https://registry.kubevela.net
+NAME           	REGISTRY	  DEFINITION                    		APPLIES-TO               
+service-account	default  	                              		    [webservice worker]      
+env            	default 		                                    [webservice worker]      
+flagger-rollout	default       canaries.flagger.app          		[webservice]             
+init-container 	default 		                                    [webservice worker]      
+keda-scaler    	default       scaledobjects.keda.sh         		[deployments.apps]       
+metrics        	default       metricstraits.standard.oam.dev		[webservice backend task]
+node-affinity  	default		                              		    [webservice worker]      
+route          	default       routes.standard.oam.dev       		[webservice]             
+virtualgroup   	default		                              		    [webservice worker] 
+```
+Note that the `--discover` flag means show all traits not in your cluster.
+
+### 2. install
+
+Then you can install a trait like:
+
+```shell
+$ kubectl vela trait get init-container
+Installing component capability init-container
+Successfully install trait: init-container                                                                                                 
+```
+
+### 3.verify
+
+```shell
+$ kubectl get traitdefinition  -n vela-system
+NAME             APPLIES-TO                DESCRIPTION
+init-container   ["webservice","worker"]   add an init container with a shared volume.
+...(other trait definitions)
+```
+
+By default, the two commands will retrieve capabilities
+from [repo](https://registry.kubevela.net) maintained by KubeVela.
+
+## 2. Designed by yourself
+
+Check [this documentation](../../platform-engineers/cue/trait) about how to design and enable your own traits in
+KubeVela platform.

docs/en/end-user/traits/scaler.md

@@ -5,7 +5,9 @@ title: Manual Scaling
 The `scaler` trait allows you to scale your component instance manually.
 
 ```shell
-$ kubectl vela show scaler 
+kubectl vela show scaler 
+```
+```console
 # Properties
 +----------+--------------------------------+------+----------+---------+
 |   NAME   |          DESCRIPTION           | TYPE | REQUIRED | DEFAULT |
@@ -48,17 +50,21 @@ spec:
 Apply the sample application:
 
 ```shell
-$ kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/master/docs/examples/enduser/sample-manual.yaml
+kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/master/docs/examples/enduser/sample-manual.yaml
+```
+```console
 application.core.oam.dev/website configured
 ```
 
 In runtime cluster, you can see the underlying deployment of `frontend` component has 2 replicas now.
 
 ```shell
-$ kubectl get deploy -l app.oam.dev/name=website
+kubectl get deploy -l app.oam.dev/name=website
+```
+```console
 NAME       READY   UP-TO-DATE   AVAILABLE   AGE
 backend    1/1     1            1           19h
 frontend   2/2     2            2           19h
 ```
 
-To scale up or scale down, you just need to modify the `replicas` field of `scaler` trait and re-apply the YAML.
+To scale up or scale down, you just need to modify the `replicas` field of `scaler` trait and re-apply the YAML.

docs/en/end-user/traits/service-binding.md

@@ -2,57 +2,10 @@
 title:  Service Binding
 ---
 
-Service binding trait will bind data from Kubernetes `Secret` to the application container's ENV.
+# Description
+Service binding trait will bind data from Kubernetes `Secret` to the application container's ENV. 
 
-```yaml
-apiVersion: core.oam.dev/v1beta1
-kind: TraitDefinition
-metadata:
-  annotations:
-    definition.oam.dev/description: "binding cloud resource secrets to pod env"
-  name: service-binding
-spec:
-  appliesToWorkloads:
-    - webservice
-    - worker
-  schematic:
-    cue:
-      template: |
-        patch: {
-        	spec: template: spec: {
-        		// +patchKey=name
-        		containers: [{
-        			name: context.name
-        			// +patchKey=name
-        			env: [
-        				for envName, v in parameter.envMappings {
-        					name: envName
-        					valueFrom: {
-        						secretKeyRef: {
-        							name: v.secret
-        							if v["key"] != _|_ {
-        								key: v.key
-        							}
-        							if v["key"] == _|_ {
-        								key: envName
-        							}
-        						}
-        					}
-        				},
-        			]
-        		}]
-        	}
-        }
-
-        parameter: {
-        	// +usage=The mapping of environment variables to secret
-        	envMappings: [string]: [string]: string
-        }
-
-```
-
-With the help of this `service-binding` trait, you can explicitly set parameter `envMappings` to mapping all
-environment names with secret key. Here is an example.
+## Sample
 
 ```yaml
 apiVersion: core.oam.dev/v1beta1
@@ -90,3 +43,16 @@ spec:
         secretName: db-conn
 
 ```
+
+For more detailed samples, please reference to [cloud resource](../components/cloud-services)
+
+## Specification
+
+```console
+# Properties
++-------------+------------------------------------------------+------------------+----------+---------+
+|    NAME     |                  DESCRIPTION                   |       TYPE       | REQUIRED | DEFAULT |
++-------------+------------------------------------------------+------------------+----------+---------+
+| envMappings | The mapping of environment variables to secret | map[string]{...} | true     |         |
++-------------+------------------------------------------------+------------------+----------+---------+
+```

docs/en/end-user/traits/sidecar.md

@@ -7,7 +7,9 @@ The `sidecar` trait allows you to attach a sidecar container to the component.
 ## Show the Usage of Sidecar
 
 ```shell
-$ kubectl vela show sidecar
+kubectl vela show sidecar
+```
+```console
 # Properties
 +---------+-----------------------------------------+-----------------------+----------+---------+
 |  NAME   |               DESCRIPTION               |         TYPE          | REQUIRED | DEFAULT |
@@ -80,7 +82,9 @@ kubectl apply -f app.yaml
 On runtime cluster, check the name of running pod.
 
 ```shell
-$ kubectl get pod
+kubectl get pod
+```
+```console
 NAME                              READY   STATUS    RESTARTS   AGE
 log-gen-worker-76945f458b-k7n9k   2/2     Running   0          90s
 ```
@@ -88,7 +92,9 @@ log-gen-worker-76945f458b-k7n9k   2/2     Running   0          90s
 And check the logging output of sidecar. 
 
 ```shell
-$ kubectl logs -f log-gen-worker-76945f458b-k7n9k count-log
+kubectl logs -f log-gen-worker-76945f458b-k7n9k count-log
+```
+```console
 0: Fri Apr 16 11:08:45 UTC 2021
 1: Fri Apr 16 11:08:46 UTC 2021
 2: Fri Apr 16 11:08:47 UTC 2021
@@ -99,4 +105,4 @@ $ kubectl logs -f log-gen-worker-76945f458b-k7n9k count-log
 7: Fri Apr 16 11:08:52 UTC 2021
 8: Fri Apr 16 11:08:53 UTC 2021
 9: Fri Apr 16 11:08:54 UTC 2021 
-```
+```

docs/en/end-user/traits/volumes.md

@@ -10,11 +10,13 @@ Cloud volumes are not built-in capabilities in KubeVela so you need to enable th
 Install and check the `TraitDefinition` for AWS EBS volume trait.
 
 ```shell
-$ kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/master/docs/examples/app-with-volumes/td-awsEBS.yaml
+kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/master/docs/examples/app-with-volumes/td-awsEBS.yaml
 ```
 
 ```shell
-$ kubectl vela show aws-ebs-volume
+kubectl vela show aws-ebs-volume
+```
+```console
 +-----------+----------------------------------------------------------------+--------+----------+---------+
 |   NAME    |                          DESCRIPTION                           |  TYPE  | REQUIRED | DEFAULT |
 +-----------+----------------------------------------------------------------+--------+----------+---------+

docs/en/install.mdx

@@ -5,7 +5,7 @@ title:  Installation
 import Tabs from '@theme/Tabs';
 import TabItem from '@theme/TabItem';
 
-> For upgrading existing KubeVela, please read the [upgrade guide](./advanced-install#upgrade).
+> For upgrading existing KubeVela, please read the [upgrade guide](./advanced-install/#upgrade).
 
 ## 1. Choose Control Plane Cluster
 
@@ -15,7 +15,7 @@ Requirements:
 
 KubeVela relies on Kubernetes as control plane. The control plane could be any managed Kubernetes offering or your own cluster. The only requirement is please ensure [ingress-nginx](https://kubernetes.github.io/ingress-nginx/deploy/) is installed and enabled.
 
-For for local deployment and test, you could use `minikube` or `kind`.
+For local deployment and test, you could use `minikube` or `kind`.
 
 <Tabs
 className="unique-tabs"
@@ -82,7 +82,7 @@ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/mast
 
 1. Add helm chart repo for KubeVela
     ```shell script
-    helm repo add kubevela https://kubevelacharts.oss-accelerate.aliyuncs.com/core
+    helm repo add kubevela https://charts.kubevela.net/core
     ```
 
 2. Update the chart repo
@@ -132,7 +132,7 @@ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/mast
 
 KubeVela CLI gives you a simplified workflow to manage applications with optimized output. It is not mandatory though.
 
-KubeVela CLI could be [installed as kubectl plugin](./kubectl-plugin.mdx), or install as standalone binary.
+KubeVela CLI could be [installed as kubectl plugin](./advanced-install#install-kubectl-vela-plugin), or install as standalone binary.
 
 <Tabs
     className="unique-tabs"
@@ -223,4 +223,4 @@ These capabilities are built-in so they are ready to use if showed up. KubeVela
 
 Also, whenever new capabilities are added in the platform, you will immediately see them in above output.
 
-> See the [advanced installation guide](./advanced-install) to learn more about installation details.
+> See the [advanced installation guide](./advanced-install) to learn more about installation details.

docs/en/introduction.md

@@ -8,17 +8,17 @@ slug: /
 
 ## Motivation
 
-The trend of cloud-native technology is moving towards pursuing consistent application delivery across clouds and on-premises infrastructures using Kubernetes as the common layer. Kubernetes, although excellent in abstracting low-level infrastructure details, does not introduce abstractions to model software deployment on top of hybrid environments. We’ve seen the lack of such application level context have impacted user experiences, slowed down productivity, led to unexpected errors or misconfigurations in production.
+The trend of cloud-native technology is moving towards pursuing consistent application delivery across clouds and on-premises infrastructures using Kubernetes as the common layer. Kubernetes, although excellent in abstracting low-level infrastructure details, does not introduce abstractions to model software deployment on top of hybrid environments. We’ve seen the lack of application level context have impacted user experiences, slowed down productivity, led to unexpected errors or misconfigurations in production.
 
-On the other hand, modeling a deployment of a modern microservice application is a highly opinionated and fragmented process today. Thus, most solutions aim to solve above problem (although built with Kubernetes) are essentially restricted systems and barely extensible. As the needs of your application grow, they are almost certain to outgrow the capabilities of such systems. Application teams complain they are too rigid and slow in response to feature requests or improvements. The platform team do want to help but the engineering effort is daunting: any simple API change in the platform could easily become a marathon negotiation around the opinionated abstraction design.
+On the other hand, modeling the deployment of a microservice application is a highly opinionated and fragmented process. Thus, many solutions tried to solve above problem so far essentially became restricted systems and barely extensible (regardless of whether they are built with Kubernetes or not). As the needs of your application grow, they are almost certain to outgrow the capabilities of such systems. Application teams complain they are too rigid and slow in response to feature requests or improvements. The platform team do want to help but the engineering effort is daunting: any simple change to such platform could easily become a marathon negotiation around system level design and implementation.
 
 ## What is KubeVela?
 
-KubeVela is a modern application platform that aims to make deploying and managing applications across hybrid, multi-cloud environments easier and faster by doing the following:
+KubeVela is a modern application platform that makes deploying and managing applications across today's hybrid, multi-cloud environments easier and faster without introducing another layer of restriction. This is achieved by doing the following:
 
-**Application Centric** - KubeVela introduces consistent yet application centric API to capture a full deployment of microservices on top of hybrid environments. No infrastructure level concern, simply deploy.
+**Application Centric** - KubeVela introduces consistent yet higher level API to capture a full deployment of microservices on top of hybrid environments. No infrastructure level concern, simply deploy.
 
-**Natively Extensible** - KubeVela uses CUE to glue capabilities provided by runtime infrastructure and expose them to users via self-service API. When users' needs grow, these API can naturally expand in programmable approach.
+**Natively Extensible** - KubeVela uses [CUE](https://cuelang.org/) as super glue to assemble capabilities provided by runtime infrastructures and expose them to users via application-centric APIs. When users' needs grow, these APIs can naturally expand in programmable approach.
 
 **Runtime Agnostic** - KubeVela is built with Kubernetes as control plane but adaptable to any runtime as data-plane. It can deploy (and manage) diverse workload types such as container, cloud functions, databases, or even EC2 instances across hybrid environments.
 
@@ -44,7 +44,7 @@ The typical examples are Heroku and Cloud Foundry. They provide full application
 
 Though the biggest difference lies in **flexibility**.
 
-KubeVela enables you to serve end users with programmable building blocks (based on [CUE](https://cuelang.org/)) which are fully flexible and can be extended at any time. Comparing to this mechanism, traditional PaaS systems are highly restricted, i.e. they have to enforce constraints in the type of supported applications and capabilities, and as application needs grows, you always outgrow the capabilities of the PaaS system - this will never happen in KubeVela platform.
+KubeVela enables you to serve end users with programmable building blocks (based on CUE) which are fully flexible and can be extended at any time. Comparing to this mechanism, traditional PaaS systems are highly restricted, i.e. they have to enforce constraints in the type of supported applications and capabilities, and as application needs grows, you always outgrow the capabilities of the PaaS system - this will never happen in KubeVela platform.
 
 So think of KubeVela as a Heroku but it is fully extensible when your needs grow.
 
@@ -52,26 +52,23 @@ So think of KubeVela as a Heroku but it is fully extensible when your needs grow
 
 Serverless platform such as AWS Lambda provides extraordinary user experience and agility to deploy serverless applications. However, those platforms impose even more constraints in extensibility. They are arguably "hard-coded" PaaS.
 
-KubeVela can easily deploy both Kubernetes based serverless workloads such as Knative/OpenFaaS, or cloud functions such as AWS Lambda. Simply register what you want to deploy as a "component".
+KubeVela can easily deploy both Kubernetes based serverless workloads such as Knative/OpenFaaS, or cloud based functions such as AWS Lambda. Simply register them as a "component" in KubeVela platform.
 
 ### KubeVela vs. Platform agnostic developer tools
 
 The typical example is Hashicorp's Waypoint. Waypoint is a developer facing tool which introduces a consistent workflow (i.e., build, deploy, release) to ship applications on top of different platforms.
 
-KubeVela can be integrated with such tools seamlessly. In this case, developers would use the Waypoint workflow as the UI to deploy and manage applications across hybrid environments with KubeVela's abstractions (e.g. applications, components, traits etc).
+KubeVela can be integrated with such tools seamlessly. In this case, developers would use the Waypoint workflow as the UI to deploy and manage applications across hybrid environments leveraging KubeVela as core deployment engine.
 
 ### KubeVela vs. Helm 
 
 Helm is a package manager for Kubernetes that provides package, install, and upgrade a set of YAML files for Kubernetes as a unit. 
 
-KubeVela as a modern deployment system can naturally deploys Helm charts across hybrid environments. For example, you could easily use KubeVela to declare and deploy an application which is composed by a WordPress Helm chart and a AWS RDS instance defined by Terraform, or distribute the Helm chart to multiple clusters.
-
-KubeVela also leverages Helm to manage the capability addons in runtime clusters.
+KubeVela as a modern deployment system can naturally deploys Helm charts across hybrid environments. For example, you could easily use KubeVela to declare and deploy an application which is composed by a WordPress Helm chart and a AWS RDS instance defined by Terraform, attach traits to the chart, or distribute the chart to multiple clusters. KubeVela itself also leverages Helm to manage the capability addons in runtime Kubernetes clusters.
 
 ### KubeVela vs. Kubernetes
 
-KubeVela is a Kubernetes add-on for building developer-centric deployment system. It leverages [Open Application Model](https://github.com/oam-dev/spec) and the native Kubernetes extensibility to resolve a hard problem - making shipping applications enjoyable on Kubernetes.
-
+KubeVela is a Kubernetes add-on for building modern application deployment system. It leverages [Open Application Model](https://github.com/oam-dev/spec) and Kubernetes as control plane to resolve a hard problem - making shipping applications enjoyable.
 
 ## What's Next
 

docs/en/kubectl-plugin.mdx

@@ -1,75 +0,0 @@
----
-title: Install kubectl plugin
----
-import Tabs from '@theme/Tabs';
-import TabItem from '@theme/TabItem';
-
-Install vela kubectl plugin can help you to ship applications more easily!
-
-## Installation
-
-You can install kubectl plugin `kubectl vela` by:
-
-<Tabs
-className="unique-tabs"
-defaultValue="krew"
-values={[
-    {label: 'Krew', value: 'krew'},
-    {label: 'Script', value: 'script'},
-]}>
-<TabItem value="krew">
-
-1. [Install and set up](https://krew.sigs.k8s.io/docs/user-guide/setup/install/) Krew on your machine.
-2. Discover plugins available on Krew:
-```shell
-kubectl krew update
-```
-3. install kubectl vela:
-```shell script
-kubectl krew install vela
-```
-
-</TabItem>
-<TabItem value="script">
-
-**macOS/Linux**
-```shell script
-curl -fsSl https://kubevela.io/script/install-kubectl-vela.sh | bash
-```
-
-You can also download the binary from [release pages ( >= v1.0.3)](https://github.com/oam-dev/kubevela/releases) manually.
-Kubectl will discover it from your system path automatically.
-
-</TabItem>
-</Tabs>
-
-
-
-## Usage
-
-```shell
-$ kubectl vela -h
-A Highly Extensible Platform Engine based on Kubernetes and Open Application Model.
-
-Usage:
-  kubectl vela [flags]
-  kubectl vela [command]
-
-Available Commands:
-
-Flags:
-  -h, --help   help for vela
-
-    dry-run  	Dry Run an application, and output the K8s resources as
-             	result to stdout, only CUE template supported for now
-    live-diff	Dry-run an application, and do diff on a specific app
-             	revison. The provided capability definitions will be used
-             	during Dry-run. If any capabilities used in the app are not
-             	found in the provided ones, it will try to find from
-             	cluster.
-    show     	Show the reference doc for a workload type or trait
-    version  	Prints out build version information
-
-
-Use "kubectl vela [command] --help" for more information about a command.
-```

docs/en/platform-engineers/cloud-services.md

@@ -12,8 +12,8 @@ In KubeVela, the needed cloud services are claimed as *components* in an applica
 
 KubeVela relies on [Terraform Controller](https://github.com/oam-dev/terraform-controller) or [Crossplane](http://crossplane.io/) as providers to talk to the clouds. Please check the documentations below for detailed steps.
 
-- [Terraform](./terraform.md)
-- [Crossplane](./crossplane.md)
+- [Terraform](./terraform)
+- [Crossplane](./crossplane)
 
 ## Can a Instance of Cloud Services be Shared by Multiple Applications?
 

docs/en/platform-engineers/crossplane.md

@@ -9,6 +9,7 @@ These cloud services are provided by Crossplane.
 ## Prepare Crossplane
 
 <details>
+  
 Please Refer to [Installation](https://github.com/crossplane/provider-alibaba/releases/tag/v0.5.0) 
 to install Crossplane Alibaba provider v0.5.0.
 

docs/en/platform-engineers/cue/basic.md

@@ -66,7 +66,9 @@ CUE has powerful CLI commands. Let's keep the data in a file named `first.cue` a
   You can see the results don't contain `a: float` and `b: int`, because these two variables are calculated.
   While the `e: string` doesn't have definitive results, so it keeps as it is.
     ```shell
-   $ cue eval first.cue
+    cue eval first.cue
+    ```
+    ```console
     a: 1.5
     b: 1
     d: [1, 2, 3]
@@ -78,13 +80,17 @@ CUE has powerful CLI commands. Let's keep the data in a file named `first.cue` a
 
 * Render for specified result. For example, we want only know the result of `b` in the file, then we can specify the parameter `-e`.
     ```shell
-    $ cue eval -e b first.cue
+    cue eval -e b first.cue
+    ```
+    ```console
     1
     ```
 
 * Export the result. `cue export` will export the result with final value. It will report an error if some variables are not definitive.
     ```shell
-    $ cue export first.cue
+    cue export first.cue
+    ```
+    ```console
     e: cannot convert incomplete value "string" to JSON:
         ./first.cue:9:4
     ```
@@ -94,7 +100,9 @@ CUE has powerful CLI commands. Let's keep the data in a file named `first.cue` a
     ```
   Then, the command will work. By default, the result will be rendered in json format.
     ```shell
-    $ cue export first.cue
+    cue export first.cue
+    ```
+    ```console
     {
         "a": 1.5,
         "b": 1,
@@ -112,7 +120,9 @@ CUE has powerful CLI commands. Let's keep the data in a file named `first.cue` a
 
 * Export the result in YAML format.
     ```shell
-    $ cue export first.cue --out yaml
+    cue export first.cue --out yaml
+    ```
+    ```console
     a: 1.5
     b: 1
     d:
@@ -126,7 +136,9 @@ CUE has powerful CLI commands. Let's keep the data in a file named `first.cue` a
 
 * Export the result for specified variable.
     ```shell
-    $ cue export -e g first.cue
+    cue export -e g first.cue
+    ```
+    ```console
     {
         "h": "abc"
     }
@@ -177,7 +189,9 @@ j: null
 Let's name it `second.cue`. Then the `cue export` won't complain as the `#abc` is a type not incomplete value.
 
 ```shell
-$ cue export second.cue
+cue export second.cue
+```
+```console
 {}
 ```
 
@@ -251,7 +265,9 @@ parameter:{
 5. Finally, let's export it in yaml:
 
 ```shell
-$ cue export deployment.cue -e template --out yaml
+cue export deployment.cue -e template --out yaml
+```
+```console
 apiVersion: apps/v1
 kind: Deployment
 spec:
@@ -345,7 +361,9 @@ Saving it in `third.cue` file.
 You can evaluate the result by using `cue eval`:
 
 ```shell
-$ cue eval third.cue
+cue eval third.cue
+```
+```console
 a: 1
 b: 3
 c: 3
@@ -369,7 +387,9 @@ Saving it in `fourth.cue` file.
 You can evaluate the result by using `cue eval`:
 
 ```shell
-$ cue eval fourth.cue
+cue eval fourth.cue
+```
+```console
 price: 200
 feel:  "bad"
 ```
@@ -545,4 +565,4 @@ output: {
 parameter: {
 	name:  "myapp"
 }
-```
+```

docs/en/platform-engineers/cue/component.md

@@ -4,7 +4,7 @@ title:  How-to
 
 In this section, it will introduce how to use [CUE](https://cuelang.org/) to declare app components via `ComponentDefinition`.
 
-> Before reading this part, please make sure you've learned the [Definition CRD](../definition-and-templates.md) in KubeVela.
+> Before reading this part, please make sure you've learned the [Definition CRD](../definition-and-templates) in KubeVela.
 
 ## Declare `ComponentDefinition`
 
@@ -221,7 +221,7 @@ output: {
 
 It's common that a component definition is composed by multiple API resources, for example, a `webserver` component that is composed by a Deployment and a Service. CUE is a great solution to achieve this in simplified primitives.
 
-> Another approach to do composition in KubeVela of course is [using Helm](../helm/component.md).
+> Another approach to do composition in KubeVela of course is [using Helm](../helm/component).
 
 ## How-to
 
@@ -354,15 +354,21 @@ spec:
 It will generate and manage below API resources in target cluster:
 
 ```shell
-$ kubectl get deployment
+kubectl get deployment
+```
+```console
 NAME             READY   UP-TO-DATE   AVAILABLE   AGE
 hello-world-v1   1/1     1            1           15s
+```
 
-$ kubectl get svc
+```shell
+kubectl get svc
+```
+```console
 NAME                           TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
 hello-world-trait-7bdcff98f7   ClusterIP   <your ip>       <none>        8000/TCP   32s
 ```
 
 ## What's Next
 
-Please check the [Learning CUE](./basic) documentation about why we support CUE as first-class templating solution and more details about using CUE efficiently.
+Please check the [Learning CUE](./basic) documentation about why we support CUE as first-class templating solution and more details about using CUE efficiently.

docs/en/platform-engineers/cue/patch-trait.md

@@ -19,8 +19,7 @@ metadata:
   name: node-affinity
 spec:
   appliesToWorkloads:
-    - webservice
-    - worker
+    - deployments.apps
   podDisruptive: true
   schematic:
     cue:
@@ -97,15 +96,17 @@ By default, patch trait in KubeVela leverages the CUE `merge` operation. It has
 
 ### Strategy Patch
 
-The `strategy patch` is useful for patching array list.
+Strategy Patch is effective by adding annotation, and supports the following two ways
 
 > Note that this is not a standard CUE feature, KubeVela enhanced CUE in this case.
 
-With `//+patchKey=<key_name>` annotation, merging logic of two array lists will not follow the CUE behavior. Instead, it will treat the list as object and use a strategy merge approach:
+#### 1. With `+patchKey=<key_name>` annotation
+
+This is useful for patching array list, merging logic of two array lists will not follow the CUE behavior. Instead, it will treat the list as object and use a strategy merge approach:
  - if a duplicated key is found, the patch data will be merge with the existing values; 
  - if no duplication found, the patch will append into the array list.
 
-The example of strategy patch trait will like below:
+The example of strategy patch trait with 'patchKey' will like below:
  
 ```yaml
 apiVersion: core.oam.dev/v1beta1
@@ -116,8 +117,7 @@ metadata:
   name: sidecar
 spec:
   appliesToWorkloads:
-    - webservice
-    - worker
+    - deployments.apps
   podDisruptive: true
   schematic:
     cue:
@@ -146,8 +146,7 @@ metadata:
   name: expose
 spec:
   appliesToWorkloads:
-    - webservice
-    - worker
+    - deployments.apps
   podDisruptive: true
   schematic:
     cue:
@@ -174,6 +173,76 @@ spec:
 
 So the above trait which attaches a Service to given component instance will patch an corresponding label to the workload first and then render the Service resource based on template in `outputs`.
 
+#### 2. With `+patchStrategy=retainkeys` annotation
+
+Similar to strategy [retainkeys](https://kubernetes.io/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/#use-strategic-merge-patch-to-update-a-deployment-using-the-retainkeys-strategy) in K8s strategic merge patch
+
+In some scenarios that the entire object needs to be replaced, retainkeys strategy is the best choice. the example as follows:
+
+Assume the Deployment is the base resource
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: retainkeys-demo
+spec:
+  selector:
+    matchLabels:
+      app: nginx
+  strategy:
+    type: rollingUpdate
+    rollingUpdate:
+      maxSurge: 30%
+  template:
+    metadata:
+      labels:
+        app: nginx
+    spec:
+      containers:
+      - name: retainkeys-demo-ctr
+        image: nginx
+```
+Now want to replace rollingUpdate strategy with a new strategy, you can write the patch trait like below
+
+```yaml
+apiVersion: core.oam.dev/v1alpha2
+kind: TraitDefinition
+metadata:
+  name: recreate
+spec:
+  appliesToWorkloads:
+    - deployments.apps
+  extension:
+    template: |-
+      patch: {
+         spec: {
+              // +patchStrategy=retainKeys
+              strategy: type: "Recreate"
+           }
+      }        
+```
+Then the base resource becomes as follows
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: retainkeys-demo
+spec:
+  selector:
+    matchLabels:
+      app: nginx
+  strategy:
+    type: Recreate
+  template:
+    metadata:
+      labels:
+        app: nginx
+    spec:
+      containers:
+      - name: retainkeys-demo-ctr
+        image: nginx
+```
 ## More Use Cases of Patch Trait
 
 Patch trait is in general pretty useful to separate operational concerns from the component definition, here are some more examples.
@@ -191,8 +260,7 @@ metadata:
   name: virtualgroup
 spec:
   appliesToWorkloads:
-    - webservice
-    - worker
+    - deployments.apps
   podDisruptive: true
   schematic:
     cue:
@@ -242,8 +310,7 @@ metadata:
   name: kautoscale
 spec:
   appliesToWorkloads:
-    - webservice
-    - worker
+    - deployments.apps
   podDisruptive: false
   schematic:
     cue:
@@ -279,8 +346,7 @@ metadata:
   name: env
 spec:
   appliesToWorkloads:
-    - webservice
-    - worker
+    - deployments.apps
   podDisruptive: true
   schematic:
     cue:
@@ -321,8 +387,7 @@ metadata:
   name: service-account
 spec:
   appliesToWorkloads:
-    - webservice
-    - worker
+    - deployments.apps
   podDisruptive: true
   schematic:
     cue:
@@ -368,8 +433,7 @@ metadata:
   name: init-container
 spec:
   appliesToWorkloads:
-    - webservice
-    - worker
+    - deployments.apps
   podDisruptive: true
   schematic:
     cue:

docs/en/platform-engineers/debug-test-cue.md

@@ -132,10 +132,10 @@ parameter: {
 }
 ```
 
-After everything is done, there's a script [`hack/vela-templates/mergedef.sh`](https://github.com/oam-dev/kubevela/blob/master/hack/vela-templates/mergedef.sh) to merge the `def.yaml` and `def.cue` into a completed Definition Object.
+After everything is done, there's a script [`vela-templates/mergedef.sh`](https://github.com/oam-dev/kubevela/blob/master/vela-templates/mergedef.sh) to merge the `def.yaml` and `def.cue` into a completed Definition Object.
 
 ```shell
-$ ./hack/vela-templates/mergedef.sh def.yaml def.cue > microservice-def.yaml
+./vela-templates/mergedef.sh def.yaml def.cue > microservice-def.yaml
 ```
 
 ## Debug CUE template
@@ -143,7 +143,9 @@ $ ./hack/vela-templates/mergedef.sh def.yaml def.cue > microservice-def.yaml
 ### Use `cue vet` to Validate
 
 ```shell
-$ cue vet def.cue
+cue vet def.cue
+```
+```console
 output.metadata.name: reference "context" not found:
     ./def.cue:6:14
 output.spec.selector.matchLabels.app: reference "context" not found:
@@ -174,14 +176,18 @@ context: {
 Then execute the command:
 
 ```shell
-$ cue vet def.cue
+cue vet def.cue
+```
+```console
 some instances are incomplete; use the -c flag to show errors or suppress this message
 ```
 
 The `reference "context" not found` error is gone, but  `cue vet` only validates the data type which is not enough to ensure the login in template is correct. Hence we need to use `cue vet -c` for complete validation:
 
 ```shell
-$ cue vet def.cue -c
+cue vet def.cue -c
+```
+```console
 context.name: incomplete value string
 output.metadata.name: incomplete value string
 output.spec.selector.matchLabels.app: incomplete value string
@@ -226,7 +232,9 @@ cue vet def.cue -c
 The `cue export` can export rendered result in YAMl foramt:
 
 ```shell
-$ cue export -e output def.cue --out yaml
+cue export -e output def.cue --out yaml
+```
+```console
 apiVersion: apps/v1
 kind: Deployment
 metadata:
@@ -250,7 +258,9 @@ spec:
 ```
 
 ```shell
-$ cue export -e outputs.service def.cue --out yaml
+cue export -e outputs.service def.cue --out yaml
+```
+```console
 apiVersion: v1
 kind: Service
 metadata:
@@ -286,7 +296,9 @@ There are two kinds of ways to import internal `kube` packages.
 2. Import them with third-party packages style. You can run `vela system cue-packages` to list all build-in `kube` packages
    to know the `third-party packages` supported currently.
     ```shell
-    $ vela system cue-packages
+    vela system cue-packages
+    ```
+    ```console
     DEFINITION-NAME                	IMPORT-PATH                         	 USAGE
     #Deployment                    	k8s.io/apps/v1                      	Kube Object for apps/v1.Deployment
     #Service                       	k8s.io/core/v1                      	Kube Object for v1.Service
@@ -520,7 +532,9 @@ parameter: {
 Use `cue export` to see the export result.
 
 ```shell
-$ cue export def.cue --out yaml
+cue export def.cue --out yaml
+```
+```console
 output:
   metadata:
     name: test
@@ -576,7 +590,7 @@ When CUE template is good, we can use `vela system dry-run` to dry run and check
 First, we need use `mergedef.sh` to merge the definition and cue files.
 
 ```shell
-$ mergedef.sh def.yaml def.cue > componentdef.yaml
+mergedef.sh def.yaml def.cue > componentdef.yaml
 ```
 
 Then, let's create an Application named `test-app.yaml`.
@@ -604,7 +618,9 @@ spec:
 Dry run the application by using `vela system dry-run`.
 
 ```shell
-$ vela system dry-run -f test-app.yaml -d componentdef.yaml
+vela system dry-run -f test-app.yaml -d componentdef.yaml
+```
+```console
 ---
 # Application(boutique) -- Comopnent(frontend)
 ---

docs/en/platform-engineers/definition-and-templates.md

@@ -70,7 +70,6 @@ metadata:
 spec:
   appliesToWorkloads: 
     - deployments.apps
-    - webservice
   conflictsWith: 
     - service
   workloadRefPath: spec.wrokloadRef
@@ -85,16 +84,15 @@ This field defines the constraints that what kinds of workloads this trait is al
 - It accepts an array of string as value.
 - Each item in the array refers to one or a group of workload types to which this trait is allowded to apply.
 
-There are four approaches to denote one or a group of workload types.
+There are three approaches to denote one or a group of workload types.
 
-- `ComponentDefinition` name, e.g., `webservice`, `worker`
 - `ComponentDefinition` definition reference (CRD name), e.g., `deployments.apps`
 - Resource group of `ComponentDefinition` definition reference prefixed with `*.`, e.g., `*.apps`, `*.oam.dev`. This means the trait is allowded to apply to any workloads in this group.
 - `*` means this trait is allowded to apply to any workloads
 
 If this field is omitted, it means this trait is allowded to apply to any workload types.
 
-KubeVela will raise an error if a trait is applied to a workload which is NOT included in the `appliesToWorkloads`.
+KubeVela will raise an error if a trait is applied to a workload type which is NOT included in the `appliesToWorkloads`.
 
 
 ##### `.spec.conflictsWith` 
@@ -242,7 +240,9 @@ In KubeVela, definition entities are mutable. Each time a `ComponentDefinition`
 For example, we can design a new parameter named `args` for the `webservice` component definition by applying a new definition with same name as below.
 
 ```shell
-$ kubectl vela show webservice
+kubectl vela show webservice
+```
+```console
 # Properties
 +-------+----------------------------------------------------+----------+----------+---------+
 | NAME  |                    DESCRIPTION                     |   TYPE   | REQUIRED | DEFAULT |
@@ -258,7 +258,9 @@ kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/master/docs/
 The change will take effect immediately.
 
 ```shell
-$ kubectl vela show webservice
+kubectl vela show webservice
+```
+```console
 # Properties
 +-------+----------------------------------------------------+----------+----------+---------+
 | NAME  |                    DESCRIPTION                     |   TYPE   | REQUIRED | DEFAULT |
@@ -271,7 +273,9 @@ $ kubectl vela show webservice
 We will see a new definition revision will be automatically generated, `v2` is the latest version, `v1` is the previous one.
 
 ```shell
-$  kubectl get definitionrevision -l="componentdefinition.oam.dev/name=webservice" -n vela-system
+kubectl get definitionrevision -l="componentdefinition.oam.dev/name=webservice" -n vela-system
+```
+```console
 NAME            REVISION   HASH               TYPE
 webservice-v1   1          3f6886d9832021ba   Component
 webservice-v2   2          b3b9978e7164d973   Component
@@ -316,4 +320,4 @@ spec:
         - '1000'
       args:
         - wait
-```
+```

docs/en/platform-engineers/helm/component.md

@@ -4,7 +4,7 @@ title:  How-to
 
 In this section, it will introduce how to declare Helm charts as components via `ComponentDefinition`.
 
-> Before reading this part, please make sure you've learned [the definition and template concepts](../definition-and-templates.md).
+> Before reading this part, please make sure you've learned [the definition and template concepts](../definition-and-templates).
 
 ## Prerequisite
 
@@ -65,18 +65,24 @@ The component `properties` is exactly the [overlay values](https://github.com/ca
 
 Deploy the application and after several minutes (it may take time to fetch Helm chart), you can check the Helm release is installed.
 ```shell
-$ helm ls -A
+helm ls -A
+```
+```console
 myapp-demo-podinfo  default   1   2021-03-05 02:02:18.692317102 +0000 UTC deployed  podinfo-5.1.4     5.1.4
 ```
 Check the workload defined in the chart has been created successfully.
 ```shell
-$ kubectl get deploy
+kubectl get deploy
+```
+```console
 NAME                     READY   UP-TO-DATE   AVAILABLE   AGE
 myapp-demo-podinfo   1/1     1            1           66m
 ```
 
 Check the values (`image.tag = 5.1.2`) from application's `properties` are assigned to the chart.
 ```shell
-$ kubectl get deployment myapp-demo-podinfo -o json | jq '.spec.template.spec.containers[0].image'
+kubectl get deployment myapp-demo-podinfo -o json | jq '.spec.template.spec.containers[0].image'
+```
+```console
 "ghcr.io/stefanprodan/podinfo:5.1.2"
 ```

docs/en/platform-engineers/helm/trait.md

@@ -40,18 +40,24 @@ spec:
 
 Check the `scaler` trait takes effect.
 ```shell
-$ kubectl get manualscalertrait
+kubectl get manualscalertrait
+```
+```console
 NAME                            AGE
 demo-podinfo-scaler-d8f78c6fc   13m
 ```
 ```shell
-$ kubectl get deployment myapp-demo-podinfo -o json | jq .spec.replicas
+kubectl get deployment myapp-demo-podinfo -o json | jq .spec.replicas
+```
+```console
 4
 ```
 
 Check the `virtualgroup` trait.
 ```shell
-$ kubectl get deployment myapp-demo-podinfo -o json | jq .spec.template.metadata.labels
+kubectl get deployment myapp-demo-podinfo -o json | jq .spec.template.metadata.labels
+```
+```console
 {
   "app.cluster.virtual.group": "my-group1",
   "app.kubernetes.io/name": "myapp-demo-podinfo"
@@ -93,25 +99,33 @@ Apply the new configuration and check the results after several minutes.
 
 Check the new values (`image.tag = 5.1.3`) from application's `properties` are assigned to the chart.
 ```shell
-$ kubectl get deployment myapp-demo-podinfo -o json | jq '.spec.template.spec.containers[0].image'
+kubectl get deployment myapp-demo-podinfo -o json | jq '.spec.template.spec.containers[0].image'
+```
+```console
 "ghcr.io/stefanprodan/podinfo:5.1.3"
 ```
 Under the hood, Helm makes an upgrade to the release (revision 1 => 2).
 ```shell
-$ helm ls -A
+helm ls -A
+```
+```console
 NAME              	NAMESPACE	REVISION	UPDATED                                	STATUS  	CHART        	APP VERSION
 myapp-demo-podinfo	default  	2       	2021-03-15 08:52:00.037690148 +0000 UTC	deployed	podinfo-5.1.4	5.1.4
 ```
 
 Check the `scaler` trait.
 ```shell
-$ kubectl get deployment myapp-demo-podinfo -o json | jq .spec.replicas
+kubectl get deployment myapp-demo-podinfo -o json | jq .spec.replicas
+```
+```console
 2
 ```
 
 Check the `virtualgroup` trait.
 ```shell
-$ kubectl get deployment myapp-demo-podinfo -o json | jq .spec.template.metadata.labels
+kubectl get deployment myapp-demo-podinfo -o json | jq .spec.template.metadata.labels
+```
+```console
 {
   "app.cluster.virtual.group": "my-group2",
   "app.kubernetes.io/name": "myapp-demo-podinfo"
@@ -147,7 +161,9 @@ spec:
 
 Apply the application and check `manualscalertrait` has been deleted.
 ```shell
-$ kubectl get manualscalertrait
+kubectl get manualscalertrait
+```
+```console
 No resources found
 ```
 

docs/en/platform-engineers/keda.md

@@ -46,7 +46,7 @@ This is how you claim and register KEDA `ScaledObject`'s API resource (`scaledob
 
 ### 3. Define `appliesToWorkloads`
 
-A trait can be attached to specified workload types or all (i.e. `"*"` means your trait can work with any workload type).
+A trait can be attached to specified workload types or all (i.e. `"*"` or omitted means your trait can work with any workload type).
 
 For the case of KEAD, we will only allow user to attach it to Kubernetes workload type. So we claim it as below:
 
@@ -105,7 +105,7 @@ This is a CUE based template which only exposes `type` and `value` as trait prop
 As long as the definition file is ready, you just need to apply it to Kubernetes.
 
 ```bash
-$ kubectl apply -f https://raw.githubusercontent.com/oam-dev/catalog/master/registry/keda-scaler.yaml
+kubectl apply -f https://raw.githubusercontent.com/oam-dev/catalog/master/registry/keda-scaler.yaml
 ```
 
 And the new trait will immediately become available for end users to use in `Application` resource.

docs/en/platform-engineers/kube/component.md

@@ -79,13 +79,17 @@ Since parameters only support basic data type, values in `properties` should be
 Deploy the `Application` and verify the running workload instance.
 
 ```shell
-$ kubectl get deploy
+kubectl get deploy
+```
+```console
 NAME                     READY   UP-TO-DATE   AVAILABLE   AGE
 mycomp                   1/1     1            1           66m
 ```
 And check the parameter works.
 ```shell
-$ kubectl get deployment mycomp -o json | jq '.spec.template.spec.containers[0].image'
+kubectl get deployment mycomp -o json | jq '.spec.template.spec.containers[0].image'
+```
+```console
 "nginx:1.14.0"
 ```
 

docs/en/platform-engineers/kube/trait.md

@@ -37,18 +37,24 @@ Deploy the application and verify traits work.
 
 Check the `scaler` trait.
 ```shell
-$ kubectl get manualscalertrait
+kubectl get manualscalertrait
+```
+```console
 NAME                            AGE
 demo-podinfo-scaler-3x1sfcd34   2m
 ```
 ```shell
-$ kubectl get deployment mycomp -o json | jq .spec.replicas
+kubectl get deployment mycomp -o json | jq .spec.replicas
+```
+```console
 2
 ```
 
 Check the `virtualgroup` trait.
 ```shell
-$ kubectl get deployment mycomp -o json | jq .spec.template.metadata.labels
+kubectl get deployment mycomp -o json | jq .spec.template.metadata.labels
+```
+```console
 {
   "app.cluster.virtual.group": "my-group1",
   "app.kubernetes.io/name": "myapp"
@@ -91,19 +97,25 @@ Apply the new configuration and check the results after several seconds.
 
 Check the new property value.
 ```shell
-$ kubectl get deployment mycomp -o json | jq '.spec.template.spec.containers[0].image'
+kubectl get deployment mycomp -o json | jq '.spec.template.spec.containers[0].image'
+```
+```console
 "nginx:1.14.1"
 ```
 
 Check the `scaler` trait.
 ```shell
-$ kubectl get deployment mycomp -o json | jq .spec.replicas
+kubectl get deployment mycomp -o json | jq .spec.replicas
+```
+```console
 4
 ```
 
 Check the `virtualgroup` trait.
 ```shell
-$ kubectl get deployment mycomp -o json | jq .spec.template.metadata.labels
+kubectl get deployment mycomp -o json | jq .spec.template.metadata.labels
+```
+```console
 {
   "app.cluster.virtual.group": "my-group2",
   "app.kubernetes.io/name": "myapp"

docs/en/platform-engineers/openapi-v3-json-schema.md

@@ -9,17 +9,33 @@ KubeVela will automatically generate OpenAPI v3 JSON schema based on its paramet
 
 
 ## List Schema
-
-This `ConfigMap` will have a common label `definition.oam.dev=schema`, so you can find easily by:
-
+KubeVela support generate different versions of Component/Trait Definition.
+Thus, we use `ConfigMap` to store the parameter information of different versions of Definition.
+This `ConfigMap` will have a common label `definition.oam.dev=schema`, the default `ConfigMap` without a version suffix will point to the latest version,
+you can find easily by:
 ```shell
-$ kubectl get configmap -n vela-system -l definition.oam.dev=schema
-NAME                DATA   AGE
-schema-ingress      1      19s
-schema-scaler       1      19s
-schema-task         1      19s
-schema-webservice   1      19s
-schema-worker       1      20s
+kubectl get configmap -n vela-system -l definition.oam.dev=schema
+```
+```console
+NAME                   DATA     AGE
+schema-ingress         1        46m
+schema-scaler          1        50m
+schema-webservice      1        2m26s
+schema-webservice-v1   1        40s
+schema-worker          1        1m45s 
+schema-worker-v1       1        55s
+schema-worker-v2       1        20s
+```
+For the sack of convenience, we also specify a unified label for the `ConfigMap` which stores the parameter information of the same Definition. 
+And we can list the ConfigMap which stores the parameter of the same Definition by specifying the label like `definition.oam.dev/name=definitionName`, where the `definitionName` is the specific name of your component or trait. 
+```shell
+kubectl get configmap -l definition.oam.dev/name=worker
+```
+```console
+NAME                   DATA     AGE
+schema-worker          1        1m50s
+schema-worker-v1       1        1m
+schema-worker-v2       1        25s
 ```
 
 The `ConfigMap` name is in the format of `schema-<your-definition-name>`,
@@ -28,7 +44,9 @@ and the data key is `openapi-v3-json-schema`.
 For example, we can use the following command to get the JSON schema of `webservice`.
 
 ```shell
-$ kubectl get configmap schema-webservice -n vela-system -o yaml
+kubectl get configmap schema-webservice -n vela-system -o yaml
+```
+```console
 apiVersion: v1
 kind: ConfigMap
 metadata:

docs/en/platform-engineers/overview.md

@@ -121,8 +121,7 @@ metadata:
   name: hpa
 spec:
   appliesToWorkloads:
-    - webservice
-    - worker
+    - deployments.apps
   schematic:
     cue:
       template: |
@@ -168,8 +167,7 @@ metadata:
   name: sidecar
 spec:
   appliesToWorkloads:
-    - webservice
-    - worker
+    - deployments.apps
   schematic:
     cue:
       template: |-

docs/en/platform-engineers/terraform.md

@@ -10,10 +10,10 @@ These cloud services are provided by Terraform.
 
 <details>
 
-Download the latest chart, like `terraform-controller-chart-0.1.4.tgz`, from the latest [releases list](https://github.com/oam-dev/terraform-controller/releases) and install it.
+Download the latest chart, like `terraform-controller-chart-0.1.8.tgz`, from the latest [releases list](https://github.com/oam-dev/terraform-controller/releases) and install it.
 
 ```shell
-$ helm install terraform-controller terraform-controller-0.1.2.tgz
+$ helm install terraform-controller terraform-controller-0.1.8.tgz
 NAME: terraform-controller
 LAST DEPLOYED: Mon Apr 26 15:55:35 2021
 NAMESPACE: default
@@ -30,7 +30,7 @@ Please refer to [Terraform controller getting started](https://github.com/oam-de
 
 </details>
 
-## Register `alibaba-rds` Component
+### Register `alibaba-rds` Component
 
 Register [alibaba-rds](https://github.com/oam-dev/kubevela/tree/master/docs/examples/terraform/cloud-resource-provision-and-consume/ComponentDefinition-alibaba-rds.yaml) to KubeVela.
 
@@ -140,4 +140,4 @@ spec:
         }
 
 
-```
+```

docs/en/quick-start-appfile.md

@@ -15,7 +15,9 @@ Make sure you have finished and verified the installation following [this guide]
 ## Step 2: Deploy Your First Application
 
 ```bash
-$ vela up -f https://raw.githubusercontent.com/oam-dev/kubevela/master/docs/examples/vela.yaml
+vela up -f https://raw.githubusercontent.com/oam-dev/kubevela/master/docs/examples/vela.yaml
+```
+```console
 Parsing vela.yaml ...
 Loading templates ...
 
@@ -35,7 +37,9 @@ App has not been deployed, creating a new deployment...
 
 Check the status until we see `Routes` are ready:
 ```bash
-$ vela status first-vela-app
+vela status first-vela-app
+```
+```console
 About:
 
   Name:       first-vela-app
@@ -58,7 +62,9 @@ Services:
 **In [kind cluster setup](./install#kind)**, you can visit the service via localhost. In other setups, replace localhost with ingress address accordingly.
 
 ```
-$ curl -H "Host:testsvc.example.com" http://localhost/
+curl -H "Host:testsvc.example.com" http://localhost/
+```
+```console
 <xmp>
 Hello World
 

docs/en/quick-start.md

@@ -10,8 +10,10 @@ Make sure you have finished and verified the installation following [this guide]
 
 ## Step 2: Deploy Your First Application
 
-```bash
-$ kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/master/docs/examples/vela-app.yaml
+```bash script
+kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/master/docs/examples/vela-app.yaml
+```
+```console
 application.core.oam.dev/first-vela-app created
 ```
 
@@ -19,8 +21,10 @@ Above command will apply an application to KubeVela and let it distribute the ap
 
 Check the status until we see `status` is `running` and services are `healthy`:
 
-```bash
-$  kubectl get application first-vela-app -o yaml
+```bash script
+kubectl get application first-vela-app -o yaml
+```
+```console
 apiVersion: core.oam.dev/v1beta1
 kind: Application
 ...
@@ -38,8 +42,10 @@ status:
 
 You can now directly visit the application (regardless of where it is running).
 
+```bash script
+curl -H "Host:testsvc.example.com" http://<your ip address>/
 ```
-$ curl -H "Host:testsvc.example.com" http://<your ip address>/
+```console
 <xmp>
 Hello World
 
@@ -62,4 +68,4 @@ Here are some recommended next steps:
 
 - Learn KubeVela's [core concepts](./concepts)
 - Learn more details about [`Application`](end-user/application) and what it can do for you.
-- Learn how to attach [rollout plan](end-user/scopes/rollout-plan) to this application.
+- Learn how to attach [rollout plan](end-user/scopes/rollout-plan) to this application, or [place it to multiple runtime clusters](end-user/scopes/appdeploy).

docs/en/roadmap.md

@@ -1,5 +0,0 @@
----
-title:  KubeVela Roadmap
----
-
-Please visit [roadmap docs page](https://github.com/oam-dev/kubevela/tree/master/docs/en/roadmap/).

docs/en/roadmap/2021-06-roadmap.md

@@ -0,0 +1,36 @@
+---
+title:  Roadmap
+---
+
+Date: 2021-04-01 to 2021-06-30
+
+## Core Platform
+
+1. Implement Application serverside Kustomize and Workflow.
+2. KubeVela as a control plane.
+    - Application Controller deploy resources directly to remote clusters and instead of using AppContext
+    - AppRollout should be able to work in runtime cluster or rollout remote cluster resources
+3. Multi-cluster and Multi-environment support, applications can deploy in different environments which
+   contains different clusters with different strategies.
+4. Better Helm and Kustomize support, users can deploy a helm chart or a git repo directly without any more effort.
+5. Support built-in Application monitoring.
+6. Support more rollout strategies.
+    - blue-green
+    - traffic management rollout
+    - canary
+    - A/B
+7. Support a general CUE controller which can glue more than K8s CRDs, it should support more protocol such as restful API,
+   go function call, etc.
+8. Discoverable capability registries with more back integrations(file server/github/OSS).
+
+## User Experience
+
+1. Develop tools and CI integration.
+2. Refine our docs and website.
+
+## Third-party integrations
+
+1. Integrate with Open Cluster Management.
+2. Integrate with Flux CD
+3. Integrate with Dapr to enable end-to-end microservice application development and deployment workflow.
+4. Integrate with Tilt for local development.