fix release website (#1819)

add autoGenWorkloadDefinition option to choose whether to create workloaddef via webhook

.github/ISSUE_TEMPLATE/bug_report.md

@@ -15,9 +15,9 @@ A clear and concise description of what the bug is.
 **To Reproduce**
 <!--
 Steps to reproduce the behavior:
-1. Go to '...'
-2. Click on '....'
-3. Scroll down to '....'
+1. The YAML files of Component/Trait I used.
+2. The YAML file of Application I applied.
+3. Other operations I have done.
 4. See error
 -->
 
@@ -31,6 +31,12 @@ A clear and concise description of what you expected to happen.
 If applicable, add screenshots to help explain your problem.
 -->
 
+**KubeVela Version**
+
+<!--
+Describe your KubeVela controller or CLI version information.
+-->
+
 **Cluster information**
 <!--
 Describe your kubernetes cluster information.

.github/workflows/check-docs.yml

@@ -14,6 +14,11 @@ jobs:
       - uses: actions/setup-node@v1
         with:
           node-version: '12.x'
+      - uses: actions/setup-python@v2
+        with:
+          python-version: '3.7'
+      - name: Clean md files
+        run: python ./hack/website/format.py markdown ./docs/en
       - name: Test Build
         env:
           VERSION: ${{ github.ref }}

.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,87 +75,17 @@ 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
     if: needs.detect-noop.outputs.noop != 'true'
 
     steps:
+      - name: Setup Go
+        uses: actions/setup-go@v2
+        with:
+          go-version: ${{ env.GO_VERSION }}
+
       - name: Checkout
         uses: actions/checkout@v2
         with:
@@ -215,8 +98,11 @@ jobs:
           key: ${{ runner.os }}-pkg-${{ hashFiles('**/go.sum') }}
           restore-keys: ${{ runner.os }}-pkg-
 
+      - name: Install StaticCheck
+        run: GO111MODULE=off go get honnef.co/go/tools/cmd/staticcheck
+
       - name: Static Check
-        run: go run honnef.co/go/tools/cmd/staticcheck -- ./...
+        run: staticcheck ./...
 
       - name: License Header Check
         run: make check-license-header
@@ -283,14 +169,16 @@ 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
       - name: Run cross-build
         run: make cross-build
       - name: Run compress binary
-        run: make compress
+        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-docs.yaml

@@ -14,6 +14,11 @@ jobs:
       - uses: actions/setup-node@v1
         with:
           node-version: '12.x'
+      - uses: actions/setup-python@v2
+        with:
+          python-version: '3.7'
+      - name: Clean md files
+        run: python ./hack/website/format.py markdown ./docs/en
       - name: Sync to kubevela.io Repo
         env:
           SSH_DEPLOY_KEY: ${{ secrets.GH_PAGES_DEPLOY }}

.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/format.py markdown ./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

@@ -3,147 +3,62 @@
 ## About KubeVela
 
 KubeVela project is initialized and maintained by the cloud native community since day 0 with [bootstrapping contributors from 8+ different organizations](https://github.com/oam-dev/kubevela/graphs/contributors).
-We intend for KubeVela to have an open governance since the very beginning and donate the project to neutral foundation as soon as it's released. 
+We intend for KubeVela to have an open governance since the very beginning and donate the project to neutral foundation as soon as it's released.
+To help us create a safe and positive community experience for all, we require all participants to adhere to the [Code of Conduct](./CODE_OF_CONDUCT.md).
 
-This doc explains how to set up a development environment, so you can get started
-contributing to `kubevela` or build a PoC (Proof of Concept). 
+This document is a guide to help you through the process of contributing to KubeVela.
 
+## Become a contributor
 
-## Development
+You can contribute to KubeVela in several ways. Here are some examples:
 
-### Prerequisites
+* Contribute to the KubeVela codebase.
+* Report and triage bugs.
+* Develop community CRD operators as workload or trait and contribute to [catalog](https://github.com/oam-dev/catalog).
+* Write technical documentation and blog posts, for users and contributors.
+* Organize meetups and user groups in your local area.
+* Help others by answering questions about KubeVela.
 
-1. Golang version 1.13+
-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.
+For more ways to contribute, check out the [Open Source Guides](https://opensource.guide/how-to-contribute/).
 
-We also recommend you to learn about KubeVela's [design](https://kubevela.io/docs/concepts) before dive into its code.
+### Report bugs
 
-### Build
+Before submitting a new issue, try to make sure someone hasn't already reported the problem.
+Look through the [existing issues](https://github.com/oam-dev/kubevela/issues) for similar issues.
 
-* Clone this project
+Report a bug by submitting a [bug report](https://github.com/oam-dev/kubevela/issues/new?assignees=&labels=kind%2Fbug&template=bug_report.md&title=).
+Make sure that you provide as much information as possible on how to reproduce the bug.
 
-```shell script
-git clone git@github.com:oam-dev/kubevela.git
-```
+Follow the issue template and add additional information that will help us replicate the problem.
 
-KubeVela includes two parts, `vela core` and `vela cli`.
+#### Security issues
 
-- The `vela core` is actually a K8s controller, it will watch OAM Spec CRD and deploy resources.
-- The `vela cli` is a command line tool that can build, run apps(with the help of `vela core`).
+If you believe you've found a security vulnerability, please read our [security policy](https://github.com/oam-dev/kubevela/blob/master/SECURITY.md) for more details.
 
-For local development, we probably need to build both of them.
+### Suggest enhancements
 
-* Build Vela CLI
+If you have an idea to improve KubeVela, submit an [feature request](https://github.com/oam-dev/kubevela/issues/new?assignees=&labels=kind%2Ffeature&template=feature_request.md&title=%5BFeature%5D).
 
-```shell script
-make
-```
+### Triage issues
 
-After the vela cli built successfully, `make` command will create `vela` binary to `bin/` under the project.
+If you don't have the knowledge or time to code, consider helping with _issue triage_. The community will thank you for saving them time by spending some of yours.
 
-* Configure `vela` binary to System PATH
+Read more about the ways you can [Triage issues](/contribute/triage-issues.md).
 
-```shell script
-export PATH=$PATH:/your/path/to/project/kubevela/bin
-```
+### Answering questions
 
-Then you can use `vela` command directly.
+If you have a question and you can't find the answer in the [documentation](https://kubevela.io/docs/),
+the next step is to ask it on the [github discussion](https://github.com/oam-dev/kubevela/discussions).
 
-* Build Vela Core
+It's important to us to help these users, and we'd love your help. You can help other KubeVela users by answering [their questions](https://github.com/oam-dev/kubevela/discussions).
 
-```shell script
-make manager
-```
+### Your first contribution
 
-* Run Vela Core
+Unsure where to begin contributing to KubeVela? Start by browsing issues labeled `good first issue` or `help wanted`.
 
-Firstly make sure your cluster has CRDs, below is the command that can help install all CRDs.
+- [Good first issue](https://github.com/oam-dev/kubevela/labels/good%20first%20issue) issues are generally straightforward to complete.
+- [Help wanted](https://github.com/oam-dev/kubevela/labels/help%20wanted) issues are problems we would like the community to help us with regardless of complexity.
 
-```shell script
-make core-install
-```
+If you're looking to make a code change, see how to set up your environment for [local development](contribute/developer-guide.md).
 
-Run locally:
-
-```shell script
-make core-run
-```
-
-This command will run controller locally, it will use your local KubeConfig which means you need to have a k8s cluster
-locally. If you don't have a one, we suggest that you could setup up a cluster with [kind](https://kind.sigs.k8s.io/).
-
-When you're developing `vela-core`, make sure the controller installed by helm chart is not running.
-Otherwise, it will conflict with your local running controller.
-
-You can check and uninstall it by using helm.
-
-```shell script
-helm list -A
-helm uninstall -n vela-system kubevela
-```
-
-### Use
-
-You can try use your local built binaries follow [the documentation](https://kubevela.io/docs/quick-start).
-
-## Testing
-
-### Unit test
-
-```shell script
-make test
-```
-
-### E2E test
-
-**Before e2e test start, make sure you have vela-core running.**
-
-```shell script
-make core-run
-```
-
-Start to test.
-
-```
-make e2e-test
-```
-
-### Contribute Docs
-
-Please read [the documentation](https://github.com/oam-dev/kubevela/tree/master/docs/README.md) before contributing to the docs.
-
-- Build docs
-
-```shell script
-make docs-build
-```
-
-- Local development and preview
-
-```shell script
-make docs-start
-```
-
-## Make a pull request
-
-Remember to write unit-test and e2e-test after you have finished your code.
- 
-Run following checks before making a pull request.
-
-```shell script
-make reviewable
-```
-
-The command will do some lint checks and clean code.
-
-After that, check in all changes and send a pull request.
-
-## Merge Regulations
-
-Before merging, the pull request should obey the following rules:
-
-- The commit title and message should be clear about what this PR does.
-- All test CI should pass green.
-- The `codecov/project` should pass. This means the coverage should not drop. See [Codecov commit status](https://docs.codecov.io/docs/commit-status#project-status).
+When you're ready to contribute, it's time to [Create a pull request](/contribute/create-pull-request.md).

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

ISSUE_TRIAGE.md

@@ -0,0 +1,323 @@
+# Triage issues
+
+The main goal of issue triage is to categorize all incoming KubeVela issues and make sure each issue has all basic
+information needed for anyone else to understand and be able to start working on it.
+
+> **Note:** This information is for OAM/KubeVela project Maintainers, Owners, and Admins.
+>  If you are a Contributor, then you will not be able to perform most of the tasks in this topic.
+
+The core maintainers of the OAM/KubeVela project are responsible for categorizing all incoming issues and delegating
+any critical or important issue to other maintainers. Currently one maintainer each week is responsible.
+Besides that part, triage provides an important way to contribute to an open source project.
+
+Triage helps ensure issues resolve quickly by:
+
+- Ensuring the issue's intent and purpose is conveyed precisely. This is necessary because it can be difficult for
+  an issue to explain how an end user experiences a problem and what actions they took.
+- Giving a contributor the information they need before they commit to resolving an issue.
+- Lowering the issue count by preventing duplicate issues.
+- Streamlining the development process by preventing duplicate discussions.
+
+If you don't have the knowledge or time to code, consider helping with triage.
+The community will thank you for saving them time by spending some of yours.
+
+## Simplified flowchart diagram of the issue triage process
+
+<!-- https://textik.com/#908a27a44c590528 -->
+```
+                               +-----------------------------+                                                                                              
+                               |                             |                                                                                              
+                               |  New Issues Opened          |                                                                                              
+             +-----------------+                             |                                                                                              
+             |                 |  Or More information needed |                                                                                              
+             |                 |                             |                                                                                              
+             |                 +--------------+--------------+                                                                                              
+             |   Ask for more info            |                                                                                                             
+             |                                |                                                                                                             
+             |                 +--------------+------------+                                                                                                
+             |                 |                           |    Yes                                                                                         
+             |                 |  All informatio  needed   |                                                                                                
+             |     +-----------+  to categorize the issue？ +---------------+                                                                                
+             |     |   No      |                           |               |                                                                                
+             |     |           +---------------------------+               |                                                                                
+             |     |                                           +-----------+-----------+          +---------------------------+                             
++------------+-----+-----+                                     |                       |     Yes  |                           |                             
+|                        |                                     | Needs investigation ？ +---------+ label: needs investigation|                             
+| label: needs more info |                                     |                       |          |                           |                             
+|                        |                                     +----------+------------+          +-------------+-------------+                             
++------------------------+                                                |                                     |                                           
+                                                                          | No                                  |                                           
+                                                                          |                                     |                                           
+                                                               +----------+----------+       investigate        |                                           
+                                                               |   label: type/*     |                          |                                           
+                                                               |   label: area/*     +--------------------------+                                           
+                                                               |                     |                                                                      
+                                                               +--|-------------|----+                                                                      
+                                                                  |             |                Yes                                                        
+                                                                  |     +-------|-------------+     +-------------------+                                   
+                                                                  |     |  needs priority？    +----+ label: priority/* |                                   
+                                                                  |     +-------|-------------+     +----------|--------+                                   
+                                                                  |             | No                           |                                            
+                                                                  |             |                              |                                            
+                                                     +----- ------|---+      +--|----- --+                     |                                            
+                                                     | close issue    + ---- +    done   +---------------------+                                            
+                                                     +----------------+      +-----------+                                                                  
+```
+
+## 1. Find uncategorized issues
+
+To get started with issue triage and finding issues that haven't been triaged you have two alternatives.
+
+### Browse unlabeled issues
+
+The easiest and straight forward way of getting started and finding issues that haven't been triaged is to browse
+[unlabeled issues](https://github.com/oam-dev/kubevela/issues?q=is%3Aopen+is%3Aissue+no%3Alabel) and starting from
+the bottom and working yourself to the top.
+
+### Subscribe to all notifications
+
+The more advanced, but recommended way is to subscribe to all notifications from this repository which means that
+all new issues, pull requests, comments and important status changes are sent to your configured email address.
+Read this [guide](https://help.github.com/en/articles/watching-and-unwatching-repositories#watching-a-single-repository)
+for help with setting this up.
+
+It's highly recommended that you setup filters to automatically remove emails from the inbox and label/categorize
+them accordingly to make it easy for you to understand when you need to act upon a notification or where to look for
+finding issues that haven't been triaged etc.
+
+
+## 2. Ensure the issue contains basic information
+
+Before triaging an issue very far, make sure that the issue's author provided the standard issue information.
+This will help you make an educated recommendation on how to categorize the issue.
+The KubeVela project utilizes [GitHub issue templates](https://help.github.com/en/articles/creating-issue-templates-for-your-repository)
+to guide contributors to provide standard information that must be included for each type of template or type of issue.
+
+### Standard issue information that must be included
+
+Given a certain [issue template]([template](https://github.com/oam-dev/kubevela/issues/new/choose)) have been used
+by the issue author or depending how the issue is perceived by the issue triage responsible, the following should
+help you understand what standard issue information that must be included.
+
+#### Bug reports
+
+Should explain what happened, what was expected and how to reproduce it together with any additional information that
+may help giving a complete picture of what happened such as screenshots, application related YAMLs, and any environment
+related information that's applicable and/or maybe related to the reported problem:
+- KubeVela version
+- K8s cluster version KubeVela is installed on
+- Which other K8s CRD controllers used
+- Development environment like Go versions, if applicable
+
+#### Enhancement requests
+
+Should explain what enhancement or feature that the author wants to be added and why that is needed.
+
+### Good practices
+
+To make it easier for everyone to understand and find issues they're searching for it's suggested as a general rule of thumbs to:
+
+- Make sure that issue titles are named to explain the subject of the issue, has a correct spelling and doesn't include irrelevant information and/or sensitive information.
+- Make sure that issue descriptions doesn't include irrelevant information, information from template that haven't been filled out and/or sensitive information.
+- Do your best effort to change title and description or request suggested changes by adding a comment.
+
+> **Note:** Above rules is applicable to both new and existing issues of the KubeVela project.
+
+### Do you have all the information needed to categorize an issue?
+
+Depending on the issue, you might not feel all this information is needed. Use your best judgement.
+If you cannot triage an issue using what its author provided, explain kindly to the author that they must provide the
+above information to clarify the problem. Label issue with `needs more info` and add any related `area/*` or `type/*` labels.
+
+If the author provides the standard information but you are still unable to triage the issue, request additional information.
+Do this kindly and politely because you are asking for more of the author's time.
+
+If the author does not respond to the requested information within the timespan of a week,
+close the issue with a kind note stating that the author can request for the issue to be reopened when the necessary information is provided.
+
+When you feel you have all the information needed you're ready to [categorizing the issue](#3-categorizing-an-issue).
+
+If you receive a notification with additional information provided but you are not anymore on issue triage and
+you feel you do not have time to handle it, you should delegate it to the current person on issue triage.
+
+## 3. Categorizing an issue
+
+An issue can have multiple of the following labels. Typically, a properly categorized issue should at least have:
+
+- One label identifying its type (`type/*`).
+- One or multiple labels identifying the functional areas of interest or component (`area/*`), if applicable.
+
+| Label                    | Description                                                               |
+| ------------------------ | ------------------------------------------------------------------------- |
+| `type/bug`               | A feature isn't working as expected given design or documentation.        |
+| `type/enhancement`       | Request for a new feature or enhancement.                                 |
+| `type/docs`              | Documentation problem or enhancement.                                     |
+| `type/question`          | Issue is a question or is perceived as such.                              |
+| `type/duplicate`         | An existing issue of the same subject/request have already been reported. |
+| `type/wontfix`           | A reported bug works as intended/by design.                               |
+| `type/invalid`           | A reported bug with invalid usage.                                        |
+| `area/*`                 | Subject is related to a functional area of interest or component.         |
+
+### Duplicate issues
+
+Make sure it's not a duplicate by searching existing issues using related terms from the issue title and description.
+If you think you know there is an existing issue, but can't find it, please reach out to one of the maintainers and ask for help.
+If you identify that the issue is a duplicate of an existing issue:
+
+1. Add a comment `/duplicate of #<issue number>`. GitHub will recognize this and add some additional context to the issue activity.
+2. The KubeVela bot will do the rest, adding the correct label and closing comment
+3. Optionally add any related `area/*` labels.
+
+### Bug reports
+
+If it's not perfectly clear that it's an actual bug, quickly try to reproduce it.
+
+**It's a bug/it can be reproduced:**
+
+1. Add a comment describing detailed steps for how to reproduce it, if applicable.
+2. Label the issue `type/bug` and at least one `area/*` label.
+3. If you know that maintainers won't be able to put any resources into it for some time then label the issue
+   with `help wanted` and optionally `good first issue` together with pointers on which code to update to fix the bug.
+   This should signal to the community that we would appreciate any help we can get to resolve this.
+4. Move on to [prioritizing the issue](#4-prioritization-of-issues).
+
+**It can't be reproduced:**
+1. Either [ask for more information](#2-ensure-the-issue-contains-basic-information) needed to investigate it more thoroughly.
+2. Either [delegate further investigations](#investigation-of-issues) to someone else.
+
+**It works as intended/by design:**
+1. Kindly and politely add a comment explaining briefly why we think it works as intended and close the issue.
+2. Label the issue `type/wontfix`.
+
+### Enhancement/feature?
+
+1. Label the issue `type/enhancement` and at least one `area/*` label.
+2. Move on to [prioritizing the issue](#4-prioritization-of-issues).
+
+### Documentation issue?
+
+First, evaluate if the documentation makes sense to be included in the KubeVela project:
+
+- Is this something we want/can maintain as a project?
+- Is this referring to usage of some specific integration/tool and in that case is that a popular use case in combination with KubeVela?
+- If unsure, kindly and politely add a comment explaining that we would need [upvotes](https://help.github.com/en/articles/about-conversations-on-github#reacting-to-ideas-in-comments)
+  to identify that lots of other users want/need this.
+
+Second, label the issue `type/docs` and at least one `area/*` label.
+
+**Minor typo/error/lack of information:**
+
+There's a minor typo/error/lack of information that adds a lot of confusion for users and given the amount of work is a big win to make sure fixing it:
+1. Either update the documentation yourself and open a pull request.
+2. Either delegate the work to someone else by assigning that person to the issue and add the issue to next major/minor milestone.
+
+**Major error/lack of information:**
+
+1. Label the issue with `help wanted` and `good first issue`, if applicable, to signal that we find this important to
+   fix and we would appreciate any help we can get from the community.
+2. Move on to [prioritizing the issue](#4-prioritization-of-issues).
+
+### Support requests and questions
+
+1. Kindly and politely direct the issue author to the [github discussion](https://github.com/oam-dev/kubevela/discussions)
+   and explain that issue is mainly used for tracking bugs and feature requests.
+   If possible, it's usually a good idea to add some pointers to the issue author's question.
+2. Close the issue and label it with `type/question`.
+
+## 4. Prioritization of issues
+
+In general bugs and enhancement issues should be labeled with a priority.
+
+This is the most difficult thing with triaging issues since it requires a lot of knowledge, context and experience
+before being able to think of and start feel comfortable adding a certain priority label.
+
+The key here is asking for help and discuss issues to understand how more experienced project members think and reason.
+By doing that you learn more and eventually be more and more comfortable with prioritizing issues.
+
+In case there is an uncertainty around the prioritization of an issue, please ask the maintainers for help.
+
+| Label                             | Description                                                                                                              |
+| --------------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
+| `priority/critical`               | Highest priority. Must be actively worked on as someone's top priority right now.                                        |
+| `priority/important-soon`         | Must be staffed and worked on either currently, or very soon, ideally in time for the next release.                      |
+| `priority/important-longterm`     | Important over the long term, but may not be staffed and/or may need multiple releases to complete.                      |
+| `priority/nice-to-have`           | It's a good idea, but not scheduled for any release.                                                                     |
+| `priority/awaiting-more-evidence` | Lowest priority. Possibly useful, but not yet enough interest in it.                                                     |
+| `priority/unscheduled`            | Something to look into before and to be discussed during the planning of the next (upcoming) major/minor stable release. |
+
+**Critical bugs**
+
+1. If a bug has been categorized and any of the following criteria apply, the bug should be labeled as critical and
+   must be actively worked on as someone's top priority right now.
+
+    - Results in any crash or data loss.
+    - Critical security or performance issues
+    - Problem that makes a feature unusable
+    - Multiple users experience a severe problem affecting their business, users etc.
+
+2. Label the issue `priority/critical`.
+3. Add the issue to the next upcoming patch release milestone. Create a new milestone if there are none.
+4. Escalate the problem to the maintainers.
+5. Assign or ask a maintainer for help assigning someone to make this issue their top priority right now.
+
+**Important short-term**
+
+1. Label the issue `priority/important-soon`.
+2. Add the issue to the next upcoming patch or major/minor stable release milestone. Ask maintainers for help if unsure if it's a patch or not.
+   Create a new milestone if there are none.
+3. Make sure to add the issue to a suitable backlog of a GitHub project and prioritize it or assign someone to work on it now or very soon.
+4. Consider requesting [help from the community](#5-requesting-help-from-the-community), even though it may be problematic given a short amount of time until it should be released.
+
+**Important long-term**
+
+1. Label the issue `priority/important-longterm`.
+2. Consider requesting [help from the community](#5-requesting-help-from-the-community).
+
+**Nice to have**
+
+1. Label the issue `priority/nice-to-have`.
+2. Consider requesting [help from the community](#5-requesting-help-from-the-community).
+
+**Not critical, but unsure?**
+
+1. Label the issue `priority/unscheduled`.
+2. Consider requesting [help from the community](#5-requesting-help-from-the-community).
+
+## 5. Requesting help from the community
+
+Depending on the issue and/or priority, it's always a good idea to consider signalling to the community that help from community
+is appreciated and needed in case an issue is not prioritized to be worked on by maintainers. Use your best judgement.
+In general, requesting help from the community means that a contribution has a good chance of getting accepted and merged.
+
+1. Kindly and politely add a comment to signal to users subscribed to updates of the issue.
+    - Explain that the issue would be nice to get resolved, but it isn't prioritized to work on by maintainers for an unforeseen future.
+    - If possible or applicable, try to help contributors getting starting by adding pointers and references to
+      what code/files need to be changed and/or ideas of a good way to solve/implement the issue.
+2. Label the issue with `help wanted`.
+3. If applicable, label the issue with `good first issue` to denote that the issue is suitable for a beginner to work on.
+4. If possible, try to estimate the amount of work by adding `effort/small`, `effort/medium` or `effort/large`.
+
+## Investigation of issues
+
+When an issue has all basic information provided, but the triage responsible haven't been able to reproduce the reported
+problem at a first glance, the issue is labeled [Needs investigation](https://github.com/oam-dev/kubevela/labels/needs%20investigation).
+Depending on the perceived severity and/or number of [upvotes](https://help.github.com/en/articles/about-conversations-on-github#reacting-to-ideas-in-comments),
+the investigation will either be delegated to another maintainer for further investigation or put on hold until someone else (maintainer or contributor)
+picks it up and eventually starts investigating it.
+
+Investigating issues can be a very time consuming task, especially for the maintainers, provide as much related info will
+make it easier for maintainers to investigate.
+
+Even if you don't have the time or knowledge to investigate an issue we highly recommend that you [upvote](https://help.github.com/en/articles/about-conversations-on-github#reacting-to-ideas-in-comments)
+the issue if you happen to have the same problem. If you have further details that may help investigating the issue
+please provide as much information as possible.
+
+## Automation
+
+We have some automation that triggers on comments or labels being added to issues.
+Many of these automated behaviors are defined in [commands.json](https://github.com/oam-dev/kubevela/blob/main/.github/commands.json).
+
+* Add /duplicate `#<issue number>`  to have KubeVela label & close issue with an appropriate message.
+* Add `bot/question` and the bot will close it with an appropriate message.
+
+[Read more on bot actions](https://github.com/oam-dev/kubevela/blob/main/.github/bot.md)

Makefile

@@ -52,9 +52,7 @@ build: fmt vet lint staticcheck vela-cli kubectl-vela
 	@$(OK) build succeed
 
 vela-cli:
-	go run hack/chart/generate.go
 	$(GOBUILD_ENV) go build -o bin/vela -a -ldflags $(LDFLAGS) ./references/cmd/cli/main.go
-	git checkout references/cmd/cli/fake/chart_source.go
 
 kubectl-vela:
 	$(GOBUILD_ENV) go build -o bin/kubectl-vela -a -ldflags $(LDFLAGS) ./cmd/plugin/main.go
@@ -65,23 +63,17 @@ dashboard-build:
 doc-gen:
 	rm -r docs/en/cli/*
 	go run hack/docgen/gen.go
-	go run hack/references/generate.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
@@ -93,10 +85,9 @@ generate-source:
 
 cross-build:
 	rm -rf _bin
-	go run hack/chart/generate.go
+	go get github.com/mitchellh/gox@v0.4.0
 	$(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
-	git checkout references/cmd/cli/fake/chart_source.go
 
 compress:
 	( \
@@ -123,8 +114,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:
@@ -157,7 +149,7 @@ e2e-setup:
 	helm install --create-namespace -n flux-system helm-flux http://oam.dev/catalog/helm-flux2-0.1.0.tgz
 	helm install kruise https://github.com/openkruise/kruise/releases/download/v0.7.0/kruise-chart.tgz
 	sh ./hack/e2e/modify_charts.sh
-	helm upgrade --install --create-namespace --namespace vela-system --set image.pullPolicy=IfNotPresent --set image.repository=vela-core-test --set applicationRevisionLimit=5 --set image.tag=$(GIT_COMMIT) --wait kubevela ./charts/vela-core
+	helm upgrade --install --create-namespace --namespace vela-system --set image.pullPolicy=IfNotPresent --set image.repository=vela-core-test --set applicationRevisionLimit=5 --set dependCheckWait=10s --set image.tag=$(GIT_COMMIT) --wait kubevela ./charts/vela-core
 	ginkgo version
 	ginkgo -v -r e2e/setup
 	kubectl wait --for=condition=Ready pod -l app.kubernetes.io/name=vela-core,app.kubernetes.io/instance=kubevela -n vela-system --timeout=600s
@@ -233,12 +225,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

@@ -14,27 +14,21 @@
 
 # KubeVela
 
-*Developers simply want to deploy.*
-
-Traditional *Platform-as-a-Service (PaaS)* systems enable easy application deployments, but this happiness disappears when your application outgrows the capabilities of your platform. This is inevitable regardless of your PaaS is built on Kubernetes or not - the root cause is its inflexibility.
-
-KubeVela is a modern application platform that is fully self-service, and adapts to your needs when you grow.
-
-Leveraging Kubernetes as control plane, KubeVela itself is runtime agnostic. It allows you to deploy (and manage) containerized workloads, cloud functions, databases, or even EC2 instances with a consistent workflow.
+KubeVela is a modern application platform that makes deploying and managing applications across today's hybrid, multi-cloud environments easier and faster.
 
 ## Features
 
-**Developer Centric** - KubeVela introduces higher level API to capture a full deployment of microservices, and builds features around the application needs only. Progressive rollout and multi-cluster deployment are provided out-of-box. No infrastructure level concerns, simply deploy.
+**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.
 
-**Self-service** - KubeVela models platform features (such as workloads, operational behaviors, and cloud services) as reusable [CUE](https://github.com/cuelang/cue) and/or [Helm](https://helm.sh/) components, and expose them to end users as self-service building blocks. When your needs grow, these capabilities can extend naturally in a 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.
 
-**Simple yet Reliable** - KubeVela is built with Kubernetes as control plane so unlike traditional X-as-Code solutions, it never leaves configuration drift in your clusters. Also, this makes KubeVela work with any CI/CD or GitOps tools via declarative API without any integration burden.
+**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.
 
 ## Getting Started
 
+- [Introduction](https://kubevela.io/docs)
 - [Installation](https://kubevela.io/docs/install)
-- [Quick start](https://kubevela.io/docs/quick-start)
-- [How it works](https://kubevela.io/docs/concepts)
+- [Deploy an Application](https://kubevela.io/docs/application)
 
 ## Documentation
 
@@ -58,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

@@ -14,8 +14,16 @@ See the License for the specific language governing permissions and
 limitations under the License.
 */
 
-package fake
+package types
 
-// ChartSource is a base64-encoded, gzipped tarball of the default Helm chart(charts/vela-core).
-// Its value is initialized at build time. This whole file will be rewrite at that time, please don't change this file.
-var ChartSource string
+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

@@ -138,5 +138,55 @@ webhooks:
           - UPDATE
         resources:
           - podspecworkloads
-
+  - clientConfig:
+      caBundle: Cg==
+      service:
+        name: {{ template "kubevela.name" . }}-webhook
+        namespace: {{ .Release.Namespace }}
+        path: /validating-core-oam-dev-v1beta1-applications
+    {{- if .Values.admissionWebhooks.patch.enabled  }}
+    failurePolicy: Ignore
+    {{- else }}
+    failurePolicy: {{ .Values.admissionWebhooks.failurePolicy }}
+    {{- end }}
+    name: validating.core.oam.dev.v1beta1.applications
+    admissionReviewVersions:
+      - v1beta1
+    sideEffects: None
+    rules:
+      - apiGroups:
+          - core.oam.dev
+        apiVersions:
+          - v1beta1
+        operations:
+          - CREATE
+          - 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

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

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

@@ -3,17 +3,16 @@ apiVersion: core.oam.dev/v1beta1
 kind: TraitDefinition
 metadata:
   annotations:
-    definition.oam.dev/description: "configure k8s HPA with CPU metrics for Deployment"
+    definition.oam.dev/description: "Automatically scale the component based on CPU usage."
   name: cpuscaler
   namespace: {{.Values.systemDefinitionNamespace}}
 spec:
   appliesToWorkloads:
-    - webservice
-    - worker
+    - deployments.apps
   schematic:
     cue:
       template: |
-        outputs: cpuhpa: {
+        outputs: cpuscaler: {
         	apiVersion: "autoscaling/v2beta2"
         	kind:       "HorizontalPodAutoscaler"
         	metadata: name: context.name

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

@@ -3,8 +3,7 @@ apiVersion: core.oam.dev/v1beta1
 kind: TraitDefinition
 metadata:
   annotations:
-    definition.oam.dev/description: "Configures K8s ingress and service to enable web traffic for your service.
-    Please use route trait in cap center for advanced usage."
+    definition.oam.dev/description: "Enable public web traffic for the component."
   name: ingress
   namespace: {{.Values.systemDefinitionNamespace}}
 spec:
@@ -25,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

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

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

@@ -3,13 +3,12 @@ apiVersion: core.oam.dev/v1beta1
 kind: TraitDefinition
 metadata:
   annotations:
-    definition.oam.dev/description: "Configures replicas for your service by patch replicas field."
+    definition.oam.dev/description: "Manually scale the component."
   name: scaler
   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

@@ -3,13 +3,12 @@ apiVersion: core.oam.dev/v1beta1
 kind: TraitDefinition
 metadata:
   annotations:
-    definition.oam.dev/description: "inject a sidecar container into your app"
+    definition.oam.dev/description: "Inject a sidecar container to the component."
   name: sidecar
   namespace: {{.Values.systemDefinitionNamespace}}
 spec:
   appliesToWorkloads:
-    - webservice
-    - worker
+    - deployments.apps
   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

@@ -107,10 +107,18 @@ spec:
           args:
             - "--metrics-addr=:8080"
             - "--enable-leader-election"
+            {{ if ne .Values.logFilePath "" }}
+            - "--log-file-path={{ .Values.logFilePath }}"
+            - "--log-file-max-size={{ .Values.logFileMaxSize }}"
+            {{ end }}
+            {{ if .Values.logDebug }}
+            - "--log-debug=true"
+            {{ end }}
             {{ if .Values.admissionWebhooks.enabled }}
             - "--use-webhook=true"
             - "--webhook-port={{ .Values.webhookService.port }}"
             - "--webhook-cert-dir={{ .Values.admissionWebhooks.certificate.mountPath }}"
+            - "--autogen-workload-definition={{ .Values.admissionWebhooks.autoGenWorkloadDefinition }}"
             {{ end }}
             {{ if not .Values.useAppConfig }}
             - "--app-config-installed=false"
@@ -170,4 +178,4 @@ spec:
       {{- with .Values.tolerations }}
       tolerations:
     {{- toYaml . | nindent 8 }}
-  {{- end }}
+  {{- end }}

charts/vela-core/values.yaml

@@ -77,10 +77,27 @@ admissionWebhooks:
     tolerations: []
   certManager:
     enabled: false
+  # If autoGenWorkloadDefinition is true, webhook will auto generated workloadDefinition which componentDefinition refers to
+  autoGenWorkloadDefinition: true
 
+#Enable debug logs for development purpose
+logDebug: false
+
+#If non-empty, write log files in this path
+logFilePath: ""
+
+#Defines the maximum size a log file can grow to. Unit is megabytes.
+#If the value is 0, the maximum file size is unlimited.
+logFileMaxSize: 1024
 
 systemDefinitionNamespace: vela-system
 
 applicationRevisionLimit: 10
 
 definitionRevisionLimit: 20
+
+# concurrentReconciles is the concurrent reconcile number of the controller
+concurrentReconciles: 4
+
+# dependCheckWait is the time to wait for ApplicationConfiguration's dependent-resource ready
+dependCheckWait: 30s

cmd/core/main.go

@@ -27,18 +27,16 @@ import (
 	"strings"
 	"time"
 
-	"github.com/crossplane/crossplane-runtime/pkg/logging"
-	"go.uber.org/zap/zapcore"
-	"gopkg.in/natefinch/lumberjack.v2"
+	"k8s.io/klog/v2"
 	ctrl "sigs.k8s.io/controller-runtime"
 	"sigs.k8s.io/controller-runtime/pkg/healthz"
-	"sigs.k8s.io/controller-runtime/pkg/log/zap"
 
 	standardcontroller "github.com/oam-dev/kubevela/pkg/controller"
+	commonconfig "github.com/oam-dev/kubevela/pkg/controller/common"
 	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"
@@ -53,7 +51,6 @@ const (
 )
 
 var (
-	setupLog           = ctrl.Log.WithName(kubevelaName)
 	scheme             = common.Scheme
 	waitSecretTimeout  = 90 * time.Second
 	waitSecretInterval = 2 * time.Second
@@ -61,8 +58,8 @@ var (
 
 func main() {
 	var metricsAddr, logFilePath, leaderElectionNamespace string
-	var enableLeaderElection, logCompress, logDebug bool
-	var logRetainDate int
+	var enableLeaderElection, logDebug bool
+	var logFileMaxSize uint64
 	var certDir string
 	var webhookPort int
 	var useWebhook bool
@@ -82,8 +79,7 @@ func main() {
 	flag.StringVar(&leaderElectionNamespace, "leader-election-namespace", "",
 		"Determines the namespace in which the leader election configmap will be created.")
 	flag.StringVar(&logFilePath, "log-file-path", "", "The file to write logs to.")
-	flag.IntVar(&logRetainDate, "log-retain-date", 7, "The number of days of logs history to retain.")
-	flag.BoolVar(&logCompress, "log-compress", true, "Enable compression on the rotated logs.")
+	flag.Uint64Var(&logFileMaxSize, "log-file-max-size", 1024, "Defines the maximum size a log file can grow to, Unit is megabytes.")
 	flag.BoolVar(&logDebug, "log-debug", false, "Enable debug logs for development purpose")
 	flag.IntVar(&controllerArgs.RevisionLimit, "revision-limit", 50,
 		"RevisionLimit is the maximum number of revisions that will be maintained. The default value is 50.")
@@ -95,6 +91,7 @@ func main() {
 		"custom-revision-hook-url is a webhook url which will let KubeVela core to call with applicationConfiguration and component info and return a customized component revision")
 	flag.BoolVar(&controllerArgs.ApplicationConfigurationInstalled, "app-config-installed", true,
 		"app-config-installed indicates if applicationConfiguration CRD is installed")
+	flag.BoolVar(&controllerArgs.AutoGenWorkloadDefinition, "autogen-workload-definition", true, "Automatic generated workloadDefinition which componentDefinition refers to.")
 	flag.StringVar(&healthAddr, "health-addr", ":9440", "The address the health endpoint binds to.")
 	flag.StringVar(&applyOnceOnly, "apply-once-only", "false",
 		"For the purpose of some production environment that workload or trait should not be affected if no spec change, available options: on, off, force.")
@@ -103,29 +100,26 @@ func main() {
 	flag.DurationVar(&syncPeriod, "informer-re-sync-interval", 60*time.Minute,
 		"controller shared informer lister full re-sync period")
 	flag.StringVar(&oam.SystemDefinitonNamespace, "system-definition-namespace", "vela-system", "define the namespace of the system-level definition")
-	flag.Parse()
+	flag.IntVar(&controllerArgs.ConcurrentReconciles, "concurrent-reconciles", 4, "concurrent-reconciles is the concurrent reconcile number of the controller. The default value is 4")
+	flag.DurationVar(&controllerArgs.DependCheckWait, "depend-check-wait", 30*time.Second, "depend-check-wait is the time to wait for ApplicationConfiguration's dependent-resource ready."+
+		"The default value is 30s, which means if dependent resources were not prepared, the ApplicationConfiguration would be reconciled after 30s.")
 
+	flag.Parse()
 	// setup logging
-	var w io.Writer
-	if len(logFilePath) > 0 {
-		w = zapcore.AddSync(&lumberjack.Logger{
-			Filename: logFilePath,
-			MaxAge:   logRetainDate, // days
-			Compress: logCompress,
-		})
-	} else {
-		w = os.Stdout
+	klog.InitFlags(nil)
+	if logDebug {
+		_ = flag.Set("v", strconv.Itoa(int(commonconfig.LogDebug)))
 	}
 
-	logger := zap.New(func(o *zap.Options) {
-		o.Development = logDebug
-		o.DestWritter = w
-	})
-	ctrl.SetLogger(logger)
+	if logFilePath != "" {
+		_ = flag.Set("logtostderr", "false")
+		_ = flag.Set("log_file", logFilePath)
+		_ = flag.Set("log_file_max_size", strconv.FormatUint(logFileMaxSize, 10))
+	}
 
-	setupLog.Info(fmt.Sprintf("KubeVela Version: %s, GIT Revision: %s.", version.VelaVersion, version.GitRevision))
-	setupLog.Info(fmt.Sprintf("Disable Capabilities: %s.", disableCaps))
-	setupLog.Info(fmt.Sprintf("core init with definition namespace %s", oam.SystemDefinitonNamespace))
+	klog.InfoS("KubeVela information", "version", version.VelaVersion, "revision", version.GitRevision)
+	klog.InfoS("Disable capabilities", "name", disableCaps)
+	klog.InfoS("Vela-Core init", "definition namespace", oam.SystemDefinitonNamespace)
 
 	restConfig := ctrl.GetConfigOrDie()
 	restConfig.UserAgent = kubevelaName + "/" + version.GitRevision
@@ -142,93 +136,96 @@ func main() {
 		SyncPeriod:              &syncPeriod,
 	})
 	if err != nil {
-		setupLog.Error(err, "unable to create a controller manager")
+		klog.ErrorS(err, "Unable to create a controller manager")
 		os.Exit(1)
 	}
 
 	if err := registerHealthChecks(mgr); err != nil {
-		setupLog.Error(err, "unable to register ready/health checks")
+		klog.ErrorS(err, "Unable to register ready/health checks")
 		os.Exit(1)
 	}
 
 	if err := utils.CheckDisabledCapabilities(disableCaps); err != nil {
-		setupLog.Error(err, "unable to get enabled capabilities")
+		klog.ErrorS(err, "Unable to get enabled capabilities")
 		os.Exit(1)
 	}
 
 	switch strings.ToLower(applyOnceOnly) {
 	case "", "false", string(oamcontroller.ApplyOnceOnlyOff):
 		controllerArgs.ApplyMode = oamcontroller.ApplyOnceOnlyOff
-		setupLog.Info("ApplyOnceOnly is disabled")
+		klog.Info("ApplyOnceOnly is disabled")
 	case "true", string(oamcontroller.ApplyOnceOnlyOn):
 		controllerArgs.ApplyMode = oamcontroller.ApplyOnceOnlyOn
-		setupLog.Info("ApplyOnceOnly is enabled, that means workload or trait only apply once if no spec change even they are changed by others")
+		klog.Info("ApplyOnceOnly is enabled, that means workload or trait only apply once if no spec change even they are changed by others")
 	case string(oamcontroller.ApplyOnceOnlyForce):
 		controllerArgs.ApplyMode = oamcontroller.ApplyOnceOnlyForce
-		setupLog.Info("ApplyOnceOnlyForce is enabled, that means workload or trait only apply once if no spec change even they are changed or deleted by others")
+		klog.Info("ApplyOnceOnlyForce is enabled, that means workload or trait only apply once if no spec change even they are changed or deleted by others")
 	default:
-		setupLog.Error(fmt.Errorf("invalid apply-once-only value: %s", applyOnceOnly),
-			"unable to setup the vela core controller",
-			"valid apply-once-only value:", "on/off/force, by default it's off")
+		klog.ErrorS(fmt.Errorf("invalid apply-once-only value: %s", applyOnceOnly),
+			"Unable to setup the vela core controller",
+			"apply-once-only", "on/off/force, by default it's off")
 		os.Exit(1)
 	}
 
 	dm, err := discoverymapper.New(mgr.GetConfig())
 	if err != nil {
-		setupLog.Error(err, "failed to create CRD discovery client")
+		klog.ErrorS(err, "Failed to create CRD discovery client")
 		os.Exit(1)
 	}
 	controllerArgs.DiscoveryMapper = dm
-	pd, err := definition.NewPackageDiscover(mgr.GetConfig())
+	pd, err := packages.NewPackageDiscover(mgr.GetConfig())
 	if err != nil {
-		setupLog.Error(err, "failed to create CRD discovery for CUE package client")
-		if !definition.IsCUEParseErr(err) {
+		klog.Error(err, "Failed to create CRD discovery for CUE package client")
+		if !packages.IsCUEParseErr(err) {
 			os.Exit(1)
 		}
 	}
 	controllerArgs.PackageDiscover = pd
 
 	if useWebhook {
-		setupLog.Info("vela webhook enabled, will serving at :" + strconv.Itoa(webhookPort))
+		klog.InfoS("Enable webhook", "server port", strconv.Itoa(webhookPort))
 		oamwebhook.Register(mgr, controllerArgs)
 		velawebhook.Register(mgr, disableCaps)
 		if err := waitWebhookSecretVolume(certDir, waitSecretTimeout, waitSecretInterval); err != nil {
-			setupLog.Error(err, "unable to get webhook secret")
+			klog.ErrorS(err, "Unable to get webhook secret")
 			os.Exit(1)
 		}
 	}
 
-	if err = oamv1alpha2.Setup(mgr, controllerArgs, logging.NewLogrLogger(setupLog)); err != nil {
-		setupLog.Error(err, "unable to setup the oam core controller")
+	if err = oamv1alpha2.Setup(mgr, controllerArgs); err != nil {
+		klog.ErrorS(err, "Unable to setup the oam core controller")
 		os.Exit(1)
 	}
 
 	if err = standardcontroller.Setup(mgr, disableCaps); err != nil {
-		setupLog.Error(err, "unable to setup the vela core controller")
+		klog.ErrorS(err, "Unable to setup the vela core controller")
 		os.Exit(1)
 	}
 	if driver := os.Getenv(system.StorageDriverEnv); len(driver) == 0 {
 		// first use system environment,
 		err := os.Setenv(system.StorageDriverEnv, storageDriver)
 		if err != nil {
-			setupLog.Error(err, "unable to setup the vela core controller")
+			klog.ErrorS(err, "Unable to setup the vela core controller")
 			os.Exit(1)
 		}
 	}
-	setupLog.Info("use storage driver", "storageDriver", os.Getenv(system.StorageDriverEnv))
+	klog.InfoS("Use storage driver", "storageDriver", os.Getenv(system.StorageDriverEnv))
 
-	setupLog.Info("starting the vela controller manager")
+	klog.Info("Start the vela controller manager")
 
 	if err := mgr.Start(ctrl.SetupSignalHandler()); err != nil {
-		setupLog.Error(err, "problem running manager")
+		klog.ErrorS(err, "Failed to run manager")
 		os.Exit(1)
 	}
-	setupLog.Info("program safely stops...")
+	if logFilePath != "" {
+		klog.Flush()
+	}
+	klog.Info("Safely stops Program...")
 }
 
 // registerHealthChecks is used to create readiness&liveness probes
 func registerHealthChecks(mgr ctrl.Manager) error {
-	setupLog.Info("creating readiness/health check")
+	klog.Info("Create readiness/health check")
 	if err := mgr.AddReadyzCheck("ping", healthz.Ping); err != nil {
 		return err
 	}
@@ -247,8 +244,8 @@ func waitWebhookSecretVolume(certDir string, timeout, interval time.Duration) er
 		if time.Since(start) > timeout {
 			return fmt.Errorf("getting webhook secret timeout after %s", timeout.String())
 		}
-		setupLog.Info(fmt.Sprintf("waiting webhook secret, time consumed: %d/%d seconds ...",
-			int64(time.Since(start).Seconds()), int64(timeout.Seconds())))
+		klog.InfoS("Wait webhook secret", "time consumed(second)", int64(time.Since(start).Seconds()),
+			"timeout(second)", int64(timeout.Seconds()))
 		if _, err := os.Stat(certDir); !os.IsNotExist(err) {
 			ready := func() bool {
 				f, err := os.Open(filepath.Clean(certDir))
@@ -270,8 +267,8 @@ func waitWebhookSecretVolume(certDir string, timeout, interval time.Duration) er
 					return nil
 				})
 				if err == nil {
-					setupLog.Info(fmt.Sprintf("webhook secret is ready (time consumed: %d seconds)",
-						int64(time.Since(start).Seconds())))
+					klog.InfoS("Webhook secret is ready", "time consumed(second)",
+						int64(time.Since(start).Seconds()))
 					return true
 				}
 				return false

contribute/README.md

@@ -0,0 +1,8 @@
+# Contribute
+
+This directory contains guides for contributors to the KubeVela project.
+
+* [Create a pull request](./create-pull-request.md)
+* [Developer guide](./developer-guide.md)
+* [Triage issues](./triage-issues.md)
+* [Code conventions](./coding-conventions.md)

contribute/coding-conventions.md

@@ -0,0 +1,162 @@
+# KubeVela code conventions
+
+- Bash
+
+  - https://google.github.io/styleguide/shell.xml
+
+  - Ensure that build, release, test, and cluster-management scripts run on
+    macOS
+
+- Go
+
+  - [Go Code Review Comments](https://github.com/golang/go/wiki/CodeReviewComments)
+
+  - [Effective Go](https://golang.org/doc/effective_go.html)
+
+  - Know and avoid [Go landmines](https://gist.github.com/lavalamp/4bd23295a9f32706a48f)
+
+  - Comment your code.
+    - [Go's commenting conventions](http://blog.golang.org/godoc-documenting-go-code)
+    - If reviewers ask questions about why the code is the way it is, that's a
+      sign that comments might be helpful.
+
+  - Command-line flags should use dashes, not underscores
+
+  - Naming
+    - Please consider package name when selecting an interface name, and avoid
+      redundancy.
+
+      - e.g.: `storage.Interface` is better than `storage.StorageInterface`.
+
+    - Do not use uppercase characters, underscores, or dashes in package
+      names.
+    - Please consider parent directory name when choosing a package name.
+
+      - so pkg/controllers/autoscaler/foo.go should say `package autoscaler`
+        not `package autoscalercontroller`.
+      - Unless there's a good reason, the `package foo` line should match
+        the name of the directory in which the .go file exists.
+      - Importers can use a different name if they need to disambiguate.
+
+    - Locks should be called `lock` and should never be embedded (always `lock
+      sync.Mutex`). When multiple locks are present, give each lock a distinct name
+      following Go conventions - `stateLock`, `mapLock` etc.
+
+- KubeVela also follows the Kubernetes conventions
+
+  - [API changes](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md)
+
+  - [API conventions](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md)
+  
+## Testing conventions
+
+- All new packages and most new significant functionality must come with unit
+  tests
+
+- Table-driven tests are preferred for testing multiple scenarios/inputs; for
+  example, see [TestNamespaceAuthorization](https://git.k8s.io/kubernetes/test/integration/auth/auth_test.go)
+  
+- Unit tests must pass on macOS and Windows platforms - if you use Linux
+  specific features, your test case must either be skipped on windows or compiled
+  out (skipped is better when running Linux specific commands, compiled out is
+  required when your code does not compile on Windows).
+
+- Avoid relying on Docker hub (e.g. pull from Docker hub). Use gcr.io instead.
+
+- Avoid waiting for a short amount of time (or without waiting) and expect an
+  asynchronous thing to happen (e.g. wait for 1 seconds and expect a Pod to be
+  running). Wait and retry instead.
+
+- Significant features should come with integration (test/integration) and/or
+  end-to-end (e2e/) tests. TOOD(@wonderflow): add detail test guides.
+  - Including new vela cli commands and major features of existing commands
+
+
+## Directory and file conventions
+
+- Avoid package sprawl. Find an appropriate subdirectory for new packages.
+  - Libraries with no more appropriate home belong in new package
+    subdirectories of pkg/util
+
+- Avoid general utility packages. Packages called "util" are suspect. Instead,
+  derive a name that describes your desired function. For example, the utility
+  functions dealing with waiting for operations are in the "wait" package and
+  include functionality like Poll. So the full name is wait.Poll
+
+- All filenames should be lowercase
+
+- Go source files and directories use underscores, not dashes
+  - Package directories should generally avoid using separators as much as
+    possible (when packages are multiple words, they usually should be in nested
+    subdirectories).
+
+- Document directories and filenames should use dashes rather than underscores
+
+- Contrived examples that illustrate system features belong in
+  /docs/user-guide or /docs/admin, depending on whether it is a feature primarily
+  intended for users that deploy applications or cluster administrators,
+  respectively. Actual application examples belong in /examples.
+  - Examples should also illustrate [best practices for configuration and using the system](https://kubernetes.io/docs/concepts/configuration/overview/)
+
+- Third-party code
+
+  - Go code for normal third-party dependencies is managed using
+    [go modules](https://github.com/golang/go/wiki/Modules)
+
+  - Other third-party code belongs in `/third_party`
+    - forked third party Go code goes in `/third_party/forked`
+    - forked _golang stdlib_ code goes in `/third_party/forked/golang`
+
+  - Third-party code must include licenses
+
+  - This includes modified third-party code and excerpts, as well
+  
+## Logging Conventions
+
+### Structured logging
+
+We recommend using `klog.InfoS` to structure the log. The `msg` argument need start from a capital letter.
+and name arguments should always use lowerCamelCase.
+
+```golang
+// func InfoS(msg string, keysAndValues ...interface{})
+klog.InfoS("Reconcile traitDefinition", "traitDefinition", klog.KRef(req.Namespace, req.Name))
+// output:
+// I0605 10:10:57.308074   22276 traitdefinition_controller.go:59] "Reconcile traitDefinition" traitDefinition="vela-system/expose"
+```
+
+### Use `klog.KObj` and `klog.KRef` for Kubernetes objects
+
+`klog.KObj` and `klog.KRef` can unify the output of kubernetes object.
+
+```golang
+// KObj is used to create ObjectRef when logging information about Kubernetes objects
+klog.InfoS("Start to reconcile", "appDeployment", klog.KObj(appDeployment))
+// KRef is used to create ObjectRef when logging information about Kubernetes objects without access to metav1.Object
+klog.InfoS("Reconcile application", "application", klog.KRef(req.Namespace, req.Name))
+```
+
+### Logging Level
+
+[This file](https://github.com/oam-dev/kubevela/blob/master/pkg/controller/common/logs.go) contains KubeVela's log level,
+you can set the log level by `klog.V(level)`.
+
+```golang
+// you can use klog.V(common.LogDebug) to print debug log
+klog.V(common.LogDebug).InfoS("Successfully applied components", "workloads", len(workloads))
+```
+
+Looking for more details in [Structured Logging Guide](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/migration-to-structured-logging.md#structured-logging-in-kubernetes).
+
+
+## Linting and formatting
+
+To ensure consistency across the Go codebase, we require all code to pass a number of linter checks.
+
+To run all linters, use the `reviewable` Makefile target:
+
+```shell script
+make reviewable
+```
+
+The command will clean code along with some lint checks. Please remember to check in all changes after that.

contribute/create-pull-request.md

@@ -0,0 +1,86 @@
+# Create a pull request
+
+We're excited that you're considering making a contribution to the KubeVela project!
+This document guides you through the process of creating a [pull request](https://help.github.com/en/articles/about-pull-requests/).
+
+## Before you begin
+
+We know you're excited to create your first pull request. Before we get started, read these resources first:
+
+- Learn how to start [Contributing to KubeVela](/CONTRIBUTING.md).
+- Make sure your code follows the relevant [style guides](/contribute/style-guides).
+
+## Your first pull request
+
+If this is your first time contributing to an open-source project on GitHub, make sure you read about [Creating a pull request](https://help.github.com/en/articles/creating-a-pull-request).
+
+To increase the chance of having your pull request accepted, make sure your pull request follows these guidelines:
+
+- Title and description matches the implementation.
+- Commits within the pull request follow the [Formatting guidelines](#Formatting-guidelines).
+- The pull request closes one related issue.
+- The pull request contains necessary tests that verify the intended behavior.
+- If your pull request has conflicts, rebase your branch onto the main branch.
+
+If the pull request fixes a bug:
+
+- The pull request description must include `Closes #<issue number>` or `Fixes #<issue number>`.
+- To avoid regressions, the pull request should include tests that replicate the fixed bug.
+
+Please refer to the [code conventions](/contribute/coding-conventions.md) for better code style and conventions.
+
+## Code review
+
+Once you've created a pull request, the next step is to have someone review your change.
+A review is a learning opportunity for both the reviewer and the author of the pull request.
+
+If you think a specific person needs to review your pull request, then you can tag them in the description or in a comment.
+Tag a user by typing the `@` symbol followed by their GitHub username.
+
+We recommend that you read [How to do a code review](https://google.github.io/eng-practices/review/reviewer/) to learn more about code reviews.
+
+## Formatting guidelines
+
+A well-written pull request minimizes the time to get your change accepted.
+These guidelines help you write good commit messages and descriptions for your pull requests.
+
+### Commit message format
+
+KubeVela uses the guidelines for commit messages outlined in [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/), with the following additions:
+
+- Subject line must begin with the _area_ of the commit.
+- A footer in the form of an optional [keyword and issue reference](https://help.github.com/en/articles/closing-issues-using-keywords).
+
+#### Area
+
+The area should use upper camel case, e.g. UpperCamelCase.
+
+Prefer using one of the following areas:
+
+- **Application:** Changes to the application controller.
+- **Component:** Changes to the component related code or definition controller.
+- **Trait:** Changes to the trait related code or definition controller.
+- **CUE:** Changes to the CUE related logic.
+- **Docs:** Changes to documentation.
+- **AppConfig:** Changes to AppConfig related code.
+
+**Examples**
+
+- `Application: Support workflow in application controller`
+- `CUE: Fix patch parse issues`
+- `Docs: Changed url to URL in all documentation files`
+
+### Pull request titles
+
+The KubeVela team _squashes_ all commits into one when we accept a pull request.
+The title of the pull request becomes the subject line of the squashed commit message.
+We still encourage contributors to write informative commit messages, as they become a part of the Git commit body.
+
+We use the pull request title when we generate change logs for releases. As such, we strive to make the title as informative as possible.
+
+Make sure that the title for your pull request uses the same format as the subject line in the commit message.
+
+### Pass all the CI checks
+
+Before merge, All test CI should pass green.
+The `codecov/project` should also pass. This means the coverage should not drop. See [Codecov commit status](https://docs.codecov.io/docs/commit-status#project-status).

contribute/developer-guide.md

@@ -0,0 +1,145 @@
+# Developer guide
+
+This guide helps you get started developing KubeVela.
+
+## Prerequisites
+
+1. Golang version 1.16+
+2. Kubernetes version v1.18+ with `~/.kube/config` configured.
+3. ginkgo 1.14.0+ (just for [E2E test](./developer-guide.md#e2e-test))
+4. golangci-lint 1.38.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+
+
+<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>
+
+You may also be interested with KubeVela's [design](https://github.com/oam-dev/kubevela/tree/master/design/vela-core) before diving into its code.
+
+## Build
+
+* Clone this project
+
+```shell script
+git clone git@github.com:oam-dev/kubevela.git
+```
+
+KubeVela includes two parts, `vela core` and `vela cli`.
+
+- The `vela core` is actually a K8s controller, it will watch OAM Spec CRD and deploy resources.
+- The `vela cli` is a command line tool that can build, run apps(with the help of `vela core`).
+
+For local development, we probably need to build both of them.
+
+* Build Vela CLI
+
+```shell script
+make
+```
+
+After the vela cli built successfully, `make` command will create `vela` binary to `bin/` under the project.
+
+* Configure `vela` binary to System PATH
+
+```shell script
+export PATH=$PATH:/your/path/to/project/kubevela/bin
+```
+
+Then you can use `vela` command directly.
+
+* Build Vela Core
+
+```shell script
+make manager
+```
+
+* Run Vela Core
+
+Firstly make sure your cluster has CRDs, below is the command that can help install all CRDs.
+
+```shell script
+make core-install
+```
+
+Run locally:
+
+```shell script
+make core-run
+```
+
+This command will run controller locally, it will use your local KubeConfig which means you need to have a k8s cluster
+locally. If you don't have a one, we suggest that you could setup up a cluster with [kind](https://kind.sigs.k8s.io/).
+
+When you're developing `vela-core`, make sure the controller installed by helm chart is not running.
+Otherwise, it will conflict with your local running controller.
+
+You can check and uninstall it by using helm.
+
+```shell script
+helm list -A
+helm uninstall -n vela-system kubevela
+```
+
+## Use
+
+You can try use your local built binaries follow [the documentation](https://kubevela.io/docs/quick-start).
+
+## Testing
+
+### Unit test
+
+```shell script
+make test
+```
+
+### E2E test
+
+**Before e2e test start, make sure you have vela-core running.**
+
+```shell script
+make core-run
+```
+
+Start to test.
+
+```
+make e2e-test
+```
+
+## Contribute Docs
+
+Please read [the documentation](https://github.com/oam-dev/kubevela/tree/master/docs/README.md) before contributing to the docs.
+
+- Build docs
+
+```shell script
+make docs-build
+```
+
+- Local development and preview
+
+```shell script
+make docs-start
+```
+
+## Next steps
+
+* Read our [code conventions](coding-conventions.md)
+* Learn how to [Create a pull request](create-pull-request.md)

contribute/triage-issues.md

@@ -0,0 +1,40 @@
+# Triage issues
+
+Triage helps ensure that issues resolve quickly by:
+
+- Ensuring the issue's intent and purpose is conveyed precisely. This is necessary because it can be difficult for
+  an issue to explain how an end user experiences a problem and what actions they took.
+- Giving a contributor the information they need before they commit to resolving an issue.
+- Lowering the issue count by preventing duplicate issues.
+- Streamlining the development process by preventing duplicate discussions.
+
+This document gives you some ideas on what you can do to help. For more information, read more about [how the core KubeVela team triage issues](/ISSUE_TRIAGE.md).
+
+## Improve issues
+
+Improve issues by suggesting improvements to the title and description. If you think an issue has formatting issues,
+bad language, or grammatical errors, post a comment to let the author and maintainers know.
+
+## Report resolved issues
+
+If you think an issue has been resolved, or is no longer relevant, suggest us to close it.
+Add a comment on the issue, where you explain the reason it should be closed.
+Make sure to include any related issues and pull requests.
+
+## Investigate issues
+
+Investigate issues that we haven't been able to reproduce yet.
+In some cases, there are many combinations of usage that make it difficult for us to reproduce certain issues.
+Help us by adding more information.
+
+## Vote on issues
+
+Use [GitHub reactions](https://help.github.com/en/articles/about-conversations-on-github#reacting-to-ideas-in-comments)
+to let us know what's important to you. Vote on bugs if you've experienced the same problem. **Don't vote, or react, by commenting on the issue.**
+
+Read more about [how we prioritize issues](/ISSUE_TRIAGE.md#4-prioritization-of-issues).
+
+## Report duplicates
+
+If you find two issues that describe the same thing, add a comment in one of the issues, with a reference (`#<issue number>`) to the other.
+Explain why you think the issue is duplicated.

design/api/vela-controller-params-reference.md

@@ -0,0 +1,27 @@
+# KubeVela Controller Parameters Reference
+
+|          parameter          |  type  |              default              |                           describe                           |
+| :-------------------------: | :----: | :-------------------------------: | :----------------------------------------------------------: |
+|         use-webhook         |  bool  |               false               |                   Enable Admission Webhook                   |
+|      webhook-cert-dir       | string | /k8s-webhook-server/serving-certs |               Admission webhook cert/key dir.                |
+|        webhook-port         |  int   |               9443                |               Admission webhook listen address               |
+|        metrics-addr         | string |               :8080               |          The address the metric endpoint binds to.           |
+|   enable-leader-election    |  bool  |               false               | Enable leader election for controller manager. Enabling this will ensure there is only one active controller manager. |
+|  leader-election-namespace  | string |                ""                 | Determines the namespace in which the leader election configmap will be created. |
+|        log-file-path        | string |                ""                 |                  The file to write logs to.                  |
+|      log-file-max-size      |  int   |               1024                | Defines the maximum size a log file can grow to, Unit is megabytes. |
+|          log-debug          |  bool  |               false               |          Enable debug logs for development purpose           |
+|       revision-limit        |  int   |                50                 | revision-limit is the maximum number of revisions that will be maintained. The default value is 50. |
+| application-revision-limit  |  int   |                10                 | application-revision-limit is the maximum number of application useless revisions that will be maintained, if the useless revisions exceed this number, older ones will be GCed first.The default value is 10. |
+|  definition-revision-limit  |  int   |                20                 | definition-revision-limit is the maximum number of component/trait definition useless revisions that will be maintained, if the useless revisions exceed this number, older ones will be GCed first.The default value is 20. |
+|  custom-revision-hook-url   | string |                ""                 | custom-revision-hook-url is a webhook url which will let KubeVela core to call with applicationConfiguration and component info and return a customized component revision |
+|    app-config-installed     |  bool  |               true                | app-config-installed indicates if applicationConfiguration CRD is installed |
+| autogen-workload-definition |  bool  |               true                | Automatic generated workloadDefinition which componentDefinition refers to |
+|         health-addr         | string |               :9440               |          The address the health endpoint binds to.           |
+|       apply-once-only       | string |               false               | For the purpose of some production environment that workload or trait should not be affected if no spec change, available options: on, off, force. |
+|        disable-caps         | string |                ""                 |           To be disabled builtin capability list.            |
+|       storage-driver        | string |               Local               |         Application file save to the storage driver          |
+|  informer-re-sync-interval  |  time  |                2h                 |    controller shared informer lister full re-sync period     |
+| system-definition-namespace | string |            vela-system            |     define the namespace of the system-level definition      |
+|    concurrent-reconciles    |  int   |                 4                 | concurrent-reconciles is the concurrent reconcile number of the controller. |
+|      depend-check-wait      |  time  |                30s                | depend-check-wait is the time to wait for ApplicationConfiguration's dependent-resource ready. |

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/environment.md

@@ -0,0 +1,294 @@
+# Initilizing Environments For Application Deployment
+
+## Background
+
+A team of application development usually needs to initialize some shared environments for developers to deploy applications to.
+For example, a team would initialize two environments, a *dev* environment for testing applications,
+and a *prod* environment for running applications to serve live traffic.
+The environment is a logical concept grouping common resources that multiple application deployments would depend on.
+
+A list of resources we want to initialize per environment:
+
+- K8s Clusters. Different environments might have clusters of different size and version, e.g.
+  small v1.10 k8s cluster for *dev* environment and large v1.9 k8s cluster for *prod* environment.
+- Admin policies. Production environment would usually set global policies on all application deployments,
+  like chaos testing, SLO requirements, security scanning, misconfiguration detection.
+- Operators & CRDs. Environments contains a variety of Operators & CRDs as system capabilities.
+  These operators can include domain registration, routing, logging, monitoring, autoscaling, etc.
+- Shared services. Environments contains a variety of system services that are be shared by applications.
+  These resources can include DB, cache, load balancers, API Gateways, etc.
+
+With the introduction of environment, the user workflow on Vela works like:
+
+- Platform team defines system Components for Environments.
+- Platform team initializes Environments using system Components.
+- Platform team defines user Components for Applications.
+- Developers choose user Components and Environments to deploy Applicatons.
+
+When initializing environments, there are additional requirements:
+
+- The ability to describe dependency relations between environments. For example, both *dev* and *prod* environments
+  would depend on a common environment that sets up operators both *dev* and *prod* would use.
+
+In the following we propose solutions to implement environment concept for application delivery.
+
+## Initialzer CRD
+
+We propose to add an Initializer CRD:
+
+```yaml
+kind: Initializer
+metadata:
+  name: prod-env
+spec:
+  # appTemplate indicates the application template to render and deploy an system application.
+  appTemplate:
+    # We can use Application to deploy the resources that an environment needs.
+    # An environment setup can be done just like deploying applications in system level.
+    metadata:
+      ...
+    spec:
+      # system components
+      components:
+        ...
+      # system policies
+      policies:
+        ...
+
+  # dependsOn indicates the other initializers that this depends on.
+  # It will not apply its components until all dependencies exist.
+  dependsOn:
+    - ref:
+        apiVersion: core.oam.dev/v1beta1
+        kind: Initializer
+        name: common-operators
+```
+
+By providing this initializer CRD, users can initialize environments by deploying system components --
+the abstractions is flexible enough to do work like provisioning cloud resources, handling db migration,
+installing system operators, etc.
+Additionally, initializer dependency enables separating common setup tasks like setting up namespaces,
+RBAC rules, accounts into reusable modules.
+
+
+## Initializer-Related Operators
+
+The Initializer CRD groups initialization resources together.
+To satisfy each resource and its use case, we also need to implement the supporting operators and definitions.
+In the following, we will walk through each use case and discuss the design of solution.
+
+
+### Case 1: K8s Cluster
+
+In this case, an initializer contains some clusters, and developers specify an initializer name to deploy apps.
+
+Platform team would define placement rules as a Policy and deploy the environment as an Initializer:
+
+```yaml
+kind: Initializer
+metadata:
+  name: prod-env
+spec:
+  appTemplate:
+    spec:
+      policies:
+        - name: prod-env-placement
+          type: placement
+          properties:
+            # clusters of specified names or matched labels will be selected
+            clusterSelector:
+              names: ["prod-1"， "prod-2"]
+              labels:
+                tier: prod
+```
+
+Developers would define how to deploy to clusters based on environments via Workflow:
+
+```yaml
+kind: Application
+metadata:
+  name: my-app
+spec:
+  workflow:
+    - name: deploy2clusters
+      type: deploy2clusters
+      properties:
+        # target indicates the name of the initializer
+        # which contains the selected clusters information.
+        target: prod-env
+
+        # propagation indicates how to propagate the app to the clusters.
+        #   all: all clusters will get one instance of the app
+        #   twin: pick two clusters to deploy two instances of the app
+        #   single: pick one cluster to deploy only one instance of the app
+        propagation: all
+```
+
+Under the hood, the `placement` Policy would be translated to Placement objects that contains cluster information.
+The `deploy2clusters` Workflow Steps would trigger `deploy2clusters` Operator to read Placement objects via `target` name
+and handles progapation of the app's resources to selected clusters.
+
+
+### Case 2: Admin Policy
+
+In this case, an initializer contains some admin policies, and developers specify an initializer to deploy apps.
+
+Platform team would define an admin policy as a Policy, and deploy such an environment as an Initializer:
+
+```yaml
+kind: Initializer
+metadata:
+  name: prod-env
+spec:
+  appTemplate:
+    spec:
+      policies:
+        - name: prod-env-slo-policy
+          type: slo-policy
+          properties:
+            properties:
+              # slo indicates the service in this env must be 99.99% up
+              slo: "99.99"
+        - name: prod-env-chaos-policy
+          type: chaos-policy
+          properties:
+            properties:
+              io:
+                action: fault
+                volumePath: /var/run/etcd
+                path: /var/run/etcd/**/*
+                percent: 50
+                duration: "400s"
+```
+
+Developers would specify a target to deploy via Workflow, which automatically does policy checks in the background:
+
+```yaml
+kind: Application
+metadata:
+  name: my-app
+spec:
+  workflow:
+    - name: check-policy
+      type: check-policy
+      properties:
+        # This app will be checked against the policies in the given target
+        target: prod-env
+        # If policy checks failed, send alerts to spcified channels
+        notifications:
+          slack: slack_url
+          dingding: dingding_url
+```
+
+Under the hood, the `slo-policy` and `chaos-policy` Policies would be translated to data objects (e.g. ConfigMap
+or dedicated Policy objects) that contains policy data.
+The `check-policy` Workflow Steps would trigger `check-policy` Operator to register the apps
+to handlers of the target's policy checks, and handle notifications.
+
+
+### case 3: Operator & CRD
+
+In this case, an initializer defines the system Operators ands CRDs to be installed on a cluster.
+Deploying such an initializer will setup these services and definitions on the host cluster.
+
+Platform team would define these Operators and CRDs as Components, and deploy such an environment as an Initializer:
+
+```yaml
+kind: Initializer
+metadata:
+  name: prod-env
+spec:
+  appTemplate:
+    spec:
+      components:
+        - name: prod-monitoring-operator
+          # Reuse the built-in Helm/Kustomize ComponentDefinition to deploy Operators from Git repo.
+          type: helm-git
+          properties:
+            chart:
+              repository: operator-git-repo-url
+              name: monitoring-operator
+              version: 3.2.0
+        - name: prod-logging-operator
+          type: kustomize-git
+          properties:
+            sourceRef:
+              kind: GitRepository
+              name: logging-operator
+            path: ./apps/prod
+```
+
+Under the hood, Vela will support built-in ComponentDefinitions to deploy Helm charts or Kustomize folders
+via git url. We can use this functionality to deploy system operators.
+
+
+### case 4: Shared Service
+
+In this case, an Initializer defines shared services to be installed on the cluster.
+Deploying such an initializer will setup these services on the host cluster.
+
+Platform team would define the shared services as Components, and deploy such an environment as an Initializer:
+
+```yaml
+kind: Initializer
+metadata:
+  name: prod-env
+spec:
+  appTemplate:
+    spec:
+      components:
+        - name: prod-policy-env
+          # Reuse the built-in Helm ComponentDefinition to deploy Crossplane resource.
+          type: helm-git
+          properties:
+            chart:
+              repository: crossplane-mysql-url
+              name: mysql
+              version: 3.2.0
+        - name: prod-policy-env
+          # Reuse the built-in Terraform ComponentDefinition to deploy cloud resource.
+          type: terraform-git
+          properties:
+            module:
+              source: "git::https://github.com/catalog/kafka.git"
+            outputs:
+              - key: queue_urls
+                moduleOutputName: queue_urls
+              - key: json_string
+                moduleOutputName: json_string
+            variables:
+              - key: ACCESS_KEY_ID
+                sensitive: true
+                environmentVariable: true
+              - key: SECRET_ACCESS_KEY
+                sensitive: true
+                environmentVariable: true
+              - key: CONFIRM_DESTROY
+                value: "1"
+                sensitive: false
+                environmentVariable: true
+```
+
+
+## Implementation Plan
+
+We will discuss the details of implementation plan in this section.
+
+### Environment Controller
+
+- Add a new Initializer CRD and controller skeleton in KubeVela. Add reconcile logic:
+  - If finalizer doesn't exist, add finalizer to the object.
+  - If obj DeletionTimestamp is non-zero (i.e. being deleted):
+    - Wait until the Application resource are deleted entirely.
+      The resource tracker finalizer will ensure all children resources are deleted entirely first.
+    - Then remove finalizer.
+  - Check initializer dependency:
+    - If any of them does not exist, try reconcile later.
+  - Handle each resource:
+    - Render the `appTemplate` into an Application object.
+    - Put Initializer name into the label `app.oam.dev/initializer-name` of Application object.
+    - Put Initializer CR as an ownerRef into the Application object.
+    - Apply the Application object.
+
+
+## Considerations

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/README.md

@@ -4,7 +4,7 @@
 
 # KubeVela
 
-KubeVela is a modern application platform that is fully self-service, and adapts to your needs when you grow.
+KubeVela is a modern application platform that makes deploying and managing applications across today's hybrid, multi-cloud environments easier and faster.
 
 ## Community
 

docs/en/advanced-install.mdx

@@ -1,6 +1,8 @@
 ---
-title:  Advanced Topics for Installation
+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/application.md

@@ -1,149 +0,0 @@
----
-title: Deploy Application
----
-
-This documentation will walk through a full application deployment workflow on KubeVela platform.
-
-## Introduction
-
-KubeVela is a fully self-service platform. All capabilities an application deployment needs are maintained as building block modules in this platform. Specifically:
-- Components - deployable/provisionable entities that composed your application deployment
-  - e.g. a Kubernetes workload, a MySQL database, or a AWS OSS bucket
-- Traits - attachable operational features per your needs
-  - e.g. autoscaling rules, rollout strategies, ingress rules, sidecars, security policies etc
-
-## Step 1: Check Capabilities in the Platform
-
-As user of this platform, you could check available components you can deploy, and available traits you can attach.
-
-```console
-$ kubectl get componentdefinitions -n vela-system
-NAME         WORKLOAD-KIND   DESCRIPTION                                                                                                                                                AGE
-task         Job             Describes jobs that run code or a script to completion.                                                                                                    5h52m
-webservice   Deployment      Describes long-running, scalable, containerized services that have a stable network endpoint to receive external network traffic from customers.           5h52m
-worker       Deployment      Describes long-running, scalable, containerized services that running at backend. They do NOT have network endpoint to receive external network traffic.   5h52m
-```
-
-```console
-$ kubectl get traitdefinitions -n vela-system
-NAME      APPLIES-TO                DESCRIPTION                                                                                                                           AGE
-ingress   ["webservice","worker"]   Configures K8s ingress and service to enable web traffic for your service. Please use route trait in cap center for advanced usage.   6h8m
-cpuscaler ["webservice","worker"]   Configure k8s HPA with CPU metrics for Deployment                                                                                          6h8m
-```
-
-To show the specification for given capability, you could use `vela` CLI. For example, `vela show webservice` will return full schema of *Web Service* component and `vela show webservice --web` will open its capability reference documentation in your browser.
-
-## Step 2: Design and Deploy Application
-
-In KubeVela, `Application` is the main API to define your application deployment based on available capabilities. Every `Application` could contain multiple components, each of them can be attached with a number of traits per needs. 
-
-Now let's define an application composed by *Web Service* and *Worker* components.
-
-```yaml
-# sample.yaml
-apiVersion: core.oam.dev/v1beta1
-kind: Application
-metadata:
-  name: website
-spec:
-  components:
-    - name: frontend
-      type: webservice
-      properties:
-        image: nginx
-      traits:
-        - type: cpuscaler
-          properties:
-            min: 1
-            max: 10
-            cpuPercent: 60
-        - type: sidecar
-          properties:
-            name: "sidecar-test"
-            image: "fluentd"
-    - name: backend
-      type: worker
-      properties:
-        image: busybox
-        cmd:
-          - sleep
-          - '1000'
-```
-
-In this sample, we also attached `sidecar` and `cpuscaler` traits to the `frontend` component.
-So after deployed, the `frontend` component instance (a Kubernetes Deployment workload) will be automatically injected
-with a `fluentd` sidecar and automatically scale from 1-10 replicas based on CPU usage.
-
-### Deploy the Application
-
-Apply application YAML to Kubernetes:
-
-```shell
-$ kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/master/docs/examples/enduser/sample.yaml
-application.core.oam.dev/website created
-```
-
-You'll get the application becomes `running`.
-
-```shell
-$ kubectl get application website -o yaml
-apiVersion: core.oam.dev/v1beta1
-kind: Application
-metadata:
- name: website
-....
-status:
-  components:
-  - apiVersion: core.oam.dev/v1alpha2
-    kind: Component
-    name: backend
-  - apiVersion: core.oam.dev/v1alpha2
-    kind: Component
-    name: frontend
-....
-  status: running
-
-```
-
-### Verify the Deployment
-
-You could see a Deployment named `frontend` is running, with port exposed, and with a container `fluentd` injected.
-
-```shell
-$ kubectl get deploy frontend
-NAME       READY   UP-TO-DATE   AVAILABLE   AGE
-frontend   1/1     1            1           97s
-```
-
-```shell
-$ kubectl get deploy frontend -o yaml
-...
-    spec:
-      containers:
-      - image: nginx
-        imagePullPolicy: Always
-        name: frontend
-        ports:
-        - containerPort: 80
-          protocol: TCP
-      - image: fluentd
-        imagePullPolicy: Always
-        name: sidecar-test
-...
-```
-
-Another Deployment is also running named `backend`.
-
-```shell
-$ kubectl get deploy backend
-NAME      READY   UP-TO-DATE   AVAILABLE   AGE
-backend   1/1     1            1           111s
-```
-
-An HPA was also created by the `cpuscaler` trait. 
-
-```shell
-$ kubectl get HorizontalPodAutoscaler frontend
-NAME       REFERENCE             TARGETS         MINPODS   MAXPODS   REPLICAS   AGE
-frontend   Deployment/frontend   <unknown>/50%   1         10        1          101m
-```

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

@@ -0,0 +1,35 @@
+## vela system cue-packages
+
+List cue package
+
+### Synopsis
+
+List cue package
+
+```
+vela system cue-packages
+```
+
+### Examples
+
+```
+vela system cue-packages
+```
+
+### Options
+
+```
+  -h, --help   help for cue-packages
+```
+
+### Options inherited from parent commands
+
+```
+  -e, --env string   specify environment name for application
+```
+
+### SEE ALSO
+
+* [vela system](vela_system)	 - System management utilities
+
+###### Auto generated by spf13/cobra on 2-May-2021

docs/en/cli/vela_system_live-diff.md

@@ -0,0 +1,39 @@
+## vela system live-diff
+
+Dry-run an application, and do diff on a specific app revison
+
+### Synopsis
+
+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.
+
+```
+vela system live-diff
+```
+
+### Examples
+
+```
+vela live-diff -f app-v2.yaml -r app-v1 --context 10
+```
+
+### Options
+
+```
+  -r, --Revision string     specify an application Revision name, by default, it will compare with the latest Revision
+  -c, --context int         output number lines of context around changes, by default show all unchanged lines (default -1)
+  -d, --definition string   specify a file or directory containing capability definitions, they will only be used in dry-run rather than applied to K8s cluster
+  -f, --file string         application file name (default "./app.yaml")
+  -h, --help                help for live-diff
+```
+
+### Options inherited from parent commands
+
+```
+  -e, --env string   specify environment name for application
+```
+
+### SEE ALSO
+
+* [vela system](vela_system)	 - System management utilities
+
+###### Auto generated by spf13/cobra on 2-May-2021

docs/en/concepts.md

@@ -4,110 +4,43 @@ title:  How it Works
 
 In this documentation, we will explain the core idea of KubeVela and clarify some technical terms that are widely used in the project.
 
-## Overview
+## API
 
-First of all, KubeVela introduces a workflow with separate of concerns as below:
+On control plane, KubeVela introduces [Open Application Model (OAM)](https://oam.dev) as the main API to model a full deployment of modern microservices application. This API could be explained as below:
+
+![alt](resources/concepts.png)
+
+In detail:
+- Components - deployable/provisionable entities that compose your application.
+  - e.g. a Helm chart, a Kubernetes workload, a Terraform module, or a cloud database instance etc.
+- Traits - attachable features that will *overlay* given component with operational behaviors.
+  - e.g. autoscaling rules, rollout strategies, ingress rules, sidecars, security policies etc.
+- Application - full description of your application deployment assembled with components and traits.
+- Environment - the target environments to deploy this application.
+
+We also reference components and traits as *"capabilities"* in KubeVela.
+
+## Workflow
+
+To ensure simple yet consistent user experience across hybrid environments. KubeVela introduces a workflow with separate of concerns as below:
 - **Platform Team**
-  - Model and manage platform capabilities as components or traits, together with deployment environment configurations.
-- **End Users**
-  - Choose a deployment environment, assemble the app with available components and traits per needs, and then deploy the app to target environment.
+  - Model and manage platform capabilities as components or traits, together with target environments specifications.
+- **Application Team**
+  - Choose a environment, assemble the application with components and traits per needs, and deploy it to target environment.
+
+> Note that either platform team or application team application will only talk to the control plane cluster. KubeVela is designed to hide the details of runtime infrastructures except for debugging or verifying purpose.
 
 Below is how this workflow looks like:
 
 ![alt](resources/how-it-works.png)
 
-This design make it possible for platform team to enforce best practices by *coding* platform capabilities into reusable building blocks, and leverage them to expose a *PaaS-like* experience (*i.e. app-centric abstractions, self-service workflow etc*) to end users.
-
-Also, as programmable components, all capabilities in KubeVela can be updated or extended easily per your needs at any time.
-
-![alt](resources/what-is-kubevela.png)
-
-In the model layer, KubeVela leverages [Open Application Model (OAM)](https://oam.dev) to make above design happen.
-
-## `Application`
-
-The *Application* is the core API of KubeVela. It allows developers to work with a single artifact to capture the complete application deployment with simplified primitives.
-
-In application delivery platform, having an "application" concept is important to simplify administrative tasks and can serve as an anchor to avoid configuration drifts during operation. Also, it provides a much simpler path for on-boarding Kubernetes capabilities to end users without relying on low level details. For example, a developer will be able to model a "web service" without defining a detailed Kubernetes Deployment + Service combo each time, or claim the auto-scaling requirements without referring to the underlying KEDA ScaleObject.
-
-### Example
-
-An example of `website` application with two components (i.e. `frontend` and `backend`) could be modeled as below:
-
-```yaml
-apiVersion: core.oam.dev/v1beta1
-kind: Application
-metadata:
-  name: website
-spec:
-  components:
-    - name: backend
-      type: worker
-      properties:
-        image: busybox
-        cmd:
-          - sleep
-          - '1000'
-    - name: frontend
-      type: webservice
-      properties:
-        image: nginx
-      traits:
-        - type: autoscaler
-          properties:
-            min: 1
-            max: 10
-        - type: sidecar
-          properties:
-            name: "sidecar-test"
-            image: "fluentd"
-```
-
-The `Application` resource in KubeVela is a LEGO-style entity and does not even have fixed schema. Instead, it is composed by several building blocks (app components and traits etc.) that gives you full flexibility to model platform capabilities around the application's needs.
-
-These building blocks named `ComponentDefinition` and `TraitDefinition`.
-
-### `ComponentDefinition`
-
-`ComponentDefinition` is an object that models a deployable entity in your platform, for example, a *Long Running Web Service*, a *Helm chart* or a *Alibaba Cloud RDS*. A typical `ComponentDefinition` carries workload type description (i.e. `WorkloadDefinition`) of this component, and the configurable parameter list this component exposed to users.
-
-Hence, components are designed to be shareable and reusable. For example, by referencing the same *Alibaba Cloud RDS* component and setting different parameter values, users could easily provision Alibaba Cloud RDS instances of different sizes in different availability zones.
-
-Users will use the `Application` entity to declare how they want to instantiate and deploy certain component definitions. Specifically, the `.type` field references the name of a `ComponentDefinition` and `.properties` are user provided parameter values to instantiate it. 
-
-All component definitions expected to be provided by component providers such as 3rd-party software vendors, or pre-installed in the system by platform team.
-
-### `TraitDefinition`
-
-Optionally, each component has a `.traits` section that augments the component instance with operational behaviors such as load balancing policy, network ingress routing, auto-scaling policies, or upgrade strategies, etc.
-
-Traits are operational features provided by the platform. To attach a trait to component instance, the user will declare `.type` field to reference the specific `TraitDefinition`, and `.properties` field to set property values of the given trait. Similarly, `TraitDefiniton` also allows you to define *template* for operational features.
-
-We also reference component definitions and trait definitions as *"capabilities"* in KubeVela. 
-
-### Summary
-
-These main concepts of KubeVela could be shown as below:
-
-![alt](resources/concepts.png)
-
-Essentially:
-- Components - deployable/provisionable entities that composed your application
-  - e.g. a Helm chart, a stateless workload, a MySQL database, or a AWS S3 bucket
-- Traits - attachable operational features per your needs
-  - e.g. autoscaling rules, rollout strategies, ingress rules, sidecars, security policies etc
-- Application - full description of your application deployment assembled with components and traits
-- Environment - the target environments to deploy this application
+All the capability building blocks can be updated or extended easily at any time since they are fully programmable via CUE.
 
 ## Environment
-Before releasing an application to production, it's important to test the code in testing/staging workspaces. In KubeVela, we describe these workspaces as "deployment environments" or "environments" for short. Each environment has its own configuration (e.g., domain, Kubernetes cluster and namespace, configuration data, access control policy, etc.) to allow user to create different deployment environments such as "test" and "production".
+Before releasing an application to production, it's important to test the code in testing/staging workspaces. In KubeVela, we describe these workspaces as "environments". Each environment has its own configuration (e.g., domain, Kubernetes cluster and namespace, configuration data, access control policy, etc.) to allow user to create different deployment environments such as "test" and "production".
 
-Currently, a KubeVela `environment` only maps to a Kubernetes namespace, while the cluster level environment is work in progress.
+## What's Next
 
-## Architecture
+Here are some recommended next steps:
 
-The overall architecture of KubeVela is shown as below:
-
-![alt](resources/arch.png)
-
-In nutshell, in *control plane cluster*, the application controller is responsible for application deployment orchestration and the placement controller is responsible for deploying the application across multiple *runtime clusters* with traffic shifting features supported out-of-box. The needed addons in runtime cluster are automatically discovered and installed with leverage of [CRD Lifecycle Management (CLM)](https://github.com/cloudnativeapp/CLM).
+- 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/extensions/set-autoscale.md

@@ -55,7 +55,7 @@ Introduce how to automatically scale workloads by cron.
           timezone: "America/Los_Angeles"
   ```
 
-> The full specification of `autoscale` could show up by `$ vela show autoscale` or be found on [its reference documentation](../references/traits/autoscale)
+> The full specification of `autoscale` could show up by `$ vela show autoscale`.
 
 2. Deploy an application
   

docs/en/developers/extensions/set-metrics.md

@@ -55,7 +55,7 @@ The app will emit random latencies as metrics.
     EOF
   ```
 
-> The full specification of `metrics` could show up by `$ vela show metrics` or be found on [its reference documentation](../references/traits/metrics)
+> The full specification of `metrics` could show up by `$ vela show metrics`.
 
 2. Deploy the application:
 

docs/en/developers/extensions/set-rollout.md

@@ -26,7 +26,7 @@ services:
       domain: "example.com"
 ```
 
-> The full specification of `rollout` could show up by `$ vela show rollout` or be found on [its reference documentation](../references/traits/rollout)
+> The full specification of `rollout` could show up by `$ vela show rollout`.
 
 Apply this `appfile.yaml`:
 

docs/en/developers/extensions/set-route.md

@@ -42,7 +42,7 @@ services:
           rewriteTarget: /
 ```
 
-> The full specification of `route` could show up by `$ vela show route` or be found on [its reference documentation](../references/traits/route)
+> The full specification of `route` could show up by `$ vela show route`.
 
 Apply again:
 

docs/en/developers/learn-appfile.md

@@ -72,7 +72,7 @@ services:
   
 ```
 
-> To learn about how to set the properties of specific workload type or trait, please check the [reference documentation guide](./check-ref-doc).
+> To learn about how to set the properties of specific workload type or trait, please use `vela show <TYPE | TRAIT>`.
 
 ## Example Workflow
 
@@ -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>
@@ -221,7 +225,7 @@ spec:
 
 ### [Optional] Configure another workload type
 
-By now we have deployed a *[Web Service](references/component-types/webservice)*, which is the default workload type in KubeVela. We can also add another service of *[Task](references/component-types/task)* type in the same app:
+By now we have deployed a *[Web Service](../end-user/components/webservice)*, which is the default workload type in KubeVela. We can also add another service of *[Task](../end-user/components/task)* type in the same app:
 
 ```yaml
 services:
@@ -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/README.md

@@ -1,113 +0,0 @@
----
-title:  Overview
----
-
-In this documentation, we will show how to check the detailed schema of a given capability (i.e. component type or trait). 
-
-This may sound challenging because every capability is a "plug-in" in KubeVela (even for the built-in ones), also, it's by design that KubeVela allows platform administrators to modify the capability templates at any time. In this case, do we need to manually write documentation for every newly installed capability? And how can we ensure those documentations for the system is up-to-date?
-
-## Using Browser
-
-Actually, as a important part of its "extensibility" design, KubeVela will always **automatically generate** reference documentation for every workload type or trait registered in your Kubernetes cluster, based on the template in its definition of course. This feature works for any capability: either built-in ones or your own workload types/traits.
-
-Thus, as an end user, the only thing you need to do is:
-
-```console
-$ vela show COMPONENT_TYPE or TRAIT --web
-```
-
-This command will automatically open the reference documentation for given component type or trait in your default browser.
-
-Let's take `$ vela show webservice --web` as example. The detailed schema documentation for `Web Service` component type will show up immediately as below:
-
-![](../../resources/vela_show_webservice.jpg)
-
-Note that there's in the section named `Specification`, it even provides you with a full sample for the usage of this workload type with a fake name `my-service-name`.
-
-Similarly, we can also do `$ vela show autoscale`:
-
-![](../../resources/vela_show_autoscale.jpg)
-
-With these auto-generated reference documentations, we could easily complete the application description by simple copy-paste, for example:
-
-```yaml
-name: helloworld
-
-services:
-  backend: # copy-paste from the webservice ref doc above
-    image: oamdev/testapp:v1
-    cmd: ["node", "server.js"]
-    port: 8080
-    cpu: "0.1"
-
-    autoscale: # copy-paste and modify from autoscaler ref doc above
-      min: 1
-      max: 8
-      cron:
-        startAt:  "19:00"
-        duration: "2h"
-        days:     "Friday"
-        replicas: 4
-        timezone: "America/Los_Angeles"
-```
-
-## Using Terminal
-
-This reference doc feature also works for terminal-only case. For example:
-
-```shell
-$ vela show webservice
-# Properties
-+-------+----------------------------------------------------------------------------------+---------------+----------+---------+
-| NAME  |                                   DESCRIPTION                                    |     TYPE      | REQUIRED | DEFAULT |
-+-------+----------------------------------------------------------------------------------+---------------+----------+---------+
-| cmd   | Commands to run in the container                                                 | []string      | false    |         |
-| env   | Define arguments by using environment variables                                  | [[]env](#env) | false    |         |
-| image | Which image would you like to use for your service                               | string        | true     |         |
-| port  | Which port do you want customer traffic sent to                                  | int           | true     |      80 |
-| cpu   | Number of CPU units for the service, like `0.5` (0.5 CPU core), `1` (1 CPU core) | string        | false    |         |
-+-------+----------------------------------------------------------------------------------+---------------+----------+---------+
-
-
-## env
-+-----------+-----------------------------------------------------------+-------------------------+----------+---------+
-|   NAME    |                        DESCRIPTION                        |          TYPE           | REQUIRED | DEFAULT |
-+-----------+-----------------------------------------------------------+-------------------------+----------+---------+
-| name      | Environment variable name                                 | string                  | true     |         |
-| value     | The value of the environment variable                     | string                  | false    |         |
-| valueFrom | Specifies a source the value of this var should come from | [valueFrom](#valueFrom) | false    |         |
-+-----------+-----------------------------------------------------------+-------------------------+----------+---------+
-
-
-### valueFrom
-+--------------+--------------------------------------------------+-------------------------------+----------+---------+
-|     NAME     |                   DESCRIPTION                    |             TYPE              | REQUIRED | DEFAULT |
-+--------------+--------------------------------------------------+-------------------------------+----------+---------+
-| secretKeyRef | Selects a key of a secret in the pod's namespace | [secretKeyRef](#secretKeyRef) | true     |         |
-+--------------+--------------------------------------------------+-------------------------------+----------+---------+
-
-
-#### secretKeyRef
-+------+------------------------------------------------------------------+--------+----------+---------+
-| NAME |                           DESCRIPTION                            |  TYPE  | REQUIRED | DEFAULT |
-+------+------------------------------------------------------------------+--------+----------+---------+
-| name | The name of the secret in the pod's namespace to select from     | string | true     |         |
-| key  | The key of the secret to select from. Must be a valid secret key | string | true     |         |
-+------+------------------------------------------------------------------+--------+----------+---------+
-```
-
-## For Built-in Capabilities
-
-Note that for all the built-in capabilities, we already published their reference docs below based on the same doc generation mechanism.
-
-
-- Workload Types
-	- [webservice](component-types/webservice)
-	- [task](component-types/task)
-	- [worker](component-types/worker)
-- Traits
-	- [route](traits/route)
-	- [autoscale](traits/autoscale)
-	- [rollout](traits/rollout)
-	- [metrics](traits/metrics)
-	- [scaler](traits/scaler)

docs/en/developers/references/component-types/task.md

@@ -1,27 +0,0 @@
----
-title:  Task
----
-
-## Description
-
-Describes jobs that run code or a script to completion.
-
-## Specification
-
-List of all configuration options for a `Task` workload type.
-
-```yaml
-...
-    image: perl
-    count: 10
-    cmd: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
-```
-
-## Properties
-
-Name | Description | Type | Required | Default 
------------- | ------------- | ------------- | ------------- | ------------- 
- cmd | Commands to run in the container | []string | false |  
- count | specify number of tasks to run in parallel | int | true | 1 
- restart | Define the job restart policy, the value can only be Never or OnFailure. By default, it's Never. | string | true | Never 
- image | Which image would you like to use for your service | string | true |  

docs/en/developers/references/component-types/webservice.md

@@ -1,61 +0,0 @@
----
-title:  Webservice
----
-
-## Description
-
-Describes long-running, scalable, containerized services that have a stable network endpoint to receive external network traffic from customers. If workload type is skipped for any service defined in Appfile, it will be defaulted to `webservice` type.
-
-## Specification
-
-List of all configuration options for a `Webservice` workload type.
-
-```yaml
-...
-    image: oamdev/testapp:v1
-    cmd: ["node", "server.js"]
-    port: 8080
-    cpu: "0.1"
-    env:
-      - name: FOO
-        value: bar
-      - name: FOO
-        valueFrom:
-          secretKeyRef:
-            name: bar
-            key: bar
-```
-
-## Properties
-
-Name | Description | Type | Required | Default 
------------- | ------------- | ------------- | ------------- | ------------- 
- cmd | Commands to run in the container | []string | false |  
- env | Define arguments by using environment variables | [[]env](#env) | false |  
- image | Which image would you like to use for your service | string | true |  
- port | Which port do you want customer traffic sent to | int | true | 80 
- cpu | Number of CPU units for the service, like `0.5` (0.5 CPU core), `1` (1 CPU core) | string | false |  
-
-
-### env
-
-Name | Description | Type | Required | Default 
------------- | ------------- | ------------- | ------------- | ------------- 
- name | Environment variable name | string | true |  
- value | The value of the environment variable | string | false |  
- valueFrom | Specifies a source the value of this var should come from | [valueFrom](#valueFrom) | false |  
-
-
-#### valueFrom
-
-Name | Description | Type | Required | Default 
------------- | ------------- | ------------- | ------------- | ------------- 
- secretKeyRef | Selects a key of a secret in the pod's namespace | [secretKeyRef](#secretKeyRef) | true |  
-
-
-##### secretKeyRef
-
-Name | Description | Type | Required | Default 
------------- | ------------- | ------------- | ------------- | ------------- 
- name | The name of the secret in the pod's namespace to select from | string | true |  
- key | The key of the secret to select from. Must be a valid secret key | string | true |  

docs/en/developers/references/component-types/worker.md

@@ -1,24 +0,0 @@
----
-title:  Worker
----
-
-## Description
-
-Describes long-running, scalable, containerized services that running at backend. They do NOT have network endpoint to receive external network traffic.
-
-## Specification
-
-List of all configuration options for a `Worker` workload type.
-
-```yaml
-...
-    image: oamdev/testapp:v1
-    cmd: ["node", "server.js"]
-```
-
-## Properties
-
-Name | Description | Type | Required | Default 
------------- | ------------- | ------------- | ------------- | ------------- 
- cmd | Commands to run in the container | []string | false |  
- image | Which image would you like to use for your service | string | true |  

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/developers/references/traits/autoscale.md

@@ -1,44 +0,0 @@
----
-title:  Autoscale
----
-
-## Description
-
-Automatically scales workloads by resource utilization metrics or cron triggers.
-
-## Specification
-
-List of all configuration options for a `Autoscale` trait.
-
-```yaml
-...
-	min: 1
-	max: 4
-	cron:
-	startAt:  "14:00"
-	duration: "2h"
-	days:     "Monday, Thursday"
-	replicas: 2
-	timezone: "America/Los_Angeles"
-	cpuPercent: 10
-```
-
-## Properties
-
-Name | Description | Type | Required | Default 
------------- | ------------- | ------------- | ------------- | ------------- 
- min | Minimal replicas of the workload | int | true |  
- max | Maximal replicas of the workload | int | true |  
- cpuPercent | Specify the value for CPU utilization, like 80, which means 80% | int | false |  
- cron | Cron type auto-scaling. Just for `appfile`, not available for Cli usage | [cron](#cron) | false |  
-
-
-### cron
-
-Name | Description | Type | Required | Default 
------------- | ------------- | ------------- | ------------- | ------------- 
- startAt | The time to start scaling, like `08:00` | string | true |  
- duration | For how long the scaling will last | string | true |  
- days | Several workdays or weekends, like "Monday, Tuesday" | string | true |  
- replicas | The target replicas to be scaled to | int | true |  
- timezone | Timezone, like "America/Los_Angeles" | string | true |  

docs/en/developers/references/traits/ingress.md

@@ -1,25 +0,0 @@
----
-title:  Ingress
----
-
-## Description
-
-Configures K8s ingress and service to enable web traffic for your service. Please use route trait in cap center for advanced usage.
-
-## Specification
-
-List of all configuration options for a `Ingress` trait.
-
-```yaml
-...
-    domain: testsvc.example.com
-    http:
-      /: 8000
-```
-
-## Properties
-
-Name | Description | Type | Required | Default 
------------- | ------------- | ------------- | ------------- | ------------- 
- domain |  | string | true |  
- http |  | map[string]int | true |  

docs/en/developers/references/traits/scaler.md

@@ -1,23 +0,0 @@
----
-title:  Scaler
----
-
-## Description
-
-Configures replicas for your service.
-
-## Specification
-
-List of all configuration options for a `Scaler` trait.
-
-```yaml
-...
-    scaler:
-      replicas: 100
-```
-
-## Properties
-
-Name | Description | Type | Required | Default 
------------- | ------------- | ------------- | ------------- | ------------- 
- replicas | Replicas of the workload | int | true | 1 

docs/en/end-user/application.md

@@ -0,0 +1,236 @@
+---
+title: Application
+---
+
+This documentation will walk through how to use KubeVela to design a simple application without any polices or placement rule defined.
+
+> Note: since you didn't declare placement rule, KubeVela will deploy this application directly to the control plane cluster (i.e. the cluster your `kubectl` is talking to). This is also the same case if you are using local cluster such as KinD or MiniKube to play KubeVela.
+
+## Step 1: Check Available Components
+
+Components are deployable or provisionable entities that compose your application. It could be a Helm chart, a simple Kubernetes workload, a CUE or Terraform module, or a cloud database etc.
+
+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. 
+worker            Deployment      Describes long-running, scalable, containerized services that running at backend. They do NOT have network endpoint to receive external network traffic.
+```
+
+To show the specification for given component, you could use `vela show`. 
+
+```shell
+kubectl vela show webservice
+```
+```console
+# Properties
++------------------+----------------------------------------------------------------------------------+-----------------------+----------+---------+
+|       NAME       |                                   DESCRIPTION                                    |         TYPE          | REQUIRED | DEFAULT |
++------------------+----------------------------------------------------------------------------------+-----------------------+----------+---------+
+| cmd              | Commands to run in the container                                                 | []string              | false    |         |
+| env              | Define arguments by using environment variables                                  | [[]env](#env)         | false    |         |
+| addRevisionLabel |                                                                                  | bool                  | true     | false   |
+| image            | Which image would you like to use for your service                               | string                | true     |         |
+| port             | Which port do you want customer traffic sent to                                  | int                   | true     |      80 |
+| cpu              | Number of CPU units for the service, like `0.5` (0.5 CPU core), `1` (1 CPU core) | string                | false    |         |
+| volumes          | Declare volumes and volumeMounts                                                 | [[]volumes](#volumes) | false    |         |
++------------------+----------------------------------------------------------------------------------+-----------------------+----------+---------+
+... // skip other fields
+```
+
+> Tips: `vela show xxx --web` will open its capability reference documentation in your default browser.
+
+You could always [add more components](components/more) to the platform at any time.
+
+## Step 2: Declare an Application
+
+Application is the full description of a deployment. Let's define an application that deploys a *Web Service* and a *Worker* components.
+
+```yaml
+# sample.yaml
+apiVersion: core.oam.dev/v1beta1
+kind: Application
+metadata:
+  name: website
+spec:
+  components:
+    - name: frontend
+      type: webservice
+      properties:
+        image: nginx
+    - name: backend
+      type: worker
+      properties:
+        image: busybox
+        cmd:
+          - sleep
+          - '1000'
+```
+
+## Step 3: Attach Traits
+
+Traits are platform provided features that could *overlay* a given component with extra operational behaviors.
+
+```shell
+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.
+scaler                                     [webservice worker]   Manually scale the component.
+sidecar                                    [webservice worker]   Inject a sidecar container to the component.
+```
+
+Let's check the specification of `sidecar` trait.
+
+```shell
+kubectl vela show sidecar
+```
+```console
+# Properties
++---------+-----------------------------------------+----------+----------+---------+
+|  NAME   |               DESCRIPTION               |   TYPE   | REQUIRED | DEFAULT |
++---------+-----------------------------------------+----------+----------+---------+
+| name    | Specify the name of sidecar container   | string   | true     |         |
+| image   | Specify the image of sidecar container  | string   | true     |         |
+| command | Specify the commands run in the sidecar | []string | false    |         |
++---------+-----------------------------------------+----------+----------+---------+
+```
+
+Note that traits are designed to be *overlays*.
+
+This means for `sidecar` trait, your `frontend` component doesn't need to have a sidecar template or bring a webhook to enable sidecar injection. Instead, KubeVela is able to patch a sidecar to its workload instance after it is generated by the component (no matter it's a Helm chart or CUE module) but before it is applied to runtime cluster.
+
+Similarly, the system will assign a HPA instance based on the properties you set and "link" it to the target workload instance, the component itself is untouched.
+
+Now let's attach `sidecar` and `cpuscaler` traits to the `frontend` component. 
+
+```yaml
+# sample.yaml
+apiVersion: core.oam.dev/v1beta1
+kind: Application
+metadata:
+  name: website
+spec:
+  components:
+    - name: frontend              # This is the component I want to deploy
+      type: webservice
+      properties:
+        image: nginx
+      traits:
+        - type: cpuscaler         # Automatically scale the component by CPU usage after deployed
+          properties:
+            min: 1
+            max: 10
+            cpuPercent: 60
+        - type: sidecar           # Inject a fluentd sidecar before applying the component to runtime cluster
+          properties:
+            name: "sidecar-test"
+            image: "fluentd"
+    - name: backend
+      type: worker
+      properties:
+        image: busybox
+        cmd:
+          - sleep
+          - '1000'
+```
+
+## Step 4: Deploy the Application
+
+```shell
+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
+```
+```console
+NAME        COMPONENT   TYPE         PHASE     HEALTHY   STATUS   AGE
+website     frontend    webservice   running   true               4m54s
+```
+
+Check the details of the application.
+
+```shell
+kubectl get app website -o yaml
+```
+```console
+apiVersion: core.oam.dev/v1beta1
+kind: Application
+metadata:
+  generation: 1
+  name: website
+  namespace: default
+spec:
+  components:
+  - name: frontend
+    properties:
+      image: nginx
+    traits:
+    - properties:
+        cpuPercent: 60
+        max: 10
+        min: 1
+      type: cpuscaler
+    - properties:
+        image: fluentd
+        name: sidecar-test
+      type: sidecar
+    type: webservice
+  - name: backend
+    properties:
+      cmd:
+      - sleep
+      - "1000"
+      image: busybox
+    type: worker
+status:
+  ...
+  latestRevision:
+    name: website-v1
+    revision: 1
+    revisionHash: e9e062e2cddfe5fb
+  services:
+  - healthy: true
+    name: frontend
+    traits:
+    - healthy: true
+      type: cpuscaler
+    - healthy: true
+      type: sidecar
+  - healthy: true
+    name: backend
+  status: running
+```
+
+Specifically:
+
+1. `status.latestRevision` declares current revision of this deployment.
+2. `status.services` declares the component created by this deployment and the healthy state.
+3. `status.status` declares the global state of this deployment. 
+
+### List Revisions
+
+When updating an application entity, KubeVela will create a new revision for this change.
+
+```shell
+kubectl get apprev -l app.oam.dev/name=website
+```
+```console
+NAME           AGE
+website-v1     35m
+```
+
+Furthermore, the system will decide how to/whether to rollout the application based on the attached [rollout plan](scopes/rollout-plan).

docs/en/end-user/cloud-resources.md

@@ -1,242 +0,0 @@
----
-title: Provision and Consume Cloud Resources by Crossplane
----
-
-> ⚠️ This section requires your platform builder has already installed the [cloud resources related capabilities](../platform-engineers/cloud-services).
-
-## Provision and consume cloud resource in a single application v1 (one cloud resource)
-
-Check the parameters of cloud resource component:
-
-```shell
-$ kubectl vela show alibaba-rds
-
-# Properties
-+---------------+------------------------------------------------+--------+----------+--------------------+
-|     NAME      |                  DESCRIPTION                   |  TYPE  | REQUIRED |      DEFAULT       |
-+---------------+------------------------------------------------+--------+----------+--------------------+
-| engine        | RDS engine                                     | string | true     | mysql              |
-| engineVersion | The version of RDS engine                      | string | true     |                8.0 |
-| instanceClass | The instance class for the RDS                 | string | true     | rds.mysql.c1.large |
-| username      | RDS username                                   | string | true     |                    |
-| secretName    | Secret name which RDS connection will write to | string | true     |                    |
-+---------------+------------------------------------------------+--------+----------+--------------------+
-```
-
-Use the service binding trait to bind cloud resources into workload as ENV.
-
-Create an application with a cloud resource provisioning component and a consuming component as below.
-
-```yaml
-apiVersion: core.oam.dev/v1beta1
-kind: Application
-metadata:
-  name: webapp
-spec:
-  components:
-    - name: express-server
-      type: webservice
-      properties:
-        image: zzxwill/flask-web-application:v0.3.1-crossplane
-        ports: 80
-      traits:
-        - type: service-binding
-          properties:
-            envMappings:
-              # environments refer to db-conn secret
-              DB_PASSWORD:
-                secret: db-conn
-                key: password                                     # 1) If the env name is different from secret key, secret key has to be set.
-              endpoint:
-                secret: db-conn                                   # 2) If the env name is the same as the secret key, secret key can be omitted.
-              username:
-                secret: db-conn
-
-    - name: sample-db
-      type: alibaba-rds
-      properties:
-        name: sample-db
-        engine: mysql
-        engineVersion: "8.0"
-        instanceClass: rds.mysql.c1.large
-        username: oamtest
-        secretName: db-conn
-
-```
-
-Apply it and verify the application.
-
-```shell
-$ kubectl get application
-NAME     AGE
-webapp   46m
-
-$ kubectl port-forward deployment/express-server 80:80
-Forwarding from 127.0.0.1:80 -> 80
-Forwarding from [::1]:80 -> 80
-Handling connection for 80
-Handling connection for 80
-```
-
-![](../resources/crossplane-visit-application.jpg)
-
-## Provision and consume cloud resource in a single application v2 (two cloud resources)
-
-Based on the section `Provisioning and consuming cloud resource in a single application v1 (one cloud resource)`, 
-
-Update the application to also consume cloud resource OSS.
-
-```yaml
-apiVersion: core.oam.dev/v1beta1
-kind: Application
-metadata:
-  name: webapp
-spec:
-  components:
-    - name: express-server
-      type: webservice
-      properties:
-        image: zzxwill/flask-web-application:v0.3.1-crossplane
-        ports: 80
-      traits:
-        - type: service-binding
-          properties:
-            envMappings:
-              # environments refer to db-conn secret
-              DB_PASSWORD:
-                secret: db-conn
-                key: password                                     # 1) If the env name is different from secret key, secret key has to be set.
-              endpoint:
-                secret: db-conn                                   # 2) If the env name is the same as the secret key, secret key can be omitted.
-              username:
-                secret: db-conn
-              # environments refer to oss-conn secret
-              BUCKET_NAME:
-                secret: oss-conn
-                key: Bucket
-
-    - name: sample-db
-      type: alibaba-rds
-      properties:
-        name: sample-db
-        engine: mysql
-        engineVersion: "8.0"
-        instanceClass: rds.mysql.c1.large
-        username: oamtest
-        secretName: db-conn
-
-    - name: sample-oss
-      type: alibaba-oss
-      properties:
-        name: velaweb
-        secretName: oss-conn
-```
-
-Apply it and verify the application.
-
-```shell
-$ kubectl port-forward deployment/express-server 80:80
-Forwarding from 127.0.0.1:80 -> 80
-Forwarding from [::1]:80 -> 80
-Handling connection for 80
-Handling connection for 80
-```
-
-![](../resources/crossplane-visit-application-v2.jpg)
-
-## Provision and consume cloud resource in different applications
-
-In this section, cloud resource will be provisioned in one application and consumed in another application.
-
-### Provision Cloud Resource
-
-Instantiate RDS component with `alibaba-rds` workload type in an [Application](../application) to provide cloud resources.
-
-As we have claimed an RDS instance with ComponentDefinition name `alibaba-rds`.
-The component in the application should refer to this type.
-
-```yaml
-apiVersion: core.oam.dev/v1beta1
-kind: Application
-metadata:
-  name: baas-rds
-spec:
-  components:
-    - name: sample-db
-      type: alibaba-rds
-      properties:
-        name: sample-db
-        engine: mysql
-        engineVersion: "8.0"
-        instanceClass: rds.mysql.c1.large
-        username: oamtest
-        secretName: db-conn
-```
-
-Apply the application to Kubernetes and a RDS instance will be automatically provisioned (may take some time, ~2 mins).
-
-A secret `db-conn` will also be created in the same namespace as that of the application.
-
-```shell
-$ kubectl get application
-NAME       AGE
-baas-rds   9h
-
-$ kubectl get rdsinstance
-NAME           READY   SYNCED   STATE     ENGINE   VERSION   AGE
-sample-db-v1   True    True     Running   mysql    8.0       9h
-
-$ kubectl get secret
-NAME                                              TYPE                                  DATA   AGE
-db-conn                                           connection.crossplane.io/v1alpha1     4      9h
-
-$ ✗ kubectl get secret db-conn -o yaml
-apiVersion: v1
-data:
-  endpoint: xxx==
-  password: yyy
-  port: MzMwNg==
-  username: b2FtdGVzdA==
-kind: Secret
-```
-
-### Consume the Cloud Resource
-
-In this section, we will show how another component consumes the RDS instance.
-
-> Note: we recommend defining the cloud resource claiming to an independent application if that cloud resource has
-> standalone lifecycle.
-
-Now create the Application to consume the data.
-
-```yaml
-apiVersion: core.oam.dev/v1beta1
-kind: Application
-metadata:
-  name: webapp
-spec:
-  components:
-    - name: express-server
-      type: webconsumer
-      properties:
-        image: zzxwill/flask-web-application:v0.3.1-crossplane
-        ports: 80
-        dbSecret: db-conn
-```
-
-```shell
-$ kubectl get application
-NAME       AGE
-baas-rds   10h
-webapp     14h
-
-$ kubectl get deployment
-NAME                READY   UP-TO-DATE   AVAILABLE   AGE
-express-server-v1   1/1     1            1           9h
-
-$ kubectl port-forward deployment/express-server 80:80
-```
-
-We can see the cloud resource is successfully consumed by the application.
-
-![](../resources/crossplane-visit-application.jpg)

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

@@ -1,13 +1,23 @@
 ---
-title: Provision and Consume Cloud Resources by Terraform
+title: Cloud Services
 ---
 
-> ⚠️ This section requires your platform builder has already installed the [Terraform related capabilities](../platform-engineers/terraform).
+KubeVela allows you to declare cloud services your application needs in consistent API. Currently, we support both Terraform and Crossplane.
+
+> Please check [the platform team guide for cloud services](../../platform-engineers/cloud-services) if you are interested in how these capabilities are maintained in KubeVela.
+
+The cloud services will be consumed by the application via [Service Binding Trait](../traits/service-binding).
+
+## Terraform
+
+> ⚠️ This section assumes [Terraform related capabilities](../../platform-engineers/terraform) have been installed in your platform.
 
 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 |
@@ -26,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 |
@@ -36,7 +49,9 @@ $ kubectl vela show service-binding
 +-------------+------------------------------------------------+------------------+----------+---------+
 ```
 
-Now apply an [application](https://github.com/oam-dev/kubevela/tree/master/docs/examples/terraform/cloud-resource-provision-and-consume/application.yaml) as below.
+### Alibaba Cloud RDS and OSS
+
+A sample [application](https://github.com/oam-dev/kubevela/tree/master/docs/examples/terraform/cloud-resource-provision-and-consume/application.yaml) is as below.
 
 ```yaml
 apiVersion: core.oam.dev/v1beta1
@@ -87,18 +102,96 @@ spec:
 
 ```
 
-Apply it and verify the application.
+## Crossplane
+
+> ⚠️ This section assumes [Crossplane related capabilities](../../platform-engineers/crossplane) have been installed in your platform.
+
+### Alibaba Cloud RDS and OSS
+
+Check the parameters of cloud service component:
 
 ```shell
-$ kubectl get application
+kubectl vela show alibaba-rds
+```
+```console
+# Properties
++---------------+------------------------------------------------+--------+----------+--------------------+
+|     NAME      |                  DESCRIPTION                   |  TYPE  | REQUIRED |      DEFAULT       |
++---------------+------------------------------------------------+--------+----------+--------------------+
+| engine        | RDS engine                                     | string | true     | mysql              |
+| engineVersion | The version of RDS engine                      | string | true     |                8.0 |
+| instanceClass | The instance class for the RDS                 | string | true     | rds.mysql.c1.large |
+| username      | RDS username                                   | string | true     |                    |
+| secretName    | Secret name which RDS connection will write to | string | true     |                    |
++---------------+------------------------------------------------+--------+----------+--------------------+
+```
+A sample application is as below.
+
+```yaml
+apiVersion: core.oam.dev/v1beta1
+kind: Application
+metadata:
+  name: webapp
+spec:
+  components:
+    - name: express-server
+      type: webservice
+      properties:
+        image: zzxwill/flask-web-application:v0.3.1-crossplane
+        ports: 80
+      traits:
+        - type: service-binding
+          properties:
+            envMappings:
+              # environments refer to db-conn secret
+              DB_PASSWORD:
+                secret: db-conn
+                key: password                                     # 1) If the env name is different from secret key, secret key has to be set.
+              endpoint:
+                secret: db-conn                                   # 2) If the env name is the same as the secret key, secret key can be omitted.
+              username:
+                secret: db-conn
+              # environments refer to oss-conn secret
+              BUCKET_NAME:
+                secret: oss-conn
+                key: Bucket
+
+    - name: sample-db
+      type: alibaba-rds
+      properties:
+        name: sample-db
+        engine: mysql
+        engineVersion: "8.0"
+        instanceClass: rds.mysql.c1.large
+        username: oamtest
+        secretName: db-conn
+
+    - name: sample-oss
+      type: alibaba-oss
+      properties:
+        name: velaweb
+        secretName: oss-conn
+```
+
+## Verify
+
+Deploy and verify the application (by either provider is OK).
+
+```shell
+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
 Handling connection for 80
 ```
 
-![](../resources/crossplane-visit-application.jpg)
+![](../../resources/crossplane-visit-application.jpg)

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

@@ -0,0 +1,54 @@
+---
+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.
+- [CUE](../../platform-engineers/cue/component) - CUE is powerful approach to encapsulate a component and it doesn't require any repository.
+- [Simple Template](../../platform-engineers/kube/component) - Not a Helm or CUE expert? A simple template approach is also provided to define any Kubernetes API resource as a component. Note that only key-value style parameters are supported in this case.
+- [Cloud Services](../../platform-engineers/cloud-services) - KubeVela allows you to declare cloud services as part of the application and provision them in consistent API.

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

@@ -0,0 +1,38 @@
+---
+title:  Task
+---
+
+## Description
+
+Describes jobs that run code or a script to completion.
+
+## Samples
+
+```yaml
+apiVersion: core.oam.dev/v1beta1
+kind: Application
+metadata:
+  name: app-worker
+spec:
+  components:
+    - name: mytask
+      type: task
+      properties:
+        image: perl
+	    count: 10
+	    cmd: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
+```
+
+## Specification
+
+```console
+# Properties
++---------+--------------------------------------------------------------------------------------------------+----------+----------+---------+
+|  NAME   |                                           DESCRIPTION                                            |   TYPE   | REQUIRED | DEFAULT |
++---------+--------------------------------------------------------------------------------------------------+----------+----------+---------+
+| cmd     | Commands to run in the container                                                                 | []string | false    |         |
+| count   | specify number of tasks to run in parallel                                                       | int      | true     |       1 |
+| restart | Define the job restart policy, the value can only be Never or OnFailure. By default, it's Never. | string   | true     | Never   |
+| image   | Which image would you like to use for your service                                               | string   | true     |         |
++---------+--------------------------------------------------------------------------------------------------+----------+----------+---------+
+```

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

@@ -1,107 +1,82 @@
 ---
-title: Explore Applications
+title:  Web Service
 ---
 
-We will introduce how to explore application related resources in this section.
+## Description
 
-## List Application
+Describes long-running, scalable, containerized services that have a stable network endpoint to receive external network traffic from customers.
 
-```shell
-$ kubectl get application
-NAME        COMPONENT   TYPE         PHASE     HEALTHY   STATUS   AGE
-app-basic   app-basic   webservice   running   true               12d
-website     frontend    webservice   running   true               4m54s
-```
+## Samples
 
-You can also use the short name `kubectl get app`.
-
-### View Application Details
-
-```shell
-$ kubectl get app website -o yaml
+```yaml
 apiVersion: core.oam.dev/v1beta1
 kind: Application
 metadata:
-  generation: 1
   name: website
-  namespace: default
 spec:
   components:
-  - name: frontend
-    properties:
-      image: nginx
-    traits:
-    - properties:
-        cpuPercent: 60
-        max: 10
-        min: 1
-      type: cpuscaler
-    - properties:
-        image: fluentd
-        name: sidecar-test
-      type: sidecar
-    type: webservice
-  - name: backend
-    properties:
-      cmd:
-      - sleep
-      - "1000"
-      image: busybox
-    type: worker
-status:
-  ...
-  latestRevision:
-    name: website-v1
-    revision: 1
-    revisionHash: e9e062e2cddfe5fb
-  services:
-  - healthy: true
-    name: frontend
-    traits:
-    - healthy: true
-      type: cpuscaler
-    - healthy: true
-      type: sidecar
-  - healthy: true
-    name: backend
-  status: running
+    - name: frontend
+      type: webservice
+      properties:
+        image: oamdev/testapp:v1
+        cmd: ["node", "server.js"]
+        port: 8080
+        cpu: "0.1"
+        env:
+          - name: FOO
+            value: bar
+          - name: FOO
+            valueFrom:
+              secretKeyRef:
+                name: bar
+                key: bar
 ```
 
-Here are some highlight information that you need to know:
+### Declare Volumes
 
-1. `status.latestRevision` declares current revision of this application.
-2. `status.services` declares the component created by this application and the healthy state.
-3. `status.status` declares the global state of this application. 
+The `Web Service` component exposes configurations for certain volume types including `PersistenVolumeClaim`, `ConfigMap`, `Secret`, and `EmptyDir`.
 
-### List Application Revisions
-
-When we update an application, if there's any difference on spec, KubeVela will create a new revision.
-
-```shell
-$ kubectl get apprev -l app.oam.dev/name=website
-NAME           AGE
-website-v1     35m
+```yaml
+apiVersion: core.oam.dev/v1beta1
+kind: Application
+metadata:
+  name: website
+spec:
+  components:
+    - name: frontend
+      type: webservice
+      properties:
+        image: nginx
+        volumes:
+          - name: "my-pvc"    
+            mountPath: "/var/www/html1" 
+            type: "pvc"     # PersistenVolumeClaim volume
+            claimName: "myclaim"
+          - name: "my-cm"    
+            mountPath: "/var/www/html2"
+            type: "configMap"    # ConfigMap volume (specifying items)
+            cmName: "myCmName"
+            items:
+              - key: "k1"
+                path: "./a1"
+              - key: "k2"
+                path: "./a2"
+          - name: "my-cm-noitems"
+            mountPath: "/var/www/html22"
+            type: "configMap"    # ConfigMap volume (not specifying items)
+            cmName: "myCmName2"
+          - name: "mysecret"
+            type: "secret"     # Secret volume
+            mountPath: "/var/www/html3"
+            secretName: "mysecret"
+          - name: "my-empty-dir"
+            type: "emptyDir"    # EmptyDir volume
+            mountPath: "/var/www/html4"
 ```
 
-## Explore Components
+## Specification
 
-You can explore what kinds of component definitions supported in your system.
-
-```shell
-kubectl get comp -n vela-system
-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. 
-worker            Deployment      Describes long-running, scalable, containerized services that running at backend. They do NOT have network endpoint to receive external network traffic.
-```
-
-The component definition objects are namespace isolated align with application, while the `vela-system` is a common system namespace of KubeVela,
-definitions laid here can be used by every application. 
-
-You can use [vela kubectl plugin](./kubectlplugin) to view the detail usage of specific component definition.
-
-```shell
-$ kubectl vela show webservice
+```console
 # Properties
 +------------------+----------------------------------------------------------------------------------+-----------------------+----------+---------+
 |       NAME       |                                   DESCRIPTION                                    |         TYPE          | REQUIRED | DEFAULT |
@@ -151,34 +126,4 @@ $ kubectl vela show webservice
 | name | The name of the secret in the pod's namespace to select from     | string | true     |         |
 | key  | The key of the secret to select from. Must be a valid secret key | string | true     |         |
 +------+------------------------------------------------------------------+--------+----------+---------+
-```
-
-## Explore Traits
-
-You can explore what kinds of trait definitions supported in your system.
-
-```shell
-$ kubectl get trait -n vela-system
-NAME                                       APPLIES-TO            DESCRIPTION                                     
-cpuscaler                                  [webservice worker]   configure k8s HPA with CPU metrics for Deployment
-ingress                                    [webservice worker]   Configures K8s ingress and service to enable web traffic for your service. Please use route trait in cap center for advanced usage.
-scaler                                     [webservice worker]   Configures replicas for your service.
-sidecar                                    [webservice worker]   inject a sidecar container into your app
-```
-
-The trait definition objects are namespace isolated align with application, while the `vela-system` is a common system namespace of KubeVela,
-definitions laid here can be used by every application. 
-
-You can use `kubectl vela show` to see the usage of specific trait definition.
-
-```shell
-$ kubectl vela show sidecar
-# Properties
-+---------+-----------------------------------------+----------+----------+---------+
-|  NAME   |               DESCRIPTION               |   TYPE   | REQUIRED | DEFAULT |
-+---------+-----------------------------------------+----------+----------+---------+
-| name    | Specify the name of sidecar container   | string   | true     |         |
-| image   | Specify the image of sidecar container  | string   | true     |         |
-| command | Specify the commands run in the sidecar | []string | false    |         |
-+---------+-----------------------------------------+----------+----------+---------+
 ```

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

@@ -0,0 +1,37 @@
+---
+title:  Worker
+---
+
+## Description
+
+Describes long-running, scalable, containerized services that running at backend. They do NOT have network endpoint to receive external network traffic.
+
+## Samples
+
+```yaml
+apiVersion: core.oam.dev/v1beta1
+kind: Application
+metadata:
+  name: app-worker
+spec:
+  components:
+    - name: myworker
+      type: worker
+      properties:
+        image: "busybox"
+        cmd:
+          - sleep
+          - "1000"
+```
+
+## Specification
+
+```console
+# Properties
++-------+----------------------------------------------------+----------+----------+---------+
+| NAME  |                    DESCRIPTION                     |   TYPE   | REQUIRED | DEFAULT |
++-------+----------------------------------------------------+----------+----------+---------+
+| cmd   | Commands to run in the container                   | []string | false    |         |
+| image | Which image would you like to use for your service | string   | true     |         |
++-------+----------------------------------------------------+----------+----------+---------+
+``` 

docs/en/end-user/debug.md

@@ -1,8 +1,8 @@
 ---
-title: Debug and Test
+title: Dry-Run and Live-Diff
 ---
 
-You can make further debug and test for your application by using [vela kubectl plugin](./kubectlplugin).
+KubeVela allows you to dry-run and live-diff your application.
 
 ## Dry-Run the `Application`
 
@@ -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/kubectlplugin.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/end-user/labels.md

@@ -1,74 +0,0 @@
----
-title: Labels and Annotations
----
-
-We will introduce how to add labels and annotations to your Application.
-
-## List Traits
-
-```bash
-$ kubectl get trait -n vela-system
-NAME          APPLIES-TO                DESCRIPTION
-annotations   ["webservice","worker"]   Add annotations for your Workload.
-cpuscaler     ["webservice","worker"]   configure k8s HPA with CPU metrics for Deployment
-ingress       ["webservice","worker"]   Configures K8s ingress and service to enable web traffic for your service. Please use route trait in cap center for advanced usage.
-labels        ["webservice","worker"]   Add labels for your Workload.
-scaler        ["webservice","worker"]   Configures replicas for your service by patch replicas field.
-sidecar       ["webservice","worker"]   inject a sidecar container into your app
-```
-
-You can use `label` and `annotations` traits to add labels and annotations for your workload.
-
-## Apply Application
-
-Let's use `label` and `annotations` traits in your Application.
-
-```shell
-# myapp.yaml
-apiVersion: core.oam.dev/v1beta1
-kind: Application
-metadata:
-  name: myapp
-spec:
-  components:
-    - name: express-server
-      type: webservice
-      properties:
-        image: crccheck/hello-world
-        port: 8000
-      traits:
-        - type: labels
-          properties:
-            "release": "stable"
-        - type: annotations
-          properties:
-            "description": "web application"
-```
-
-Apply this Application.
-
-```shell
-kubectl apply -f myapp.yaml
-```
-
-Check the workload has been created successfully.
-
-```bash
-$ kubectl get deployments
-NAME             READY   UP-TO-DATE   AVAILABLE   AGE
-express-server   1/1     1            1           15s
-```
-
-Check the `labels` trait.
-
-```bash
-$ kubectl get deployments express-server -o jsonpath='{.spec.template.metadata.labels}'
-{"app.oam.dev/component":"express-server","release": "stable"}
-```
-
-Check the `annotations` trait.
-
-```bash
-$ kubectl get deployments express-server -o jsonpath='{.spec.template.metadata.annotations}'
-{"description":"web application"}
-```

docs/en/end-user/rollout-app.md

@@ -1,97 +0,0 @@
----
-title: Application Rollout
----
-In this documentation, we will show how to use the rollout plan within application to do progressive rollout.
-## Overview
-
-By default, when we update the spec of Application, KubeVela will update workload directly which relies on the underlying workload to provide availability.
-
-KubeVela provides a unified progressive rollout mechanism, you can specify the `spec.rolloutPlan` in application to do so.
-
-## User Workflow
-Here is the end to end user experience based on Deployment
-
-
-1. Deploy application to the cluster
-  ```yaml
-apiVersion: core.oam.dev/v1beta1
-kind: Application
-metadata:
-  name: test-rolling
-spec:
-  components:
-    - name: metrics-provider
-      type: worker
-      properties:
-        cmd:
-          - ./podinfo
-          - stress-cpu=1.0
-        image: stefanprodan/podinfo:4.0.6
-        port: 8080
-  rolloutPlan:
-    rolloutStrategy: "IncreaseFirst"
-    rolloutBatches:
-      - replicas: 50%
-      - replicas: 50%
-    targetSize: 6
-  ```
-
-2. User can  modify the application container command and apply
-  ```yaml
-apiVersion: core.oam.dev/v1beta1
-kind: Application
-metadata:
-  name: test-rolling
-spec:
-  components:
-    - name: metrics-provider
-      type: worker
-      properties:
-        cmd:
-          - ./podinfo
-          - stress-cpu=2.0
-        image: stefanprodan/podinfo:4.0.6
-        port: 8080
-  rolloutPlan:
-    rolloutStrategy: "IncreaseFirst"
-    rolloutBatches:
-      - replicas: 50%
-      - replicas: 50%
-    targetSize: 6
-  ```
-
-User can check the status of the Application and see the rollout completes, and the
-Application's `status.rollout.rollingState` becomes `rolloutSucceed`
-
-## Using AppRollout to adopt Application with rolloutPlan
-
-Sometimes, we want to use [AppRollout](../rollout/rollout) to adopt the Application Rollout, so we can use the `AppRollout` to specify more specific revision. The `AppRollout` can both rollout or revert the version of application.
-
-If you want to let `AppRollout` adopt the Application with `rolloutPlan`, please add the annotations in application to tell `AppRollout` to adopt rollout, and clean the strategy in `spec.rolloutPlan` to avoid conflicts.
-
-eg. to let AppRollout adopt the application above, you should update the application like below:
-```shell
-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=2.0
-        image: stefanprodan/podinfo:4.0.6
-        port: 8080
-```
-
-Please refer to [AppRollout](../rollout/rollout) to learn more details.
-
-
-
-

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

@@ -0,0 +1,306 @@
+---
+title: Advanced Rollout Plan
+---
+
+The rollout plan feature in KubeVela is essentially provided by `AppRollout` API.
+
+## AppRollout Specification
+
+The following describes all the available fields of a AppRollout:
+
+```yaml
+apiVersion: core.oam.dev/v1beta1
+kind: AppRollout
+metadata:
+  name: rolling-example
+spec:
+  # SourceAppRevisionName contains the name of the appRevisionName that we need to upgrade from.
+  # it can be empty only when you want to scale an  application. +optional
+  sourceAppRevisionName: test-rolling-v1
+  
+  # TargetAppRevisionName contains the name of the appRevisionName that we need to upgrade to.
+  targetAppRevisionName: test-rolling-v2
+  
+  # The list of component to upgrade in the application.
+  # We only support single component application so far. +optional
+  componentList:
+    - metrics-provider
+  # RolloutPlan is the details on how to rollout the resources
+  rolloutPlan:
+    
+    # RolloutStrategy defines strategies for the rollout plan
+    # the value can be IncreaseFirst or DecreaseFirst
+    # Defaults to IncreaseFirst. +optional
+    rolloutStrategy: "IncreaseFirst"
+    
+    # The exact distribution among batches.
+    # its size has to be exactly the same as the NumBatches (if set)
+    # The total number cannot exceed the targetSize or the size of the source resource
+    # We will IGNORE the last batch's replica field if it's a percentage since round errors can lead to inaccurate sum
+    # We highly recommend to leave the last batch's replica field empty
+    rolloutBatches:
+        
+      # Replicas is the number of pods to upgrade in this batch
+      # it can be an absolute number (ex: 5) or a percentage of total pods
+      # we will ignore the percentage of the last batch to just fill the gap
+      # Below is an example the first batch contains only 1 pod while the rest of the batches split the rest.
+      - replicas: 1
+      - replicas: 50%
+      - replicas: 50%
+        
+    # All pods in the batches up to the batchPartition (included) will have
+    # the target resource specification while the rest still have the source resource
+    # This is designed for the operators to manually rollout
+    # Default is the the number of batches which will rollout all the batches. +optional
+    batchPartition: 1
+
+    # Paused the rollout
+    # defaults to false. +optional
+    paused: false
+
+    # The size of the target resource. In rollout operation it's the same as the size of the source resource.
+    # when use rollout to scale an application targetSize is the target source you want scale to.  +optional
+    targetSize: 4
+```
+
+## 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
+    ```
+
+### Scale the application
+
+Before using AppRollout to scale an application, we must be aware of the real status of workload now. Check the workload status. 
+
+```shell
+$ kubectl get deploy metrics-provider-v3
+ NAME                  READY   UP-TO-DATE   AVAILABLE   AGE
+ metrics-provider-v3   5/5     5            5           10m
+```
+
+Last target appRevision is `test-rolling-v3` and the workload have 5 replicas currently.
+
+8. Apply the appRollout increase the replicas nums of workload to 7.
+    ```yaml
+    apiVersion: core.oam.dev/v1beta1
+    kind: AppRollout
+    metadata:
+      name: rolling-example
+    spec:
+      # sourceAppRevisionName is empty means this is a scale operation
+      targetAppRevisionName: test-rolling-v3
+      componentList:
+      - metrics-provider
+      rolloutPlan:
+         rolloutStrategy: "IncreaseFirst"
+         rolloutBatches:
+         # split two batches to scale. First batch increase 1 pod and second increase 1.
+           - replicas: 1
+           - replicas: 1
+         # targetSize means that final total size of workload is 7
+         targetSize: 7
+    ```
+
+## 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

@@ -1,12 +1,10 @@
 ---
-title: Multi-Cluster Deployment
+title: Placement
 ---
 
 ## Introduction
 
-Modern application infrastructure involves multiple clusters to ensure high availability and maximize service throughput. In this section, we will introduce how to use KubeVela to achieve application deployment across multiple clusters with following features supported:
-- Rolling Upgrade: To continuously deploy apps requires to rollout in a safe manner which usually involves step by step rollout batches and analysis.
-- Traffic shifting: When rolling upgrade an app, it needs to split the traffic onto both the old and new revisions to verify the new version while preserving service availability.
+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
 
@@ -107,7 +105,7 @@ You must run all commands in that directory.
 1. Create an Application
 
    ```bash
-   $ cat <<EOF | kubectl apply -f -
+   cat <<EOF | kubectl apply -f -
    apiVersion: core.oam.dev/v1beta1
    kind: Application
    metadata:
@@ -128,7 +126,9 @@ You must run all commands in that directory.
    This will create `example-app-v1` AppRevision. Check it:
 
    ```bash
-   $ kubectl get applicationrevisions.core.oam.dev
+   kubectl get applicationrevisions.core.oam.dev
+   ```
+   ```console
    NAME             AGE
    example-app-v1   116s
    ```
@@ -138,7 +138,7 @@ You must run all commands in that directory.
 1. Then use the above AppRevision to create an AppDeployment.
 
    ```bash
-   $ kubectl apply -f appdeployment-1.yaml
+   kubectl apply -f appdeployment-1.yaml
    ```
 
    > Note: in order to AppDeployment to work, your workload object must have a `spec.replicas` field for scaling.
@@ -146,7 +146,9 @@ You must run all commands in that directory.
 1. Now you can check that there will 1 deployment and 2 pod instances deployed
 
    ```bash
-   $ kubectl get deploy
+   kubectl get deploy
+   ```
+   ```console
    NAME         READY   UP-TO-DATE   AVAILABLE   AGE
    testsvc-v1   2/2     2            0           27s
    ```
@@ -154,7 +156,7 @@ You must run all commands in that directory.
 1. Update Application properties:
 
    ```bash
-   $ cat <<EOF | kubectl apply -f -
+   cat <<EOF | kubectl apply -f -
    apiVersion: core.oam.dev/v1beta1
    kind: Application
    metadata:
@@ -175,7 +177,9 @@ You must run all commands in that directory.
    This will create a new `example-app-v2` AppRevision. Check it:
 
    ```bash
-   $ kubectl get applicationrevisions.core.oam.dev
+   kubectl get applicationrevisions.core.oam.dev
+   ```
+   ```console
    NAME
    example-app-v1
    example-app-v2
@@ -184,16 +188,16 @@ You must run all commands in that directory.
 1. Then use the two AppRevisions to update the AppDeployment:
 
    ```bash
-   $ kubectl apply -f appdeployment-2.yaml
+   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 gateway.yaml
 
-   $ kubectl apply -f appdeployment-2-traffic.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)):
@@ -206,7 +210,9 @@ You must run all commands in that directory.
 1. Now you can check that there will 1 deployment and 1 pod per revision.
 
    ```bash
-   $ kubectl get deploy
+   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
@@ -216,7 +222,9 @@ You must run all commands in that directory.
 
    ```bash
    # run this in another terminal
-   $ kubectl -n istio-system port-forward service/istio-ingressgateway 8080:80
+   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
 
@@ -227,6 +235,6 @@ You must run all commands in that directory.
 1. Cleanup:
 
    ```bash
-   kubectl delete appdeployments.core.oam.dev  --all
+   kubectl delete appdeployments.core.oam.dev --all
    kubectl delete applications.core.oam.dev --all
    ```