Add package discover refresh when component/trait definition are registered (#1402)

* add discover refresh

* add test

* fix store openapi schema

* fix discovermapper

.github/workflows/check-docs.yml

@@ -15,5 +15,7 @@ jobs:
         with:
           node-version: '12.x'
       - name: Test Build
+        env:
+          VERSION: ${{ github.ref }}
         run: |
-          sh ./hack/website/test-build.sh
+          bash ./hack/website/test-build.sh

.github/workflows/release-docs.yaml

@@ -11,11 +11,13 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@v1
+      - uses: actions/setup-node@v1
+        with:
+          node-version: '12.x'
       - name: Sync to kubevela.io Repo
-        uses: wonderflow/auto-docs-action@v0.2.3
         env:
-          SSH_PRIVATE_KEY: ${{ secrets.GH_PAGES_DEPLOY }}
+          SSH_DEPLOY_KEY: ${{ secrets.GH_PAGES_DEPLOY }}
           VERSION: ${{ github.ref }}
           COMMIT_ID: ${{ github.sha }}
-        with:
-          gh-page: git@github.com:oam-dev/kubevela.io.git
+        run: |
+          bash ./hack/website/release.sh

.gitignore

@@ -55,3 +55,6 @@ references/dashboard/src/.umi-production/
 
 # Swagger: generate Restful API
 references/apiserver/docs/index.html
+
+# check docs
+git-page/

CONTRIBUTING.md

@@ -18,7 +18,7 @@ contributing to `kubevela` or build a PoC (Proof of Concept).
 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.
 
-We also recommend you to learn about KubeVela's [design](https://kubevela.io/#/en/concepts) before dive into its code.
+We also recommend you to learn about KubeVela's [design](https://kubevela.io/docs/concepts) before dive into its code.
 
 ### Build
 
@@ -86,7 +86,7 @@ helm uninstall -n vela-system kubevela
 
 ### Use
 
-You can try use your local built binaries follow [the documentation](https://kubevela.io/#/en/quick-start).
+You can try use your local built binaries follow [the documentation](https://kubevela.io/docs/quick-start).
 
 ## Testing
 
@@ -110,6 +110,22 @@ 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.

Makefile

@@ -62,6 +62,22 @@ doc-gen:
 	go run hack/docgen/gen.go
 	go run hack/references/generate.go
 
+docs-build:
+ifneq ($(wildcard git-page),)
+	rm -rf git-page
+endif
+	sh ./hack/website/test-build.sh
+
+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 -r git-page/resources
+	rm git-page/sidebars.js
+	cat docs/sidebars.js > git-page/sidebars.js
+	cp -R docs/en git-page/docs && cp -R docs/resources git-page/resources
+	cd git-page && yarn install && yarn start
+
 api-gen:
 	swag init -g references/apiserver/route.go --output references/apiserver/docs
 	swagger-codegen generate -l html2 -i references/apiserver/docs/swagger.yaml -o references/apiserver/docs
@@ -126,10 +142,7 @@ docker-push:
 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
-	helm repo add jetstack https://charts.jetstack.io
-	helm repo update
-	helm upgrade --install --create-namespace --namespace cert-manager cert-manager jetstack/cert-manager --version v1.2.0  --set installCRDs=true --wait
-	helm upgrade --install --create-namespace --namespace vela-system --set image.pullPolicy=IfNotPresent --set admissionWebhooks.certManager.enabled=true --set image.repository=vela-core-test --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 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

README.md

@@ -14,7 +14,7 @@
 
 # KubeVela
 
-KubeVela is the platform engine to create *PaaS-like* experience on Kubernetes, in a scalable approach.
+KubeVela is a modern application engine that adapts to your application's needs, not the other way around.
 
 ## Community
 
@@ -22,28 +22,26 @@ KubeVela is the platform engine to create *PaaS-like* experience on Kubernetes,
 - Gitter: [Discussion](https://gitter.im/oam-dev/community)
 - Bi-weekly Community Call: [Meeting Notes](https://docs.google.com/document/d/1nqdFEyULekyksFHtFvgvFAYE-0AMHKoS3RMnaKsarjs)
 
-> NOTE: KubeVela is still iterating quickly. It's currently under pre-beta release.
-
 ## What problems does it solve?
 
-Building **developer-centric platforms** with Kubernetes requires higher level primitives which is out-of-scope of Kubernetes itself. Hence, we platform teams build abstractions.
+Traditional Platform-as-a-Service (PaaS) system enables easy application deployments and everything just works, but this happiness disappears when your application outgrows the capabilities of your platform.
 
-However, great in flexibility and extensibility, the existing solutions such as IaC (Infrastructure-as-Code) and client-side templating tools all lead to ***Configuration Drift*** (i.e. the generated instances are not in line with the expected configuration) which is a nightmare in production.
+KubeVela is a modern application engine whose capabilities are actually Infrastructure-as-Code (IaC) components coded by you or come from the ecosystem. Think of it as a *Heroku* which is fully programmable to serve your needs as you grow and expand.
 
-KubeVela allows platform teams to create developer-centric abstractions with IaC but maintain them with the battle tested [Kubernetes Control Loop](https://kubernetes.io/docs/concepts/architecture/controller/). Think about a plug-in that turns your Kubernetes cluster into a *"PaaS"* via abstractions designed by yourself.
+As a plus, KubeVela leverages [Kubernetes Control Loop](https://kubernetes.io/docs/concepts/architecture/controller/) to enforce all those abstractions so they will never leave *configuration drift* (i.e. the running instances are not in line with the expected configuration) in your clusters.
 
 ## Getting Started
 
-- [Installation](https://kubevela.io/#/en/install)
-- [Quick start](https://kubevela.io/#/en/quick-start)
-- [How it works](https://kubevela.io/#/en/concepts)
+- [Installation](https://kubevela.io/docs/install)
+- [Quick start](https://kubevela.io/docs/quick-start)
+- [How it works](https://kubevela.io/docs/concepts)
 
 ## Features
 
-- **Robust, repeatable and extensible approach to create and maintain abstractions** - design your abstractions with [CUE](https://cuelang.org/) or [Helm](https://helm.sh), ship them to end users by `kubectl apply -f`, automatically generating GUI forms, upgrade your abstractions at runtime, and let Kubernetes controller guarantee determinism of the abstractions, no configuration drift.
-- **Generic progressive rollout framework** - built-in rollout framework and strategies to upgrade your microservice regardless of its workload type (e.g. stateless, stateful, or even custom operators etc), seamless integration with observability systems.
-- **Multi-enviroment app delievry model (WIP)** - built-in model to deliver or rollout your apps across multiple enviroments and/or clusters, seamless integration with Service Mesh for traffic management. 
-- **Simple and Kubernetes native** - KubeVela is just a simple custom controller, all its app delivery abstractions and features are defined as [Kubernetes Custom Resources](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) so they naturally work with any CI/CD or GitOps tools.
+- **Zero-restriction deployment** - design and express platform capabilities with [CUE](https://cuelang.org/) or [Helm](https://helm.sh) per needs of your application, and let Kubernetes controller guarantee the deployment determinism. GUI forms are automatically generated for capabilities so even your dashboard are fully extensible.
+- **Generic progressive rollout framework** - built-in rollout framework and strategies to upgrade your microservice regardless of its workload type (e.g. stateless, stateful, or even custom operators etc).
+- **Multi-cluster multi-revision application deployment** - built-in model to deploy or rollout your apps across hybrid infrastructures, with Service Mesh for traffic shifting. 
+- **Simple and native** - KubeVela is a just simple Kubernetes custom controller, all its capabilities are defined as [Custom Resources](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) so they naturally work with any CI/CD or GitOps tools that works with Kubernetes.
 
 ## Documentation
 

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

@@ -88,8 +88,14 @@ type ApplicationSpec struct {
 
 // Application is the Schema for the applications API
 // +kubebuilder:object:root=true
-// +kubebuilder:resource:categories={oam}
+// +kubebuilder:resource:categories={oam},shortName=app
 // +kubebuilder:subresource:status
+// +kubebuilder:printcolumn:name="COMPONENT",type=string,JSONPath=`.spec.components[*].name`
+// +kubebuilder:printcolumn:name="TYPE",type=string,JSONPath=`.spec.components[*].type`
+// +kubebuilder:printcolumn:name="PHASE",type=string,JSONPath=`.status.status`
+// +kubebuilder:printcolumn:name="HEALTHY",type=boolean,JSONPath=`.status.services[*].healthy`
+// +kubebuilder:printcolumn:name="STATUS",type=string,JSONPath=`.status.services[*].message`
+// +kubebuilder:printcolumn:name="AGE",type=date,JSONPath=".metadata.creationTimestamp"
 type Application struct {
 	metav1.TypeMeta   `json:",inline"`
 	metav1.ObjectMeta `json:"metadata,omitempty"`

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

@@ -55,7 +55,8 @@ type ApplicationRevisionSpec struct {
 
 // ApplicationRevision is the Schema for the ApplicationRevision API
 // +kubebuilder:object:root=true
-// +kubebuilder:shortName=apprev,resource:categories={oam}
+// +kubebuilder:resource:categories={oam},shortName=apprev
+// +kubebuilder:printcolumn:name="AGE",type=date,JSONPath=".metadata.creationTimestamp"
 type ApplicationRevision struct {
 	metav1.TypeMeta   `json:",inline"`
 	metav1.ObjectMeta `json:"metadata,omitempty"`

apis/core.oam.dev/v1alpha2/approllout_types.go

@@ -61,8 +61,14 @@ type AppRolloutStatus struct {
 
 // AppRollout is the Schema for the AppRollout API
 // +kubebuilder:object:root=true
-// +kubebuilder:resource:categories={oam}
+// +kubebuilder:resource:categories={oam},shortName=approllout
 // +kubebuilder:subresource:status
+// +kubebuilder:printcolumn:name="TARGET",type=string,JSONPath=`.status.rolloutStatus.rolloutTargetSize`
+// +kubebuilder:printcolumn:name="UPGRADED",type=string,JSONPath=`.status.rolloutStatus.upgradedReplicas`
+// +kubebuilder:printcolumn:name="READY",type=string,JSONPath=`.status.rolloutStatus.upgradedReadyReplicas`
+// +kubebuilder:printcolumn:name="BATCH-STATE",type=string,JSONPath=`.status.rolloutStatus.batchRollingState`
+// +kubebuilder:printcolumn:name="ROLLING-STATE",type=string,JSONPath=`.status.rolloutStatus.rollingState`
+// +kubebuilder:printcolumn:name="AGE",type=date,JSONPath=".metadata.creationTimestamp"
 type AppRollout struct {
 	metav1.TypeMeta   `json:",inline"`
 	metav1.ObjectMeta `json:"metadata,omitempty"`

apis/core.oam.dev/v1alpha2/componentdefinition_types.go

@@ -67,8 +67,11 @@ type ComponentDefinitionStatus struct {
 // +kubebuilder:object:root=true
 
 // ComponentDefinition is the Schema for the componentdefinitions API
-// +kubebuilder:resource:scope=Namespaced,categories={oam}
+// +kubebuilder:resource:scope=Namespaced,categories={oam},shortName=comp
 // +kubebuilder:subresource:status
+// +kubebuilder:printcolumn:name="WORKLOAD-KIND",type=string,JSONPath=".spec.workload.definition.kind"
+// +kubebuilder:printcolumn:name="DESCRIPTION",type=string,JSONPath=".metadata.annotations.definition\\.oam\\.dev/description"
+// +kubebuilder:printcolumn:name="AGE",type=date,JSONPath=".metadata.creationTimestamp"
 type ComponentDefinition struct {
 	metav1.TypeMeta   `json:",inline"`
 	metav1.ObjectMeta `json:"metadata,omitempty"`

apis/core.oam.dev/v1alpha2/core_types.go

@@ -69,8 +69,9 @@ type WorkloadDefinitionStatus struct {
 // valid OAM workload kind by referencing its CustomResourceDefinition. The CRD
 // is used to validate the schema of the workload when it is embedded in an OAM
 // Component.
-// +kubebuilder:printcolumn:JSONPath=".spec.definitionRef.name",name=DEFINITION-NAME,type=string
-// +kubebuilder:resource:scope=Namespaced,categories={oam}
+// +kubebuilder:resource:scope=Namespaced,categories={oam},shortName=workload
+// +kubebuilder:printcolumn:name="DEFINITION-NAME",type=string,JSONPath=".spec.definitionRef.name"
+// +kubebuilder:printcolumn:name="AGE",type=date,JSONPath=".metadata.creationTimestamp"
 type WorkloadDefinition struct {
 	metav1.TypeMeta   `json:",inline"`
 	metav1.ObjectMeta `json:"metadata,omitempty"`
@@ -111,6 +112,10 @@ type TraitDefinitionSpec struct {
 	// +optional
 	WorkloadRefPath string `json:"workloadRefPath,omitempty"`
 
+	// PodDisruptive specifies whether using the trait will cause the pod to restart or not.
+	// +optional
+	PodDisruptive bool `json:"podDisruptive,omitempty"`
+
 	// AppliesToWorkloads specifies the list of workload kinds this trait
 	// applies to. Workload kinds are specified in kind.group/version format,
 	// e.g. server.core.oam.dev/v1alpha2. Traits that omit this field apply to
@@ -158,9 +163,11 @@ type TraitDefinitionStatus struct {
 // OAM trait kind by referencing its CustomResourceDefinition. The CRD is used
 // to validate the schema of the trait when it is embedded in an OAM
 // ApplicationConfiguration.
-// +kubebuilder:printcolumn:JSONPath=".spec.definitionRef.name",name=DEFINITION-NAME,type=string
-// +kubebuilder:resource:scope=Namespaced,categories={oam}
+// +kubebuilder:resource:scope=Namespaced,categories={oam},shortName=trait
 // +kubebuilder:subresource:status
+// +kubebuilder:printcolumn:name="APPLIES-TO",type=string,JSONPath=".spec.appliesToWorkloads"
+// +kubebuilder:printcolumn:name="DESCRIPTION",type=string,JSONPath=".metadata.annotations.definition\\.oam\\.dev/description"
+// +kubebuilder:printcolumn:name="AGE",type=date,JSONPath=".metadata.creationTimestamp"
 type TraitDefinition struct {
 	metav1.TypeMeta   `json:",inline"`
 	metav1.ObjectMeta `json:"metadata,omitempty"`
@@ -213,7 +220,7 @@ type ScopeDefinitionSpec struct {
 // to validate the schema of the scope when it is embedded in an OAM
 // ApplicationConfiguration.
 // +kubebuilder:printcolumn:JSONPath=".spec.definitionRef.name",name=DEFINITION-NAME,type=string
-// +kubebuilder:resource:scope=Namespaced,categories={oam}
+// +kubebuilder:resource:scope=Namespaced,categories={oam},shortName=scope
 type ScopeDefinition struct {
 	metav1.TypeMeta   `json:",inline"`
 	metav1.ObjectMeta `json:"metadata,omitempty"`

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

@@ -178,7 +178,7 @@ type AppDeploymentStatus struct {
 
 // AppDeployment is the Schema for the AppDeployment API
 // +kubebuilder:object:root=true
-// +kubebuilder:resource:categories={oam}
+// +kubebuilder:resource:categories={oam},shortName=appdeploy
 // +kubebuilder:subresource:status
 type AppDeployment struct {
 	metav1.TypeMeta   `json:",inline"`

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

@@ -67,6 +67,13 @@ type ApplicationSpec struct {
 // Application is the Schema for the applications API
 // +kubebuilder:storageversion
 // +kubebuilder:subresource:status
+// +kubebuilder:resource:categories={oam},shortName=app
+// +kubebuilder:printcolumn:name="COMPONENT",type=string,JSONPath=`.spec.components[*].name`
+// +kubebuilder:printcolumn:name="TYPE",type=string,JSONPath=`.spec.components[*].type`
+// +kubebuilder:printcolumn:name="PHASE",type=string,JSONPath=`.status.status`
+// +kubebuilder:printcolumn:name="HEALTHY",type=boolean,JSONPath=`.status.services[*].healthy`
+// +kubebuilder:printcolumn:name="STATUS",type=string,JSONPath=`.status.services[*].message`
+// +kubebuilder:printcolumn:name="AGE",type=date,JSONPath=".metadata.creationTimestamp"
 type Application struct {
 	metav1.TypeMeta   `json:",inline"`
 	metav1.ObjectMeta `json:"metadata,omitempty"`

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

@@ -56,6 +56,8 @@ type ApplicationRevisionSpec struct {
 
 // ApplicationRevision is the Schema for the ApplicationRevision API
 // +kubebuilder:storageversion
+// +kubebuilder:resource:categories={oam},shortName=apprev
+// +kubebuilder:printcolumn:name="AGE",type=date,JSONPath=".metadata.creationTimestamp"
 type ApplicationRevision struct {
 	metav1.TypeMeta   `json:",inline"`
 	metav1.ObjectMeta `json:"metadata,omitempty"`

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

@@ -41,10 +41,11 @@ type AppRolloutSpec struct {
 	// RolloutPlan is the details on how to rollout the resources
 	RolloutPlan v1alpha1.RolloutPlan `json:"rolloutPlan"`
 
-	// RevertOnDelete revert the rollout when the rollout CR is deleted
-	// It will remove the target app from the kubernetes if it's set to true
+	// RevertOnDelete revert the failed rollout when the rollout CR is deleted
+	// It will revert the change back to the source version at once (not in batches)
+	// Default is false
 	// +optional
-	RevertOnDelete *bool `json:"revertOnDelete,omitempty"`
+	RevertOnDelete bool `json:"revertOnDelete,omitempty"`
 }
 
 // AppRolloutStatus defines the observed state of AppRollout
@@ -62,9 +63,15 @@ type AppRolloutStatus struct {
 
 // AppRollout is the Schema for the AppRollout API
 // +kubebuilder:object:root=true
-// +kubebuilder:resource:categories={oam}
+// +kubebuilder:resource:categories={oam},shortName=approllout
 // +kubebuilder:subresource:status
 // +kubebuilder:storageversion
+// +kubebuilder:printcolumn:name="TARGET",type=string,JSONPath=`.status.rolloutTargetSize`
+// +kubebuilder:printcolumn:name="UPGRADED",type=string,JSONPath=`.status.upgradedReplicas`
+// +kubebuilder:printcolumn:name="READY",type=string,JSONPath=`.status.upgradedReadyReplicas`
+// +kubebuilder:printcolumn:name="BATCH-STATE",type=string,JSONPath=`.status.batchRollingState`
+// +kubebuilder:printcolumn:name="ROLLING-STATE",type=string,JSONPath=`.status.rollingState`
+// +kubebuilder:printcolumn:name="AGE",type=date,JSONPath=".metadata.creationTimestamp"
 type AppRollout struct {
 	metav1.TypeMeta   `json:",inline"`
 	metav1.ObjectMeta `json:"metadata,omitempty"`

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

@@ -67,9 +67,12 @@ type ComponentDefinitionStatus struct {
 // +kubebuilder:object:root=true
 
 // ComponentDefinition is the Schema for the componentdefinitions API
-// +kubebuilder:resource:scope=Namespaced,categories={oam}
+// +kubebuilder:resource:scope=Namespaced,categories={oam},shortName=comp
 // +kubebuilder:storageversion
 // +kubebuilder:subresource:status
+// +kubebuilder:printcolumn:name="WORKLOAD-KIND",type=string,JSONPath=".spec.workload.definition.kind"
+// +kubebuilder:printcolumn:name="DESCRIPTION",type=string,JSONPath=".metadata.annotations.definition\\.oam\\.dev/description"
+// +kubebuilder:printcolumn:name="AGE",type=date,JSONPath=".metadata.creationTimestamp"
 type ComponentDefinition struct {
 	metav1.TypeMeta   `json:",inline"`
 	metav1.ObjectMeta `json:"metadata,omitempty"`

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

@@ -20,6 +20,7 @@ import (
 	runtimev1alpha1 "github.com/crossplane/crossplane-runtime/apis/core/v1alpha1"
 	metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
 	"k8s.io/apimachinery/pkg/runtime"
+	"k8s.io/apimachinery/pkg/types"
 
 	"github.com/oam-dev/kubevela/apis/core.oam.dev/common"
 )
@@ -67,9 +68,11 @@ type WorkloadDefinitionStatus struct {
 // valid OAM workload kind by referencing its CustomResourceDefinition. The CRD
 // is used to validate the schema of the workload when it is embedded in an OAM
 // Component.
-// +kubebuilder:printcolumn:JSONPath=".spec.definitionRef.name",name=DEFINITION-NAME,type=string
-// +kubebuilder:resource:scope=Namespaced,categories={oam}
+// +kubebuilder:resource:scope=Namespaced,categories={oam},shortName=workload
 // +kubebuilder:storageversion
+// +kubebuilder:printcolumn:name="DEFINITION-NAME",type=string,JSONPath=".spec.definitionRef.name"
+// +kubebuilder:printcolumn:name="DESCRIPTION",type=string,JSONPath=".metadata.annotations.definition\\.oam\\.dev/description"
+// +kubebuilder:printcolumn:name="AGE",type=date,JSONPath=".metadata.creationTimestamp"
 type WorkloadDefinition struct {
 	metav1.TypeMeta   `json:",inline"`
 	metav1.ObjectMeta `json:"metadata,omitempty"`
@@ -110,6 +113,10 @@ type TraitDefinitionSpec struct {
 	// +optional
 	WorkloadRefPath string `json:"workloadRefPath,omitempty"`
 
+	// PodDisruptive specifies whether using the trait will cause the pod to restart or not.
+	// +optional
+	PodDisruptive bool `json:"podDisruptive,omitempty"`
+
 	// AppliesToWorkloads specifies the list of workload kinds this trait
 	// applies to. Workload kinds are specified in kind.group/version format,
 	// e.g. server.core.oam.dev/v1alpha2. Traits that omit this field apply to
@@ -157,10 +164,12 @@ type TraitDefinitionStatus struct {
 // OAM trait kind by referencing its CustomResourceDefinition. The CRD is used
 // to validate the schema of the trait when it is embedded in an OAM
 // ApplicationConfiguration.
-// +kubebuilder:printcolumn:JSONPath=".spec.definitionRef.name",name=DEFINITION-NAME,type=string
-// +kubebuilder:resource:scope=Namespaced,categories={oam}
+// +kubebuilder:resource:scope=Namespaced,categories={oam},shortName=trait
 // +kubebuilder:subresource:status
 // +kubebuilder:storageversion
+// +kubebuilder:printcolumn:name="APPLIES-TO",type=string,JSONPath=".spec.appliesToWorkloads"
+// +kubebuilder:printcolumn:name="DESCRIPTION",type=string,JSONPath=".metadata.annotations.definition\\.oam\\.dev/description"
+// +kubebuilder:printcolumn:name="AGE",type=date,JSONPath=".metadata.creationTimestamp"
 type TraitDefinition struct {
 	metav1.TypeMeta   `json:",inline"`
 	metav1.ObjectMeta `json:"metadata,omitempty"`
@@ -213,7 +222,7 @@ type ScopeDefinitionSpec struct {
 // to validate the schema of the scope when it is embedded in an OAM
 // ApplicationConfiguration.
 // +kubebuilder:printcolumn:JSONPath=".spec.definitionRef.name",name=DEFINITION-NAME,type=string
-// +kubebuilder:resource:scope=Namespaced,categories={oam}
+// +kubebuilder:resource:scope=Namespaced,categories={oam},shortName=scope
 // +kubebuilder:storageversion
 type ScopeDefinition struct {
 	metav1.TypeMeta   `json:",inline"`
@@ -232,12 +241,41 @@ type ScopeDefinitionList struct {
 }
 
 // +kubebuilder:object:root=true
+// +kubebuilder:subresource:status
 
 // An ResourceTracker represents a tracker for track cross namespace resources
-// +kubebuilder:resource:scope=Cluster,categories={oam}
+// +kubebuilder:resource:scope=Cluster,categories={oam},shortName=tracker
 type ResourceTracker struct {
 	metav1.TypeMeta   `json:",inline"`
 	metav1.ObjectMeta `json:"metadata,omitempty"`
+
+	Status ResourceTrackerStatus `json:"status,omitempty"`
+}
+
+// ResourceTrackerStatus define the status of resourceTracker
+type ResourceTrackerStatus struct {
+	TrackedResources []TypedReference `json:"trackedResources,omitempty"`
+}
+
+// A TypedReference refers to an object by Name, Kind, and APIVersion. It is
+// commonly used to reference across-namespace objects
+type TypedReference struct {
+	// APIVersion of the referenced object.
+	APIVersion string `json:"apiVersion"`
+
+	// Kind of the referenced object.
+	Kind string `json:"kind"`
+
+	// Name of the referenced object.
+	Name string `json:"name"`
+
+	// Namespace of the objects outside the application namespace.
+	// +optional
+	Namespace string `json:"namespace,omitempty"`
+
+	// UID of the referenced object.
+	// +optional
+	UID types.UID `json:"uid,omitempty"`
 }
 
 // +kubebuilder:object:root=true

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

@@ -225,11 +225,6 @@ func (in *AppRolloutSpec) DeepCopyInto(out *AppRolloutSpec) {
 		copy(*out, *in)
 	}
 	in.RolloutPlan.DeepCopyInto(&out.RolloutPlan)
-	if in.RevertOnDelete != nil {
-		in, out := &in.RevertOnDelete, &out.RevertOnDelete
-		*out = new(bool)
-		**out = **in
-	}
 }
 
 // DeepCopy is an autogenerated deepcopy function, copying the receiver, creating a new AppRolloutSpec.
@@ -867,6 +862,7 @@ func (in *ResourceTracker) DeepCopyInto(out *ResourceTracker) {
 	*out = *in
 	out.TypeMeta = in.TypeMeta
 	in.ObjectMeta.DeepCopyInto(&out.ObjectMeta)
+	in.Status.DeepCopyInto(&out.Status)
 }
 
 // DeepCopy is an autogenerated deepcopy function, copying the receiver, creating a new ResourceTracker.
@@ -919,6 +915,26 @@ func (in *ResourceTrackerList) DeepCopyObject() runtime.Object {
 	return nil
 }
 
+// DeepCopyInto is an autogenerated deepcopy function, copying the receiver, writing into out. in must be non-nil.
+func (in *ResourceTrackerStatus) DeepCopyInto(out *ResourceTrackerStatus) {
+	*out = *in
+	if in.TrackedResources != nil {
+		in, out := &in.TrackedResources, &out.TrackedResources
+		*out = make([]TypedReference, len(*in))
+		copy(*out, *in)
+	}
+}
+
+// DeepCopy is an autogenerated deepcopy function, copying the receiver, creating a new ResourceTrackerStatus.
+func (in *ResourceTrackerStatus) DeepCopy() *ResourceTrackerStatus {
+	if in == nil {
+		return nil
+	}
+	out := new(ResourceTrackerStatus)
+	in.DeepCopyInto(out)
+	return out
+}
+
 // DeepCopyInto is an autogenerated deepcopy function, copying the receiver, writing into out. in must be non-nil.
 func (in *ScopeDefinition) DeepCopyInto(out *ScopeDefinition) {
 	*out = *in
@@ -1146,6 +1162,21 @@ func (in *TraitDefinitionStatus) DeepCopy() *TraitDefinitionStatus {
 	return out
 }
 
+// DeepCopyInto is an autogenerated deepcopy function, copying the receiver, writing into out. in must be non-nil.
+func (in *TypedReference) DeepCopyInto(out *TypedReference) {
+	*out = *in
+}
+
+// DeepCopy is an autogenerated deepcopy function, copying the receiver, creating a new TypedReference.
+func (in *TypedReference) DeepCopy() *TypedReference {
+	if in == nil {
+		return nil
+	}
+	out := new(TypedReference)
+	in.DeepCopyInto(out)
+	return out
+}
+
 // DeepCopyInto is an autogenerated deepcopy function, copying the receiver, writing into out. in must be non-nil.
 func (in *URIMatch) DeepCopyInto(out *URIMatch) {
 	*out = *in

apis/standard.oam.dev/v1alpha1/rollout_plan_types.go

@@ -50,6 +50,9 @@ const (
 type RollingState string
 
 const (
+	// LocatingTargetAppState indicates that the rollout is in the stage of locating target app
+	// we use this state to make sure we special handle the target app successfully only once
+	LocatingTargetAppState RollingState = "locatingTargetApp"
 	// VerifyingSpecState indicates that the rollout is in the stage of verifying the rollout settings
 	// and the controller can locate both the target and the source
 	VerifyingSpecState RollingState = "verifyingSpec"
@@ -64,8 +67,12 @@ const (
 	RolloutFailingState RollingState = "rolloutFailing"
 	// RolloutSucceedState indicates that rollout successfully completed to match the desired target state
 	RolloutSucceedState RollingState = "rolloutSucceed"
-	// RolloutAbandoningState indicates that the rollout is abandoned, can be restarted. This is a terminal state
-	RolloutAbandoningState RollingState = "rolloutAbandoned"
+	// RolloutAbandoningState indicates that the rollout is being abandoned
+	// we need to finalize it by cleaning up the old resources, adjust traffic and return control back to its owner
+	RolloutAbandoningState RollingState = "rolloutAbandoning"
+	// RolloutDeletingState indicates that the rollout is being deleted
+	// we need to finalize it by cleaning up the old resources, adjust traffic and return control back to its owner
+	RolloutDeletingState RollingState = "RolloutDeletingState"
 	// RolloutFailedState indicates that rollout is failed, the target replica is not reached
 	// we can not move forward anymore, we will let the client to decide when or whether to revert.
 	RolloutFailedState RollingState = "rolloutFailed"
@@ -240,9 +247,13 @@ type RolloutStatus struct {
 	// Conditions represents the latest available observations of a CloneSet's current state.
 	runtimev1alpha1.ConditionedStatus `json:",inline"`
 
-	// RolloutTargetTotalSize is the size of the target resources. This is determined once the initial spec verification
+	// RolloutTargetSize is the size of the target resources. This is determined once the initial spec verification
 	// and does not change until the rollout is restarted
-	RolloutTargetTotalSize int32 `json:"rolloutTargetSize,omitempty"`
+	RolloutOriginalSize int32 `json:"rolloutOriginalSize,omitempty"`
+
+	// RolloutTargetSize is the size of the target resources. This is determined once the initial spec verification
+	// and does not change until the rollout is restarted
+	RolloutTargetSize int32 `json:"rolloutTargetSize,omitempty"`
 
 	// NewPodTemplateIdentifier is a string that uniquely represent the new pod template
 	// each workload type could use different ways to identify that so we cannot compare between resources

apis/standard.oam.dev/v1alpha1/rollout_state.go

@@ -36,9 +36,15 @@ const (
 	// RollingRetriableFailureEvent indicates that we encountered an unexpected but retriable error
 	RollingRetriableFailureEvent RolloutEvent = "RollingRetriableFailureEvent"
 
+	// AppLocatedEvent indicates that apps are located successfully
+	AppLocatedEvent RolloutEvent = "AppLocatedEvent"
+
 	// RollingModifiedEvent indicates that the rolling target or source has changed
 	RollingModifiedEvent RolloutEvent = "RollingModifiedEvent"
 
+	// RollingDeletedEvent indicates that the rolling is being deleted
+	RollingDeletedEvent RolloutEvent = "RollingDeletedEvent"
+
 	// RollingSpecVerifiedEvent indicates that we have successfully verified that the rollout spec
 	RollingSpecVerifiedEvent RolloutEvent = "RollingSpecVerifiedEvent"
 
@@ -86,6 +92,8 @@ const (
 	RolloutFailing runtimev1alpha1.ConditionType = "RolloutFailing"
 	// RolloutAbandoning means that the rollout is being abandoned.
 	RolloutAbandoning runtimev1alpha1.ConditionType = "RolloutAbandoning"
+	// RolloutDeleting means that the rollout is being deleted.
+	RolloutDeleting runtimev1alpha1.ConditionType = "RolloutDeleting"
 	// RolloutFailed means that the rollout failed.
 	RolloutFailed runtimev1alpha1.ConditionType = "RolloutFailed"
 	// RolloutSucceed means that the rollout is done.
@@ -166,8 +174,8 @@ func (r *RolloutStatus) getRolloutConditionType() runtimev1alpha1.ConditionType
 	case RolloutAbandoningState:
 		return RolloutAbandoning
 
-	case RolloutFailedState:
-		return RolloutFailed
+	case RolloutDeletingState:
+		return RolloutDeleting
 
 	case RolloutSucceedState:
 		return RolloutSucceed
@@ -201,9 +209,9 @@ func (r *RolloutStatus) RolloutFailing(reason string) {
 // ResetStatus resets the status of the rollout to start from beginning
 func (r *RolloutStatus) ResetStatus() {
 	r.NewPodTemplateIdentifier = ""
-	r.RolloutTargetTotalSize = -1
+	r.RolloutTargetSize = -1
 	r.LastAppliedPodTemplateIdentifier = ""
-	r.RollingState = VerifyingSpecState
+	r.RollingState = LocatingTargetAppState
 	r.BatchRollingState = BatchInitializingState
 	r.CurrentBatch = 0
 	r.UpgradedReplicas = 0
@@ -259,9 +267,29 @@ func (r *RolloutStatus) StateTransition(event RolloutEvent) {
 	if event == RollingModifiedEvent {
 		if r.RollingState == RolloutFailedState || r.RollingState == RolloutSucceedState {
 			r.ResetStatus()
-		} else {
+		} else if r.RollingState != RolloutDeletingState {
 			r.SetRolloutCondition(NewNegativeCondition(r.getRolloutConditionType(), "Rollout Spec is modified"))
 			r.RollingState = RolloutAbandoningState
+			r.BatchRollingState = BatchInitializingState
+		}
+		return
+	}
+
+	// special handle deleted event here, it can happen at many states
+	if event == RollingDeletedEvent {
+		if r.RollingState == RolloutFailedState || r.RollingState == RolloutSucceedState {
+			panic(fmt.Errorf(invalidRollingStateTransition, rollingState, event))
+		}
+		r.SetRolloutCondition(NewNegativeCondition(r.getRolloutConditionType(), "Rollout is being deleted"))
+		r.RollingState = RolloutDeletingState
+		r.BatchRollingState = BatchInitializingState
+		return
+	}
+
+	// special handle appLocatedEvent event here, it only applies to one state but it's legal to happen at other states
+	if event == AppLocatedEvent {
+		if r.RollingState == LocatingTargetAppState {
+			r.RollingState = VerifyingSpecState
 		}
 		return
 	}
@@ -296,6 +324,14 @@ func (r *RolloutStatus) StateTransition(event RolloutEvent) {
 		}
 		panic(fmt.Errorf(invalidRollingStateTransition, rollingState, event))
 
+	case RolloutDeletingState:
+		if event == RollingFinalizedEvent {
+			r.SetRolloutCondition(NewPositiveCondition(r.getRolloutConditionType()))
+			r.RollingState = RolloutFailedState
+			return
+		}
+		panic(fmt.Errorf(invalidRollingStateTransition, rollingState, event))
+
 	case FinalisingState:
 		if event == RollingFinalizedEvent {
 			r.SetRolloutCondition(NewPositiveCondition(r.getRolloutConditionType()))
@@ -312,10 +348,7 @@ func (r *RolloutStatus) StateTransition(event RolloutEvent) {
 		}
 		panic(fmt.Errorf(invalidRollingStateTransition, rollingState, event))
 
-	case RolloutSucceedState:
-		panic(fmt.Errorf(invalidRollingStateTransition, rollingState, event))
-
-	case RolloutFailedState:
+	case RolloutSucceedState, RolloutFailedState:
 		panic(fmt.Errorf(invalidRollingStateTransition, rollingState, event))
 
 	default:

apis/standard.oam.dev/v1alpha1/rollouttrait_types.go

@@ -42,6 +42,7 @@ type RolloutTraitSpec struct {
 // RolloutTrait is the Schema for the RolloutTrait API
 // +kubebuilder:object:root=true
 // +genclient
+// +kubebuilder:resource:categories={oam}
 // +kubebuilder:subresource:status
 type RolloutTrait struct {
 	metav1.TypeMeta   `json:",inline"`

apis/types/types.go

@@ -50,8 +50,6 @@ type EnvMeta struct {
 	Email     string `json:"email,omitempty"`
 	Domain    string `json:"domain,omitempty"`
 
-	// Below are not arguments, should be auto-generated
-	Issuer  string `json:"issuer"`
 	Current string `json:"current,omitempty"`
 }
 

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

@@ -14,6 +14,8 @@ spec:
     kind: AppDeployment
     listKind: AppDeploymentList
     plural: appdeployments
+    shortNames:
+    - appdeploy
     singular: appdeployment
   scope: Namespaced
   versions:

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

@@ -9,13 +9,21 @@ metadata:
 spec:
   group: core.oam.dev
   names:
+    categories:
+    - oam
     kind: ApplicationRevision
     listKind: ApplicationRevisionList
     plural: applicationrevisions
+    shortNames:
+    - apprev
     singular: applicationrevision
   scope: Namespaced
   versions:
-  - name: v1alpha2
+  - additionalPrinterColumns:
+    - jsonPath: .metadata.creationTimestamp
+      name: AGE
+      type: date
+    name: v1alpha2
     schema:
       openAPIV3Schema:
         description: ApplicationRevision is the Schema for the ApplicationRevision API
@@ -404,8 +412,12 @@ spec:
                       rollingState:
                         description: RollingState is the Rollout State
                         type: string
+                      rolloutOriginalSize:
+                        description: RolloutTargetSize is the size of the target resources. This is determined once the initial spec verification and does not change until the rollout is restarted
+                        format: int32
+                        type: integer
                       rolloutTargetSize:
-                        description: RolloutTargetTotalSize is the size of the target resources. This is determined once the initial spec verification and does not change until the rollout is restarted
+                        description: RolloutTargetSize is the size of the target resources. This is determined once the initial spec verification and does not change until the rollout is restarted
                         format: int32
                         type: integer
                       services:
@@ -748,6 +760,9 @@ spec:
                           description: Extension is used for extension needs by OAM platform builders
                           type: object
                           x-kubernetes-preserve-unknown-fields: true
+                        podDisruptive:
+                          description: PodDisruptive specifies whether using the trait will cause the pod to restart or not.
+                          type: boolean
                         revisionEnabled:
                           description: Revision indicates whether a trait is aware of component revision
                           type: boolean
@@ -1058,7 +1073,12 @@ spec:
         type: object
     served: true
     storage: false
-  - name: v1beta1
+    subresources: {}
+  - additionalPrinterColumns:
+    - jsonPath: .metadata.creationTimestamp
+      name: AGE
+      type: date
+    name: v1beta1
     schema:
       openAPIV3Schema:
         description: ApplicationRevision is the Schema for the ApplicationRevision API
@@ -1447,8 +1467,12 @@ spec:
                       rollingState:
                         description: RollingState is the Rollout State
                         type: string
+                      rolloutOriginalSize:
+                        description: RolloutTargetSize is the size of the target resources. This is determined once the initial spec verification and does not change until the rollout is restarted
+                        format: int32
+                        type: integer
                       rolloutTargetSize:
-                        description: RolloutTargetTotalSize is the size of the target resources. This is determined once the initial spec verification and does not change until the rollout is restarted
+                        description: RolloutTargetSize is the size of the target resources. This is determined once the initial spec verification and does not change until the rollout is restarted
                         format: int32
                         type: integer
                       services:
@@ -1792,6 +1816,9 @@ spec:
                           description: Extension is used for extension needs by OAM platform builders
                           type: object
                           x-kubernetes-preserve-unknown-fields: true
+                        podDisruptive:
+                          description: PodDisruptive specifies whether using the trait will cause the pod to restart or not.
+                          type: boolean
                         revisionEnabled:
                           description: Revision indicates whether a trait is aware of component revision
                           type: boolean
@@ -2102,6 +2129,7 @@ spec:
         type: object
     served: true
     storage: true
+    subresources: {}
 status:
   acceptedNames:
     kind: ""

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

@@ -25,10 +25,31 @@ spec:
     kind: Application
     listKind: ApplicationList
     plural: applications
+    shortNames:
+    - app
     singular: application
   scope: Namespaced
   versions:
-  - name: v1alpha2
+  - additionalPrinterColumns:
+    - jsonPath: .spec.components[*].name
+      name: COMPONENT
+      type: string
+    - jsonPath: .spec.components[*].type
+      name: TYPE
+      type: string
+    - jsonPath: .status.status
+      name: PHASE
+      type: string
+    - jsonPath: .status.services[*].healthy
+      name: HEALTHY
+      type: boolean
+    - jsonPath: .status.services[*].message
+      name: STATUS
+      type: string
+    - jsonPath: .metadata.creationTimestamp
+      name: AGE
+      type: date
+    name: v1alpha2
     schema:
       openAPIV3Schema:
         description: Application is the Schema for the applications API
@@ -403,8 +424,12 @@ spec:
               rollingState:
                 description: RollingState is the Rollout State
                 type: string
+              rolloutOriginalSize:
+                description: RolloutTargetSize is the size of the target resources. This is determined once the initial spec verification and does not change until the rollout is restarted
+                format: int32
+                type: integer
               rolloutTargetSize:
-                description: RolloutTargetTotalSize is the size of the target resources. This is determined once the initial spec verification and does not change until the rollout is restarted
+                description: RolloutTargetSize is the size of the target resources. This is determined once the initial spec verification and does not change until the rollout is restarted
                 format: int32
                 type: integer
               services:
@@ -463,7 +488,26 @@ spec:
     storage: false
     subresources:
       status: {}
-  - name: v1beta1
+  - additionalPrinterColumns:
+    - jsonPath: .spec.components[*].name
+      name: COMPONENT
+      type: string
+    - jsonPath: .spec.components[*].type
+      name: TYPE
+      type: string
+    - jsonPath: .status.status
+      name: PHASE
+      type: string
+    - jsonPath: .status.services[*].healthy
+      name: HEALTHY
+      type: boolean
+    - jsonPath: .status.services[*].message
+      name: STATUS
+      type: string
+    - jsonPath: .metadata.creationTimestamp
+      name: AGE
+      type: date
+    name: v1beta1
     schema:
       openAPIV3Schema:
         description: Application is the Schema for the applications API
@@ -838,8 +882,12 @@ spec:
               rollingState:
                 description: RollingState is the Rollout State
                 type: string
+              rolloutOriginalSize:
+                description: RolloutTargetSize is the size of the target resources. This is determined once the initial spec verification and does not change until the rollout is restarted
+                format: int32
+                type: integer
               rolloutTargetSize:
-                description: RolloutTargetTotalSize is the size of the target resources. This is determined once the initial spec verification and does not change until the rollout is restarted
+                description: RolloutTargetSize is the size of the target resources. This is determined once the initial spec verification and does not change until the rollout is restarted
                 format: int32
                 type: integer
               services:

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

@@ -14,10 +14,31 @@ spec:
     kind: AppRollout
     listKind: AppRolloutList
     plural: approllouts
+    shortNames:
+    - approllout
     singular: approllout
   scope: Namespaced
   versions:
-  - name: v1alpha2
+  - additionalPrinterColumns:
+    - jsonPath: .status.rolloutStatus.rolloutTargetSize
+      name: TARGET
+      type: string
+    - jsonPath: .status.rolloutStatus.upgradedReplicas
+      name: UPGRADED
+      type: string
+    - jsonPath: .status.rolloutStatus.upgradedReadyReplicas
+      name: READY
+      type: string
+    - jsonPath: .status.rolloutStatus.batchRollingState
+      name: BATCH-STATE
+      type: string
+    - jsonPath: .status.rolloutStatus.rollingState
+      name: ROLLING-STATE
+      type: string
+    - jsonPath: .metadata.creationTimestamp
+      name: AGE
+      type: date
+    name: v1alpha2
     schema:
       openAPIV3Schema:
         description: AppRollout is the Schema for the AppRollout API
@@ -319,8 +340,12 @@ spec:
               rollingState:
                 description: RollingState is the Rollout State
                 type: string
+              rolloutOriginalSize:
+                description: RolloutTargetSize is the size of the target resources. This is determined once the initial spec verification and does not change until the rollout is restarted
+                format: int32
+                type: integer
               rolloutTargetSize:
-                description: RolloutTargetTotalSize is the size of the target resources. This is determined once the initial spec verification and does not change until the rollout is restarted
+                description: RolloutTargetSize is the size of the target resources. This is determined once the initial spec verification and does not change until the rollout is restarted
                 format: int32
                 type: integer
               targetGeneration:
@@ -346,7 +371,26 @@ spec:
     storage: false
     subresources:
       status: {}
-  - name: v1beta1
+  - additionalPrinterColumns:
+    - jsonPath: .status.rolloutTargetSize
+      name: TARGET
+      type: string
+    - jsonPath: .status.upgradedReplicas
+      name: UPGRADED
+      type: string
+    - jsonPath: .status.upgradedReadyReplicas
+      name: READY
+      type: string
+    - jsonPath: .status.batchRollingState
+      name: BATCH-STATE
+      type: string
+    - jsonPath: .status.rollingState
+      name: ROLLING-STATE
+      type: string
+    - jsonPath: .metadata.creationTimestamp
+      name: AGE
+      type: date
+    name: v1beta1
     schema:
       openAPIV3Schema:
         description: AppRollout is the Schema for the AppRollout API
@@ -368,7 +412,7 @@ spec:
                   type: string
                 type: array
               revertOnDelete:
-                description: RevertOnDelete revert the rollout when the rollout CR is deleted It will remove the target app from the kubernetes if it's set to true
+                description: RevertOnDelete revert the failed rollout when the rollout CR is deleted It will revert the change back to the source version at once (not in batches) Default is false
                 type: boolean
               rolloutPlan:
                 description: RolloutPlan is the details on how to rollout the resources
@@ -648,8 +692,12 @@ spec:
               rollingState:
                 description: RollingState is the Rollout State
                 type: string
+              rolloutOriginalSize:
+                description: RolloutTargetSize is the size of the target resources. This is determined once the initial spec verification and does not change until the rollout is restarted
+                format: int32
+                type: integer
               rolloutTargetSize:
-                description: RolloutTargetTotalSize is the size of the target resources. This is determined once the initial spec verification and does not change until the rollout is restarted
+                description: RolloutTargetSize is the size of the target resources. This is determined once the initial spec verification and does not change until the rollout is restarted
                 format: int32
                 type: integer
               targetGeneration:

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

@@ -14,10 +14,22 @@ spec:
     kind: ComponentDefinition
     listKind: ComponentDefinitionList
     plural: componentdefinitions
+    shortNames:
+    - comp
     singular: componentdefinition
   scope: Namespaced
   versions:
-  - name: v1alpha2
+  - additionalPrinterColumns:
+    - jsonPath: .spec.workload.definition.kind
+      name: WORKLOAD-KIND
+      type: string
+    - jsonPath: .metadata.annotations.definition\.oam\.dev/description
+      name: DESCRIPTION
+      type: string
+    - jsonPath: .metadata.creationTimestamp
+      name: AGE
+      type: date
+    name: v1alpha2
     schema:
       openAPIV3Schema:
         description: ComponentDefinition is the Schema for the componentdefinitions API
@@ -206,7 +218,17 @@ spec:
     storage: false
     subresources:
       status: {}
-  - name: v1beta1
+  - additionalPrinterColumns:
+    - jsonPath: .spec.workload.definition.kind
+      name: WORKLOAD-KIND
+      type: string
+    - jsonPath: .metadata.annotations.definition\.oam\.dev/description
+      name: DESCRIPTION
+      type: string
+    - jsonPath: .metadata.creationTimestamp
+      name: AGE
+      type: date
+    name: v1beta1
     schema:
       openAPIV3Schema:
         description: ComponentDefinition is the Schema for the componentdefinitions API

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

@@ -14,6 +14,8 @@ spec:
     kind: ResourceTracker
     listKind: ResourceTrackerList
     plural: resourcetrackers
+    shortNames:
+    - tracker
     singular: resourcetracker
   scope: Cluster
   versions:
@@ -30,9 +32,40 @@ spec:
             type: string
           metadata:
             type: object
+          status:
+            description: ResourceTrackerStatus define the status of resourceTracker
+            properties:
+              trackedResources:
+                items:
+                  description: A TypedReference refers to an object by Name, Kind, and APIVersion. It is commonly used to reference across-namespace objects
+                  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
+                    namespace:
+                      description: Namespace of the objects outside the application namespace.
+                      type: string
+                    uid:
+                      description: UID of the referenced object.
+                      type: string
+                  required:
+                  - apiVersion
+                  - kind
+                  - name
+                  type: object
+                type: array
+            type: object
         type: object
     served: true
     storage: true
+    subresources:
+      status: {}
 status:
   acceptedNames:
     kind: ""

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

@@ -14,6 +14,8 @@ spec:
     kind: ScopeDefinition
     listKind: ScopeDefinitionList
     plural: scopedefinitions
+    shortNames:
+    - scope
     singular: scopedefinition
   scope: Namespaced
   versions:

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

@@ -14,13 +14,21 @@ spec:
     kind: TraitDefinition
     listKind: TraitDefinitionList
     plural: traitdefinitions
+    shortNames:
+    - trait
     singular: traitdefinition
   scope: Namespaced
   versions:
   - additionalPrinterColumns:
-    - jsonPath: .spec.definitionRef.name
-      name: DEFINITION-NAME
+    - jsonPath: .spec.appliesToWorkloads
+      name: APPLIES-TO
       type: string
+    - jsonPath: .metadata.annotations.definition\.oam\.dev/description
+      name: DESCRIPTION
+      type: string
+    - jsonPath: .metadata.creationTimestamp
+      name: AGE
+      type: date
     name: v1alpha2
     schema:
       openAPIV3Schema:
@@ -63,6 +71,9 @@ spec:
                 description: Extension is used for extension needs by OAM platform builders
                 type: object
                 x-kubernetes-preserve-unknown-fields: true
+              podDisruptive:
+                description: PodDisruptive specifies whether using the trait will cause the pod to restart or not.
+                type: boolean
               revisionEnabled:
                 description: Revision indicates whether a trait is aware of component revision
                 type: boolean
@@ -192,9 +203,15 @@ spec:
     subresources:
       status: {}
   - additionalPrinterColumns:
-    - jsonPath: .spec.definitionRef.name
-      name: DEFINITION-NAME
+    - jsonPath: .spec.appliesToWorkloads
+      name: APPLIES-TO
       type: string
+    - jsonPath: .metadata.annotations.definition\.oam\.dev/description
+      name: DESCRIPTION
+      type: string
+    - jsonPath: .metadata.creationTimestamp
+      name: AGE
+      type: date
     name: v1beta1
     schema:
       openAPIV3Schema:
@@ -237,6 +254,9 @@ spec:
                 description: Extension is used for extension needs by OAM platform builders
                 type: object
                 x-kubernetes-preserve-unknown-fields: true
+              podDisruptive:
+                description: PodDisruptive specifies whether using the trait will cause the pod to restart or not.
+                type: boolean
               revisionEnabled:
                 description: Revision indicates whether a trait is aware of component revision
                 type: boolean

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

@@ -14,6 +14,8 @@ spec:
     kind: WorkloadDefinition
     listKind: WorkloadDefinitionList
     plural: workloaddefinitions
+    shortNames:
+    - workload
     singular: workloaddefinition
   scope: Namespaced
   versions:
@@ -21,6 +23,9 @@ spec:
     - jsonPath: .spec.definitionRef.name
       name: DEFINITION-NAME
       type: string
+    - jsonPath: .metadata.creationTimestamp
+      name: AGE
+      type: date
     name: v1alpha2
     schema:
       openAPIV3Schema:
@@ -204,6 +209,12 @@ spec:
     - jsonPath: .spec.definitionRef.name
       name: DEFINITION-NAME
       type: string
+    - jsonPath: .metadata.annotations.definition\.oam\.dev/description
+      name: DESCRIPTION
+      type: string
+    - jsonPath: .metadata.creationTimestamp
+      name: AGE
+      type: date
     name: v1beta1
     schema:
       openAPIV3Schema:

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

@@ -9,6 +9,8 @@ metadata:
 spec:
   group: standard.oam.dev
   names:
+    categories:
+    - oam
     kind: RolloutTrait
     listKind: RolloutTraitList
     plural: rollouttraits
@@ -340,8 +342,12 @@ spec:
               rollingState:
                 description: RollingState is the Rollout State
                 type: string
+              rolloutOriginalSize:
+                description: RolloutTargetSize is the size of the target resources. This is determined once the initial spec verification and does not change until the rollout is restarted
+                format: int32
+                type: integer
               rolloutTargetSize:
-                description: RolloutTargetTotalSize is the size of the target resources. This is determined once the initial spec verification and does not change until the rollout is restarted
+                description: RolloutTargetSize is the size of the target resources. This is determined once the initial spec verification and does not change until the rollout is restarted
                 format: int32
                 type: integer
               targetGeneration:

charts/vela-core/templates/NOTES.txt

@@ -1,21 +1 @@
-1. Get the application URL by running these commands:
-{{- if .Values.ingress.enabled }}
-{{- range $host := .Values.ingress.hosts }}
-  {{- range .paths }}
-  http{{ if $.Values.ingress.tls }}s{{ end }}://{{ $host.host }}{{ . }}
-  {{- end }}
-{{- end }}
-{{- else if contains "NodePort" .Values.service.type }}
-  export NODE_PORT=$(kubectl get --namespace {{ .Release.Namespace }} -o jsonpath="{.spec.ports[0].nodePort}" services {{ include "kubevela.fullname" . }})
-  export NODE_IP=$(kubectl get nodes --namespace {{ .Release.Namespace }} -o jsonpath="{.items[0].status.addresses[0].address}")
-  echo http://$NODE_IP:$NODE_PORT
-{{- else if contains "LoadBalancer" .Values.service.type }}
-     NOTE: It may take a few minutes for the LoadBalancer IP to be available.
-           You can watch the status of by running 'kubectl get --namespace {{ .Release.Namespace }} svc -w {{ include "kubevela.fullname" . }}'
-  export SERVICE_IP=$(kubectl get svc --namespace {{ .Release.Namespace }} {{ include "kubevela.fullname" . }} --template "{{"{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}"}}")
-  echo http://$SERVICE_IP:{{ .Values.service.port }}
-{{- else if contains "ClusterIP" .Values.service.type }}
-  export POD_NAME=$(kubectl get pods --namespace {{ .Release.Namespace }} -l "app.kubernetes.io/name={{ include "kubevela.name" . }},app.kubernetes.io/instance={{ .Release.Name }}" -o jsonpath="{.items[0].metadata.name}")
-  echo "Visit http://127.0.0.1:8080 to use your application"
-  kubectl --namespace {{ .Release.Namespace }} port-forward $POD_NAME 8080:80
-{{- end }}
+Welcome to use the KubeVela! Enjoy your shipping application journey!

charts/vela-core/templates/admission-webhooks/job-patch/clusterrole.yaml

@@ -18,4 +18,11 @@ rules:
     verbs:
       - get
       - update
+  - apiGroups:
+      - apiextensions.k8s.io
+    resources:
+      - customresourcedefinitions
+    verbs:
+      - get
+      - update
 {{- end }}

charts/vela-core/templates/admission-webhooks/job-patch/job-patchWebhook.yaml

@@ -32,6 +32,7 @@ spec:
             - --namespace={{ .Release.Namespace }}
             - --secret-name={{ template "kubevela.fullname" . }}-admission
             - --patch-failure-policy={{ .Values.admissionWebhooks.failurePolicy }}
+            - --crds=applications.core.oam.dev
       restartPolicy: OnFailure
       serviceAccountName: {{ template "kubevela.fullname" . }}-admission
       {{- with .Values.admissionWebhooks.patch.affinity }}

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

@@ -1,5 +1,5 @@
 {{- if .Values.admissionWebhooks.enabled -}}
-apiVersion: admissionregistration.k8s.io/v1beta1
+apiVersion: admissionregistration.k8s.io/v1
 kind: MutatingWebhookConfiguration
 metadata:
   name: {{ template "kubevela.fullname" . }}-admission
@@ -21,6 +21,7 @@ webhooks:
     failurePolicy: Fail
     {{- end }}
     name: mutating.core.oam.dev.v1alpha2.applicationconfigurations
+    sideEffects: None
     rules:
       - apiGroups:
           - core.oam.dev
@@ -47,6 +48,7 @@ webhooks:
     failurePolicy: Fail
     {{- end }}
     name: mutating.core.oam.dev.v1beta1.approllouts
+    sideEffects: None
     rules:
       - apiGroups:
           - core.oam.dev
@@ -73,6 +75,7 @@ webhooks:
     failurePolicy: Fails
     {{- end }}
     name: mutating.core.oam-dev.v1alpha2.components
+    sideEffects: None
     rules:
       - apiGroups:
           - core.oam.dev
@@ -87,28 +90,6 @@ webhooks:
     admissionReviewVersions:
       - v1beta1
     timeoutSeconds: 5
-  - clientConfig:
-      caBundle: Cg==
-      service:
-        name: {{ template "kubevela.name" . }}-webhook
-        namespace: {{ .Release.Namespace }}
-        path: /mutate-standard-oam-dev-v1alpha1-metricstrait
-    {{- if .Values.admissionWebhooks.patch.enabled  }}
-    failurePolicy: Ignore
-    {{- else }}
-    failurePolicy: Fails
-    {{- end }}
-    name: mmetricstrait.kb.io
-    rules:
-      - apiGroups:
-          - standard.oam.dev
-        apiVersions:
-          - v1alpha1
-        operations:
-          - CREATE
-          - UPDATE
-        resources:
-          - metricstraits
   - clientConfig:
       caBundle: Cg==
       service:
@@ -121,6 +102,9 @@ webhooks:
     failurePolicy: Fails
     {{- end }}
     name: mcontainerized.kb.io
+    sideEffects: None
+    admissionReviewVersions:
+    - v1beta1
     rules:
       - apiGroups:
           - standard.oam.dev

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

@@ -1,5 +1,5 @@
 {{- if .Values.admissionWebhooks.enabled -}}
-apiVersion: admissionregistration.k8s.io/v1beta1
+apiVersion: admissionregistration.k8s.io/v1
 kind: ValidatingWebhookConfiguration
 metadata:
   name: {{ template "kubevela.fullname" . }}-admission
@@ -21,6 +21,7 @@ webhooks:
     failurePolicy: {{ .Values.admissionWebhooks.failurePolicy }}
     {{- end }}
     name: validating.core.oam.dev.v1alpha2.applicationconfigurations
+    sideEffects: None
     rules:
       - apiGroups:
           - core.oam.dev
@@ -47,6 +48,7 @@ webhooks:
     failurePolicy: {{ .Values.admissionWebhooks.failurePolicy }}
     {{- end }}
     name: validating.core.oam.dev.v1beta1.approllouts
+    sideEffects: None
     rules:
       - apiGroups:
           - core.oam.dev
@@ -73,6 +75,7 @@ webhooks:
     failurePolicy: {{ .Values.admissionWebhooks.failurePolicy }}
     {{- end }}
     name: validating.core.oam.dev.v1alpha2.components
+    sideEffects: None
     rules:
       - apiGroups:
           - core.oam.dev
@@ -99,6 +102,9 @@ webhooks:
     failurePolicy: {{ .Values.admissionWebhooks.failurePolicy }}
     {{- end }}
     name: validating.core.oam.dev.v1alpha2.traitdefinitions
+    sideEffects: None
+    admissionReviewVersions:
+      - v1beta1
     rules:
       - apiGroups:
           - core.oam.dev
@@ -113,29 +119,6 @@ webhooks:
     admissionReviewVersions:
       - v1beta1
     timeoutSeconds: 5
-  - clientConfig:
-      caBundle: Cg==
-      service:
-        name: {{ template "kubevela.name" . }}-webhook
-        namespace: {{ .Release.Namespace }}
-        path: /validate-standard-oam-dev-v1alpha1-metricstrait
-    {{- if .Values.admissionWebhooks.patch.enabled  }}
-    failurePolicy: Ignore
-    {{- else }}
-    failurePolicy: {{ .Values.admissionWebhooks.failurePolicy }}
-    {{- end }}
-    name: vmetricstrait.kb.io
-    rules:
-      - apiGroups:
-          - standard.oam.dev
-        apiVersions:
-          - v1alpha1
-        operations:
-          - CREATE
-          - UPDATE
-          - DELETE
-        resources:
-          - metricstraits
   - clientConfig:
       caBundle: Cg==
       service:
@@ -144,6 +127,9 @@ webhooks:
         path: /validate-standard-oam-dev-v1alpha1-podspecworkload
     failurePolicy: Fail
     name: vcontainerized.kb.io
+    admissionReviewVersions:
+      - v1beta1
+    sideEffects: None
     rules:
       - apiGroups:
           - standard.oam.dev

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

@@ -21,6 +21,7 @@ spec:
   appliesToWorkloads:
     - webservice
     - worker
+  podDisruptive: false
   schematic:
     cue:
       template: |

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

@@ -13,6 +13,7 @@ spec:
   definitionRef:
     name: manualscalertraits.core.oam.dev
   workloadRefPath: spec.workloadRef
+  podDisruptive: true
   schematic:
     cue:
       template: |

charts/vela-core/templates/ingress.yaml

@@ -1,41 +0,0 @@
-{{- if .Values.ingress.enabled -}}
-{{- $fullName := include "kubevela.fullname" . -}}
-{{- $svcPort := .Values.service.port -}}
-{{- if semverCompare ">=1.14-0" .Capabilities.KubeVersion.GitVersion -}}
-apiVersion: networking.k8s.io/v1beta1
-{{- else -}}
-apiVersion: extensions/v1beta1
-{{- end }}
-kind: Ingress
-metadata:
-  name: {{ $fullName }}
-  labels:
-    {{- include "kubevela.labels" . | nindent 4 }}
-  {{- with .Values.ingress.annotations }}
-  annotations:
-    {{- toYaml . | nindent 4 }}
-  {{- end }}
-spec:
-{{- if .Values.ingress.tls }}
-  tls:
-  {{- range .Values.ingress.tls }}
-    - hosts:
-      {{- range .hosts }}
-        - {{ . | quote }}
-      {{- end }}
-      secretName: {{ .secretName }}
-  {{- end }}
-{{- end }}
-  rules:
-  {{- range .Values.ingress.hosts }}
-    - host: {{ .host | quote }}
-      http:
-        paths:
-        {{- range .paths }}
-          - path: {{ . }}
-            backend:
-              serviceName: {{ $fullName }}
-              servicePort: {{ $svcPort }}
-        {{- end }}
-  {{- end }}
-{{- end }}

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

@@ -120,6 +120,7 @@ spec:
             {{ if ne .Values.disableCaps "" }}
             - "--disable-caps={{ .Values.disableCaps }}"
             {{ end }}
+            - "--system-definition-namespace={{ .Values.systemDefinitionNamespace }}"
           image: {{ .Values.image.repository }}:{{ .Values.image.tag }}
           imagePullPolicy: {{ quote .Values.image.pullPolicy }}
           resources:

charts/vela-core/templates/tests/test-connection.yaml

@@ -1,15 +0,0 @@
-apiVersion: v1
-kind: Pod
-metadata:
-  name: "{{ include "kubevela.fullname" . }}-test-connection"
-  labels:
-    {{- include "kubevela.labels" . | nindent 4 }}
-  annotations:
-    "helm.sh/hook": test-success
-spec:
-  containers:
-    - name: wget
-      image: busybox
-      command: ['wget']
-      args: ['{{ include "kubevela.fullname" . }}:{{ .Values.service.port }}']
-  restartPolicy: Never

charts/vela-core/values.yaml

@@ -38,24 +38,6 @@ securityContext: {}
   # runAsNonRoot: true
   # runAsUser: 1000
 
-service:
-  type: ClusterIP
-  port: 80
-
-ingress:
-  enabled: false
-  annotations: {}
-    # kubernetes.io/ingress.class: nginx
-    # kubernetes.io/tls-acme: "true"
-  hosts:
-    - host: chart-example.local
-      paths: []
-  tls: []
-  #  - secretName: chart-example-tls
-  #    hosts:
-  #      - chart-example.local
-
-
 resources:
   limits:
     cpu: 500m
@@ -88,8 +70,8 @@ admissionWebhooks:
   patch:
     enabled: true
     image:
-      repository: jettech/kube-webhook-certgen
-      tag: v1.5.0
+      repository: wonderflow/kube-webhook-certgen
+      tag: v2.1
       pullPolicy: IfNotPresent
     affinity: {}
     tolerations: []

design/vela-core/route.md

@@ -1,8 +1,8 @@
 # Route Trait Design
 
-The main idea of route trait is to let users have an entrypoint to visit their App.
+The main idea of [route trait](https://github.com/oam-dev/catalog/tree/master/traits/routetrait) is to let users have an entrypoint to visit their App.
 
-In k8s world, if you want to do so, you have to understand K8s [Serivce](https://kubernetes.io/docs/concepts/services-networking/service/)
+In k8s world, if you want to do so, you have to understand K8s [Service](https://kubernetes.io/docs/concepts/services-networking/service/)
 , [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/), [Ingress Controllers](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/).
 It's not easy to get all of these things work well.
 

docs/README.md

@@ -0,0 +1,72 @@
+# Contributing to KubeVela Docs
+
+[Here](https://github.com/oam-dev/kubevela/tree/master/docs) is the source documentation of [Kubevela website](http://kubevela.io/).
+Any files modifid here will trigger the `check-docs` Github action to run and validate the docs could be build successfully into the website.
+Any changes on these files(`docs/en/*`, `resource/*`, `sidebars.js`) will be submitted to the corresponding locations of the repo 
+[kubevela.io](https://github.com/oam-dev/kubevela.io). The Github-Action there will parse the document and publish it to the Kubevela Website automatically.
+
+Please follow our guides below to learn how to write the docs in the right way.
+
+## Add or Update Docs
+
+When you add or modify the docs, these three files(`docs/en/`, `resource/` and `sidebars.js`) should be taken into consideration.
+
+1. `docs/en/`, the main English documentation files are mainly located in this folder. All markdown files need to follow the format,
+   that the title at the beginning should be in the following format:
+   
+    ```markdown
+    ---
+    title: Title Name
+    ---
+
+    ```
+
+   When you want to add a link refer to any `.md` files inside the docs(`docs/en`), you need to use relative path and remove the `.md` suffix.
+   For example, the `en/helm/component.md` has a link refer to `en/platform-engineers/definition-and-templates.md`. Then the format should like:
+   
+    ```markdown
+    [the definition and template concepts](../platform-engineers/definition-and-templates)
+    ```
+   
+2. `resource/`, image files are located in this folder. When you want to use link any image in documentation, 
+   you should put the image resources here and use a relative path like below:
+  
+   ```markdown
+    ![alt](../resources/concepts.png)
+    ```
+
+3. `sidebars.js`, this file contain the navigation information of the KubeVela website.
+    Please read [the official docs of docusaurus](https://docusaurus.io/docs/sidebar) to learn how to write `sidebar.js`.
+    
+    ```js
+       {
+          type: 'category',
+          label: 'Capability References',
+          items: [
+            // Note!: here must be add the path under "docs/en" 
+            'developers/references/README',
+            'developers/references/workload-types/webservice',
+            'developers/references/workload-types/task',
+            ...
+          ],
+        },
+    ```
+
+[comment]: <> (TODO: ADD how to translate into Chinese or other language here.)
+   
+## Local Development
+
+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:
+
+```shell
+make docs-start
+```
+
+## Build in Local
+
+You can build Kubevela website in local to test the correctness of docs, only run the following cmd:
+
+```shell
+make docs-build
+```

docs/docusaurus.config.js

@@ -1,159 +0,0 @@
-/** @type {import('@docusaurus/types').DocusaurusConfig} */
-module.exports = {
-  title: 'KubeVela',
-  tagline: 'Make shipping applications more enjoyable.',
-  url: 'https://kubevela.io',
-  baseUrl: '/',
-  onBrokenLinks: 'throw',
-  onBrokenMarkdownLinks: 'warn',
-  favicon: 'img/favicon.ico',
-  organizationName: 'oam-dev', // Usually your GitHub org/user name.
-  projectName: 'kubevela.io', // Usually your repo name.
-  i18n: {
-    defaultLocale: 'en',
-    locales: ['en', 'zh'],
-    localeConfigs: {
-      en: {
-        label: 'English',
-      },
-      zh: {
-        label: '简体中文',
-      },
-    },
-  },
-  themeConfig: {
-    navbar: {
-      title: 'KubeVela',
-      logo: {
-        alt: 'KubeVela',
-        src: 'img/logo.svg',
-        srcDark: 'img/logoDark.svg',
-      },
-      items: [
-        {
-          type: 'docsVersionDropdown',
-          position: 'right',
-        },
-        {
-          to: 'docs/',
-          activeBasePath: 'docs',
-          label: 'Documentation',
-          position: 'left',
-        },
-        {
-          to: 'blog',
-          label: 'Blog',
-          position: 'left'
-        },
-        {
-          type: 'localeDropdown',
-          position: 'right',
-        },
-        {
-          href: 'https://github.com/oam-dev/kubevela',
-          className: 'header-githab-link',
-          position: 'right',
-        },
-      ],
-    },
-    footer: {
-      links: [
-        {
-          title: 'Documentation',
-          items: [
-            {
-              label: 'Getting Started',
-              to: '/docs/install',
-            },
-            {
-              label: 'Platform Builder Guide',
-              to: '/docs/platform-engineers/overview',
-            },
-            {
-              label: 'Developer Experience Guide',
-              to: '/docs/quick-start-appfile',
-            },
-          ],
-        },
-        {
-          title: 'Community',
-          items: [
-            {
-              label: 'Slack ( #kubevela channel )',
-              href: 'https://slack.cncf.io/'
-            },
-            {
-              label: 'Gitter',
-              href: 'https://gitter.im/oam-dev/community',
-            },
-            {
-              label: 'DingTalk (23310022)',
-              href: '.',
-            }
-          ],
-        },
-        {
-          title: 'More',
-          items: [
-            {
-              label: 'GitHub',
-              href: 'https://github.com/oam-dev/kubevela',
-            },
-            {
-              label: 'Blog',
-              to: 'blog',
-            },
-          ],
-        },
-      ],
-      copyright: `
-        <br />
-        <strong>© KubeVela Authors ${new Date().getFullYear()} | Documentation Distributed under <a herf="https://creativecommons.org/licenses/by/4.0">CC-BY-4.0</a> </strong>
-        <br />
-      `,
-    },
-    prism: {
-      theme: require('prism-react-renderer/themes/dracula'),
-    },
-  },
-  plugins: [
-    [
-      require.resolve("@easyops-cn/docusaurus-search-local"),
-      {
-        hashed: true,
-        language: ["en", "zh"],
-        indexBlog: true,
-      },
-    ],
-  ],
-  presets: [
-    [
-      '@docusaurus/preset-classic',
-      {
-        docs: {
-          sidebarPath: require.resolve('./sidebars.js'),
-          editUrl:
-            'https://github.com/oam-dev/kubevela.io/edit/main/',
-          showLastUpdateAuthor: true,
-          showLastUpdateTime: true,
-          includeCurrentVersion: true,
-          lastVersion: 'current',
-          // versions: {
-          //   current: {
-          //     label: 'master',
-          //     path: '/',
-          //   },
-          // },
-        },
-        blog: {
-          showReadingTime: true,
-          editUrl:
-            'https://github.com/oam-dev/kubevela.io/tree/main/blog',
-        },
-        theme: {
-          customCss: require.resolve('./src/css/custom.css'),
-        },
-      },
-    ],
-  ],
-};

docs/en/README.md

@@ -4,7 +4,7 @@
 
 # KubeVela
 
-KubeVela is the platform engine to create *PaaS-like* experience on Kubernetes, in a scalable approach.
+KubeVela is a modern application engine that adapts to your application's needs, not the other way around.
 
 ## Community
 

docs/en/application.md

@@ -40,152 +40,7 @@ spec:
             image: "fluentd"
 ```
 
-The `type: worker` means the specification of this component (claimed in following `properties` section) will be enforced by a `ComponentDefinition` object named `worker` as below:
-
-```yaml
-apiVersion: core.oam.dev/v1beta1
-kind: ComponentDefinition
-metadata:
-  name: worker
-  annotations:
-    definition.oam.dev/description: "Describes long-running, scalable, containerized services that running at backend. They do NOT have network endpoint to receive external network traffic."
-spec:
-  workload:
-    definition:
-      apiVersion: apps/v1
-      kind: Deployment
-  schematic:
-    cue:
-      template: |
-        output: {
-        	apiVersion: "apps/v1"
-        	kind:       "Deployment"
-        	spec: {
-        		selector: matchLabels: {
-        			"app.oam.dev/component": context.name
-        		}
-        		template: {
-        			metadata: labels: {
-        				"app.oam.dev/component": context.name
-        			}
-        			spec: {
-        				containers: [{
-        					name:  context.name
-        					image: parameter.image
-
-        					if parameter["cmd"] != _|_ {
-        						command: parameter.cmd
-        					}
-        				}]
-        			}
-        		}
-        	}
-        }
-        parameter: {
-        	image: string
-        	cmd?: [...string]
-        }
-```
-
-
-Hence, the `properties` section of `backend` only supports two parameters: `image` and `cmd`, this is enforced by the `parameter` list of the `.spec.template` field of the definition.
-
-The similar extensible abstraction mechanism also applies to traits.
-For example, `type: autoscaler` in `frontend` means its trait specification (i.e. `properties` section)
-will be enforced by a `TraitDefinition` object named `autoscaler` as below:
-
-```yaml
-apiVersion: core.oam.dev/v1beta1
-kind: TraitDefinition
-metadata:
-  annotations:
-    definition.oam.dev/description: "configure k8s HPA for Deployment"
-  name: hpa
-spec:
-  appliesToWorkloads:
-    - webservice
-    - worker
-  schematic:
-    cue:
-      template: |
-        outputs: hpa: {
-        	apiVersion: "autoscaling/v2beta2"
-        	kind:       "HorizontalPodAutoscaler"
-        	metadata: name: context.name
-        	spec: {
-        		scaleTargetRef: {
-        			apiVersion: "apps/v1"
-        			kind:       "Deployment"
-        			name:       context.name
-        		}
-        		minReplicas: parameter.min
-        		maxReplicas: parameter.max
-        		metrics: [{
-        			type: "Resource"
-        			resource: {
-        				name: "cpu"
-        				target: {
-        					type:               "Utilization"
-        					averageUtilization: parameter.cpuUtil
-        				}
-        			}
-        		}]
-        	}
-        }
-        parameter: {
-        	min:     *1 | int
-        	max:     *10 | int
-        	cpuUtil: *50 | int
-        }
-```
-
-The application also have a `sidecar` trait.
-
-```yaml
-apiVersion: core.oam.dev/v1beta1
-kind: TraitDefinition
-metadata:
-  annotations:
-    definition.oam.dev/description: "add sidecar to the app"
-  name: sidecar
-spec:
-  appliesToWorkloads:
-    - webservice
-    - worker
-  schematic:
-    cue:
-      template: |-
-        patch: {
-           // +patchKey=name
-           spec: template: spec: containers: [parameter]
-        }
-        parameter: {
-           name: string
-           image: string
-           command?: [...string]
-        }
-```
-
-All the definition objects are expected to be defined and installed by platform team.
-The end users will only focus on `Application` resource.
-
-## Conventions and "Standard Contract"
-
-After the `Application` resource is applied to Kubernetes cluster,
-the KubeVela runtime will generate and manage the underlying resources instances following below "standard contract" and conventions.
-
-
-| Label  | Description |
-| :--: | :---------: | 
-|`workload.oam.dev/type=<component definition name>` | The name of its corresponding `ComponentDefinition` |
-|`trait.oam.dev/type=<trait definition name>` | The name of its corresponding `TraitDefinition` | 
-|`app.oam.dev/name=<app name>` | The name of the application it belongs to |
-|`app.oam.dev/component=<component name>` | The name of the component it belongs to |
-|`trait.oam.dev/resource=<name of trait resource instance>` | The name of trait resource instance |
-|`app.oam.dev/appRevision=<name of app revision>` | The name of the application revision it belongs to |
-
-
-## Run Application
+### Deploy the Application
 
 Apply application yaml above, then you'll get the application started
 
@@ -232,3 +87,151 @@ $ kubectl get HorizontalPodAutoscaler frontend
 NAME       REFERENCE             TARGETS         MINPODS   MAXPODS   REPLICAS   AGE
 frontend   Deployment/frontend   <unknown>/50%   1         10        1          101m
 ```
+
+
+## Under the Hood
+
+In above sample, the `type: worker` means the specification of this component (claimed in following `properties` section) will be enforced by a `ComponentDefinition` object named `worker` as below:
+
+```yaml
+apiVersion: core.oam.dev/v1beta1
+kind: ComponentDefinition
+metadata:
+  name: worker
+  annotations:
+    definition.oam.dev/description: "Describes long-running, scalable, containerized services that running at backend. They do NOT have network endpoint to receive external network traffic."
+spec:
+  workload:
+    definition:
+      apiVersion: apps/v1
+      kind: Deployment
+  schematic:
+    cue:
+      template: |
+        output: {
+          apiVersion: "apps/v1"
+          kind:       "Deployment"
+          spec: {
+            selector: matchLabels: {
+              "app.oam.dev/component": context.name
+            }
+            template: {
+              metadata: labels: {
+                "app.oam.dev/component": context.name
+              }
+              spec: {
+                containers: [{
+                  name:  context.name
+                  image: parameter.image
+
+                  if parameter["cmd"] != _|_ {
+                    command: parameter.cmd
+                  }
+                }]
+              }
+            }
+          }
+        }
+        parameter: {
+          image: string
+          cmd?: [...string]
+        }
+```
+
+
+Hence, the `properties` section of `backend` only supports two parameters: `image` and `cmd`, this is enforced by the `parameter` list of the `.spec.template` field of the definition.
+
+The similar extensible abstraction mechanism also applies to traits.
+For example, `type: autoscaler` in `frontend` means its trait specification (i.e. `properties` section)
+will be enforced by a `TraitDefinition` object named `autoscaler` as below:
+
+```yaml
+apiVersion: core.oam.dev/v1beta1
+kind: TraitDefinition
+metadata:
+  annotations:
+    definition.oam.dev/description: "configure k8s HPA for Deployment"
+  name: hpa
+spec:
+  appliesToWorkloads:
+    - webservice
+    - worker
+  schematic:
+    cue:
+      template: |
+        outputs: hpa: {
+          apiVersion: "autoscaling/v2beta2"
+          kind:       "HorizontalPodAutoscaler"
+          metadata: name: context.name
+          spec: {
+            scaleTargetRef: {
+              apiVersion: "apps/v1"
+              kind:       "Deployment"
+              name:       context.name
+            }
+            minReplicas: parameter.min
+            maxReplicas: parameter.max
+            metrics: [{
+              type: "Resource"
+              resource: {
+                name: "cpu"
+                target: {
+                  type:               "Utilization"
+                  averageUtilization: parameter.cpuUtil
+                }
+              }
+            }]
+          }
+        }
+        parameter: {
+          min:     *1 | int
+          max:     *10 | int
+          cpuUtil: *50 | int
+        }
+```
+
+The application also have a `sidecar` trait.
+
+```yaml
+apiVersion: core.oam.dev/v1beta1
+kind: TraitDefinition
+metadata:
+  annotations:
+    definition.oam.dev/description: "add sidecar to the app"
+  name: sidecar
+spec:
+  appliesToWorkloads:
+    - webservice
+    - worker
+  schematic:
+    cue:
+      template: |-
+        patch: {
+           // +patchKey=name
+           spec: template: spec: containers: [parameter]
+        }
+        parameter: {
+           name: string
+           image: string
+           command?: [...string]
+        }
+```
+
+All the definition objects are expected to be declared and installed by platform team and end users will only focus on `Application` resource.
+
+Please note that the end users of KubeVela do NOT need to know about definition objects, they learn how to use a given capability with visualized forms (or the JSON schema of parameters if they prefer). Please check the [Generate Forms from Definitions](/docs/platform-engineers/openapi-v3-json-schema) section about how this is achieved.
+
+### Conventions and "Standard Contract"
+
+After the `Application` resource is applied to Kubernetes cluster,
+the KubeVela runtime will generate and manage the underlying resources instances following below "standard contract" and conventions.
+
+
+| Label  | Description |
+| :--: | :---------: | 
+|`workload.oam.dev/type=<component definition name>` | The name of its corresponding `ComponentDefinition` |
+|`trait.oam.dev/type=<trait definition name>` | The name of its corresponding `TraitDefinition` | 
+|`app.oam.dev/name=<app name>` | The name of the application it belongs to |
+|`app.oam.dev/component=<component name>` | The name of the component it belongs to |
+|`trait.oam.dev/resource=<name of trait resource instance>` | The name of trait resource instance |
+|`app.oam.dev/appRevision=<name of app revision>` | The name of the application revision it belongs to |

docs/en/concepts.md

@@ -22,14 +22,12 @@ This template based workflow make it possible for platform team enforce best pra
 
 ![alt](../resources/what-is-kubevela.png)
 
-Below are the core building blocks in KubeVela that make this happen.
+Below are the core concepts in KubeVela that make this happen.
 
 ## `Application`
-The *Application* is the core API of KubeVela. It allows developers to work with a single artifact to capture the complete application definition with simplified primitives.
+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.
 
-### Why Choose `Application` as the Main Abstraction
-
-Having an "application" concept is important to any developer-centric platform to simplify administrative tasks and can serve as an anchor to avoid configuration drifts during operation. Also, as an abstraction object, `Application` provides a much simpler path for on-boarding Kubernetes capabilities 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.
+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 application delivery process 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
 
@@ -66,15 +64,15 @@ spec:
 
 ## Building the Abstraction
 
-Unlike most of the higher level platforms, the `Application` abstraction in KubeVela is fully extensible and does not even have fixed schema. Instead, it is composed by building blocks (app components and traits etc.) that allow you to onboard platform capabilities to this application definition with your own abstractions.
+Unlike most of the higher level abstractions, the `Application` resource in KubeVela is a LEGO-style object and does not even have fixed schema. Instead, it is composed by building blocks (app components and traits etc.) that allow you to on-board platform capabilities to this application definition via your own abstractions.
 
 The building blocks to abstraction and model platform capabilities named `ComponentDefinition` and `TraitDefinition`.
 
 ### ComponentDefinition
 
-You can think of `ComponentDefinition` as a *template* for workload type. It contains template, parametering and workload characteristic information as a declarative API resource. 
+`ComponentDefinition` is a pre-defined *template* for the deployable workload. It contains template, parametering and workload characteristic information as a declarative API resource. 
 
-Hence, the `Application` abstraction essentially declares how users want to **instantiate** given component definitions. Specifically, the `.type` field references the name of installed `ComponentDefinition` and `.properties` are the user set values to instantiate it. 
+Hence, the `Application` abstraction essentially declares how the user want to **instantiate** given component definitions in target cluster. Specifically, the `.type` field references the name of installed `ComponentDefinition` and `.properties` are the user set values to instantiate it. 
 
 Some typical component definitions are *Long Running Web Service*, *One-time Off Task* or *Redis Database*. All component definitions expected to be pre-installed in the platform, or provided by component providers such as 3rd-party software vendors.
 
@@ -82,7 +80,7 @@ Some typical component definitions are *Long Running Web Service*, *One-time Off
 
 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.
 
-You can think of traits as operational features provided by the platform. To attach a trait to component instance, the user will use `.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.
+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 *"capability definitions"* in KubeVela. 
 
@@ -103,4 +101,4 @@ The overall architecture of KubeVela is shown as below:
 
 ![alt](../resources/arch.png)
 
-Specifically, the application controller is responsible for application abstraction and encapsulation (i.e. the controller for `Application` and `Definition`). The rollout controller will handle progressive rollout strategy with the whole application as a unit. The multi-env deployment engine (*currently WIP*) is responsible for deploying the application across multiple clusters and environments. 
+Specifically, the application controller is responsible for application abstraction and encapsulation (i.e. the controller for `Application` and `Definition`). The rollout controller will handle progressive rollout strategy with the whole application as a unit. The multi-cluster deployment engine is responsible for deploying the application across multiple clusters and environments with traffic shifting and rollout features supported. 

docs/en/cue/basic.md

@@ -22,7 +22,7 @@ The reasons for KubeVela supports CUE as a first-class solution to design abstra
 
 Please make sure below CLIs are present in your environment:
 * [`cue` >=v0.2.2](https://cuelang.org/docs/install/)
-* [`vela` (>v1.0.0)](https://kubevela.io/#/en/install?id=_3-optional-get-kubevela-cli)
+* [`vela` (>v1.0.0)](../install#4-optional-get-kubevela-cli)
 
 ## CUE CLI Basic
 

docs/en/cue/cross-namespace-resource.md

@@ -50,7 +50,4 @@ spec:
         			}}}
         }
 ```
-## Limitations
-If you update definition by changing the `metadata.namespace` field. KubeVela will create new resources in the new namespace but not delete old resources.
-We wil fix the limitation in the near future.
 

docs/en/cue/patch-trait.md

@@ -21,6 +21,7 @@ spec:
   appliesToWorkloads:
     - webservice
     - worker
+  podDisruptive: true
   schematic:
     cue:
       template: |
@@ -54,7 +55,12 @@ spec:
         }
 ```
 
-The patch trait above assumes the target component instance have `spec.template.spec.affinity` field. Hence we need to use `appliesToWorkloads` to enforce the trait only applies to those workload types have this field.
+The patch trait above assumes the target component instance have `spec.template.spec.affinity` field.
+Hence, we need to use `appliesToWorkloads` to enforce the trait only applies to those workload types have this field.
+
+Another important field is `podDisruptive`, this patch trait will patch to the pod template field,
+so changes on any field of this trait will cause the pod to restart, We should add `podDisruptive` and make it to be true
+to tell users that applying this trait will cause the pod to restart.
 
 
 Now the users could declare they want to add node affinity rules to the component instance as below:
@@ -112,6 +118,7 @@ spec:
   appliesToWorkloads:
     - webservice
     - worker
+  podDisruptive: true
   schematic:
     cue:
       template: |
@@ -141,6 +148,7 @@ spec:
   appliesToWorkloads:
     - webservice
     - worker
+  podDisruptive: true
   schematic:
     cue:
       template: |
@@ -185,6 +193,7 @@ spec:
   appliesToWorkloads:
     - webservice
     - worker
+  podDisruptive: true
   schematic:
     cue:
       template: |
@@ -235,6 +244,7 @@ spec:
   appliesToWorkloads:
     - webservice
     - worker
+  podDisruptive: false
   schematic:
     cue:
       template: |
@@ -258,7 +268,7 @@ spec:
 
 Inject system environments into Pod is also very common use case.
 
-> This case rely on strategy merge patch, so don't forget add `+patchKey=name` as below:
+> This case relies on strategy merge patch, so don't forget add `+patchKey=name` as below:
 
 ```yaml
 apiVersion: core.oam.dev/v1beta1
@@ -271,6 +281,7 @@ spec:
   appliesToWorkloads:
     - webservice
     - worker
+  podDisruptive: true
   schematic:
     cue:
       template: |
@@ -312,6 +323,7 @@ spec:
   appliesToWorkloads:
     - webservice
     - worker
+  podDisruptive: true
   schematic:
     cue:
       template: |
@@ -358,6 +370,7 @@ spec:
   appliesToWorkloads:
     - webservice
     - worker
+  podDisruptive: true
   schematic:
     cue:
       template: |

docs/en/cue/trait.md

@@ -68,6 +68,7 @@ kind: TraitDefinition
 metadata:
   name: ingress
 spec:
+  podDisruptive: false
   schematic:
     cue:
       template: |

docs/en/developers/config-enviroments.md

@@ -2,7 +2,8 @@
 title:  Setting Up Deployment Environment
 ---
 
-A deployment environment is where you could configure the workspace, email for certificate issuer and domain for your applications globally. A typical set of deployment environment is `test`, `staging`, `prod`, etc.
+A deployment environment is where you could configure the workspace, email for contact and domain for your applications globally.
+A typical set of deployment environment is `test`, `staging`, `prod`, etc.
 
 ## Create environment
 

docs/en/install.mdx

@@ -5,7 +5,7 @@ title:  Installation
 import Tabs from '@theme/Tabs';
 import TabItem from '@theme/TabItem';
 
-If you have installed the kubevale chart before, please read the [Upgrade](#7-optional-upgrade) step directly.
+If you have installed the kubevale chart before, please read the [Upgrade](#upgrade) step directly.
 
 ## 1. Setup Kubernetes cluster
 
@@ -118,16 +118,13 @@ These steps will install KubeVela controller and its dependency.
     helm install --create-namespace -n vela-system kubevela kubevela/vela-core --version <next_version>-rc-master
     ```
     ```console
-   NAME: kubevela
-   LAST DEPLOYED: Sat Mar  6 21:03:11 2021
-   NAMESPACE: vela-system
-   STATUS: deployed
-   REVISION: 1
-   NOTES:
-   1. Get the application URL by running these commands:
-     export POD_NAME=$(kubectl get pods --namespace vela-system -l "app.kubernetes.io/name=vela-core,app.kubernetes.io/instance=kubevela" -o jsonpath="{.items[0].metadata.name}")
-     echo "Visit http://127.0.0.1:8080 to use your application"
-     kubectl --namespace vela-system port-forward $POD_NAME 8080:80
+    NAME: kubevela
+    LAST DEPLOYED: Thu Apr  1 19:41:30 2021
+    NAMESPACE: vela-system
+    STATUS: deployed
+    REVISION: 1
+    NOTES:
+    Welcome to use the KubeVela! Enjoy your shipping application journey!
    ```
 
 4. Install Kubevela with cert-manager (optional)
@@ -184,7 +181,7 @@ Here are three ways to get KubeVela Cli:
 ** macOS/Linux **
 
 ```shell script
-curl -fsSl https://kubevela.io/install.sh | bash
+curl -fsSl https://kubevela.io/script/install.sh | bash
 ```
 
 **Windows**
@@ -196,6 +193,13 @@ powershell -Command "iwr -useb https://kubevela.io/script/install.ps1 | iex"
 <TabItem value="homebrew">
 
 **macOS/Linux**
+
+Update your brew firstly.
+```shell script
+brew update
+```
+Then install kubevela client.
+
 ```shell script
 brew install kubevela
 ```
@@ -276,7 +280,19 @@ Then clean up CRDs (CRDs are not removed via helm by default):
 
 If you have already installed KubeVela and wants to upgrade to the new version, you could follow below instructions.
 
-## Step 1. Upgrade KubeVela CRDs
+## Step 1. Update helm repo
+
+```shell
+helm repo update
+```
+
+you can get the new version kubevela chart by run:
+
+```shell
+helm search repo kubevela/vela-core -l
+```
+
+## Step 2. Upgrade KubeVela CRDs
 
 ```shell
 kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/master/charts/vela-core/crds/core.oam.dev_componentdefinitions.yaml
@@ -290,8 +306,18 @@ kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/master/chart
 kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/master/charts/vela-core/crds/core.oam.dev_applicationcontexts.yaml
 ```
 
-## Step 2. Upgrade KubeVela helm chart
+> Tips: If you meet errors like `* is invalid: spec.scope: Invalid value: "Namespaced": filed is immutable`. Please delete the crd with the error.
+and re-apply the kubevela crds.
 
+```shell
+ kubectl delete crd \
+  scopedefinitions.core.oam.dev \
+  traitdefinitions.core.oam.dev \
+  workloaddefinitions.core.oam.dev
 ```
+
+## Step 3. Upgrade KubeVela helm chart
+
+```shell
 helm upgrade --install --create-namespace --namespace vela-system  kubevela kubevela/vela-core --version <the_new_version>
 ```

docs/en/introduction.md

@@ -20,50 +20,50 @@ In the end, developers complain those platforms are too rigid and slow in respon
 
 ## What is KubeVela?
 
-For platform builders, KubeVela serves as a framework that empowers them to create user friendly yet highly extensible platforms at ease. In details, KubeVela relieves the pains of building such platforms by doing the following:
+For platform builders, KubeVela serves as a framework that relieves the pains of building developer focused platforms by doing the following:
 
-- Application Centric. KubeVela enforces an *Application* abstraction as its main API and **ALL** KubeVela's capabilities serve for the applications' needs only. This is achieved by adopting the [Open Application Model](https://github.com/oam-dev/spec) as the core API for KubeVela.
+- Developer Centric. KubeVela abstracts away the infrastructure level primitives by introducing the *Application* concept to capture a full deployment of microservices, and then building operational features around the applications' needs only.
  
-- Extending Natively. The *Application* abstraction is composed of modularized building blocks named *components* and *traits*. Any capability provided by Kubernetes ecosystem can be added to KubeVela as new component or trait through simple `kubectl apply -f`.
+- Extending Natively. The *Application* is composed of modularized building blocks that support [CUELang](https://github.com/cuelang/cue) and [Helm](https://helm.sh) as template engines. This enable you to abstract Kubernetes capabilities in LEGO-style and ship them to end users via plain `kubectl apply -f`. Changes made to the abstraction templates take effect at runtime, neither recompilation nor redeployment of KubeVela is required.
 
-- Simple yet Extensible Abstraction Mechanism. The *Application* abstraction is implemented with server-side encapsulation controller (supports [CUELang](https://github.com/cuelang/cue) and [Helm](https://helm.sh) as templating engine) to abstract user-facing primitives from Kubernetes API resources. Changes to existing capability templates (or new templates added) take effect at runtime, neither recompilation nor redeployment of KubeVela is required.
+- Simple yet Reliable Abstraction Mechanism. Unlike most IaC (Infrastructure-as-Code) solutions, the abstractions in KubeVela is built with [Kubernetes Control Loop](https://kubernetes.io/docs/concepts/architecture/controller/) so they will never leave *Configuration Drift* in your cluster. As a [Kubernetes Custom Resource](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/), KubeVela works with any CI/CD or GitOps tools seamlessly, no integration effort needed.
 
-With KubeVela, platform builders now finally have the tooling support to design and ship any new capabilities to their end-users with high confidence and low turn around time. 
+With KubeVela, the platform builders finally have the tooling supports to design easy-to-use abstractions and ship them to end-users with high confidence and low turn around time. 
 
-For developers, such *Application* abstraction built with KubeVela will enable them to design and ship their applications to Kubernetes with minimal effort. Instead of managing a handful infrastructure details, a simple application definition that can be easily integrated with any CI/CD pipeline is all they need.
+For end-users (e.g. app developers), such abstractions built with KubeVela will enable them to design and ship applications to Kubernetes with minimal effort - instead of managing a handful infrastructure details, a simple application definition that can be easily integrated with any CI/CD pipeline is all they need.
 
 ## Comparisons
 
-### Platform-as-a-Service (PaaS) 
+### KubeVela vs. Platform-as-a-Service (PaaS) 
 
-The typical examples are Heroku and Cloud Foundry. They provides full application management capabilities and aim to improve developer experience and efficiency. In this context, KubeVela can provide similar experience but its built-in features are much lighter and easier to maintain compared to most of the existing PaaS offerings. KubeVela core components are nothing but a set of Kubernetes controllers/plugins.
+The typical examples are Heroku and Cloud Foundry. They provide full application management capabilities and aim to improve developer experience and efficiency. In this context, KubeVela can provide similar experience.
 
-Though the biggest difference lies KubeVela positions itself as the engine to build "PaaS-like" systems, not a PaaS offering.
+Though the biggest difference lies in **flexibility**.
 
-KubeVela is designed as a core engine whose primary goal is to enable platform team to create "PaaS-like" experience by simply registering Kubernetes API resources and defining templates. Comparing to this experience, most existing PaaS systems are either inextensible or have their own addon systems. Hence it's common for them to enforce constraints in the type of supported applications and the supported capabilities which will not happen in KubeVela based experience. 
+KubeVela is a Kubernetes plug-in that enabling you to serve end users with simplicity by defining your own abstractions, and this is achieved by templating Kubernetes API resources as application-centric abstractions in your cluster. Comparing to this mechanism, most existing PaaS systems are highly restricted and inflexible, i.e. they have to enforce constraints in the type of supported applications and capabilities, and as application needs grows, they always outgrow the capabilities of a PaaS system - this will never happen in KubeVela. 
 
-### Serverless platforms  
+### KubeVela vs. Serverless  
 
 Serverless platform such as AWS Lambda provides extraordinary user experience and agility to deploy serverless applications. However, those platforms impose even more constraints in extensibility. They are arguably "hard-coded" PaaS.
 
-Kubernetes based serverless platforms such as Knative, OpenFaaS can be easily integrated with KubeVela by registering themselves as new workload types and traits. Even for AWS Lambda, there is an success story to integrate it with KubeVela by the tools developed by Crossplane.
+Kubernetes based serverless platforms such as Knative, OpenFaaS can be easily integrated with KubeVela by registering themselves as new workload types and traits. Even for AWS Lambda, there is a success story to integrate it with KubeVela by the tools developed by Crossplane.
 
-### Platform agnostic developer tools
+### KubeVela vs. Platform agnostic developer tools
 
 The typical example is Hashicorp's Waypoint. Waypoint is a developer facing tool which introduces a consistent workflow (i.e., build, deploy, release) to ship applications on top of different platforms.
 
-KubeVela can be integrated into Waypoint like any other supported platforms. In this case, developers will use the Waypoint workflow to manage applications, and all the capabilities of KubeVela including abstractions will still be available in this integration.
+KubeVela can be integrated into Waypoint as a supported platform. In this case, developers could use the Waypoint workflow to manage applications with leverage of abstractions (e.g. application, rollout, ingress, autoscaling etc) you built via KubeVela.
 
-### Helm, etc. 
+### KubeVela vs. Helm 
 
-Helm is a package manager for Kubernetes that provides package, install, and upgrade a set of YAML files for Kubernetes as a unit. KubeVela leverages Helm heavily to package the capability dependencies and Helm controller is one of the core components behind *Application* abstraction.
+Helm is a package manager for Kubernetes that provides package, install, and upgrade a set of YAML files for Kubernetes as a unit. KubeVela leverages Helm heavily to package the capability dependencies and Helm is also one of the core templating engines behind *Application* abstraction.
 
 Though KubeVela itself is not a package manager, it's a core engine for platform builders to create upper layer platforms in easy and repeatable approach.
 
-### Kubernetes
+### KubeVela vs. Kubernetes
 
-KubeVela is a Kubernetes plugin for building upper layer platforms. It leverages the native Kubernetes extensibility and capabilities to resolve a hard problem - making shipping applications enjoyable on Kubernetes.
+KubeVela is a Kubernetes plugin for building higher level abstractions. It leverages [Open Application Model](https://github.com/oam-dev/spec) and the native Kubernetes extensibility to resolve a hard problem - making shipping applications enjoyable on Kubernetes.
 
 ## Getting Started
 
-[Install KubeVela](./install) into any Kubernetes cluster to get started.
+Now let's [get started](./quick-start.md) with KubeVela!

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

@@ -93,7 +93,7 @@ spec:
         		}
         		writeConnectionSecretToRef: {
         			namespace: context.namespace
-        			name:      context.outputSecretName
+        			name:      parameter.secretName
         		}
         		providerConfigRef: {
         			name: "default"
@@ -102,15 +102,14 @@ spec:
         	}
         }
         parameter: {
-        	engine:          *"mysql" | string
-        	engineVersion:   *"8.0" | string
-        	instanceClass:   *"rds.mysql.c1.large" | string
-        	username:        string
+        	engine:        *"mysql" | string
+        	engineVersion: *"8.0" | string
+        	instanceClass: *"rds.mysql.c1.large" | string
+        	username:      string
+        	secretName:    string
         }
-```
 
-Noted: In application, application developers need to use property `outputSecretName` as the secret name which is used to store all connection
-items of cloud resource connections information.
+```
 
 ### Step 2: Prepare TraitDefinition `service-binding` to do env-secret mapping
 
@@ -222,7 +221,7 @@ spec:
         engineVersion: "8.0"
         instanceClass: rds.mysql.c1.large
         username: oamtest
-        outputSecretName: db-conn
+        secretName: db-conn
 
 ```
 
@@ -273,7 +272,7 @@ spec:
         		dataRedundancyType: parameter.dataRedundancyType
         		writeConnectionSecretToRef: {
         			namespace: context.namespace
-        			name:      context.outputSecretName
+        			name:      parameter.secretName
         		}
         		providerConfigRef: {
         			name: "default"
@@ -286,8 +285,8 @@ spec:
         	acl:                *"private" | string
         	storageClass:       *"Standard" | string
         	dataRedundancyType: *"LRS" | string
+        	secretName:         string
         }
-
 ```
 
 Update the application to also consume cloud resource OSS.
@@ -329,13 +328,13 @@ spec:
         engineVersion: "8.0"
         instanceClass: rds.mysql.c1.large
         username: oamtest
-        outputSecretName: db-conn
+        secretName: db-conn
 
     - name: sample-oss
       type: alibaba-oss
       properties:
         name: velaweb
-        outputSecretName: oss-conn
+        secretName: oss-conn
 ```
 
 Apply it and verify the application.
@@ -376,7 +375,7 @@ spec:
         engineVersion: "8.0"
         instanceClass: rds.mysql.c1.large
         username: oamtest
-        outputSecretName: db-conn
+        secretName: db-conn
 ```
 
 Apply the application to Kubernetes and a RDS instance will be automatically provisioned (may take some time, ~2 mins).

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

@@ -8,7 +8,7 @@ With flexibility in defining abstractions, it's important to be able to debug, t
 
 Please make sure below CLIs are present in your environment:
 * [`cue` >=v0.2.2](https://cuelang.org/docs/install/)
-* [`vela` (>v1.0.0)](https://kubevela.io/#/en/install?id=_3-optional-get-kubevela-cli)
+* [`vela` (>v1.0.0)](../install#4-optional-get-kubevela-cli)
 
 
 ## Define Definition and Template
@@ -263,113 +263,147 @@ spec:
   type: ClusterIP
 ```
 
+### Test CUE Template with `Kube` package
 
-## Dry-Run the `Application`
+KubeVela automatically generates internal CUE packages for all built-in Kubernetes API resources including CRDs.
+You can import them in CUE template to simplify your templates and help you do the validation.
 
-When CUE template is good, we can use `vela system dry-run` to dry run and check the rendered resources in real Kubernetes cluster. This command will exactly execute the same render logic in KubeVela's `Application` Controller adn output the result for you.
+There are two kinds of ways to import internal `kube` packages.
 
-First, we need use `mergedef.sh` to merge the definition and cue files.
+1. Import them with fixed style: `kube/<apiVersion>` and using it by `Kind`.
+    ```cue
+    import (
+     apps "kube/apps/v1"
+     corev1 "kube/v1"
+    )
+    // output is validated by Deployment.
+    output: apps.#Deployment
+    outputs: service: corev1.#Service
+   ```
+   This way is very easy to remember and use because it aligns with the K8s Object usage, only need to add a prefix `kube/` before `apiVersion`.
+   While this way only supported in KubeVela, so you can only debug and test it with [`vela system dry-run`](#dry-run-the-application).
+   
+2. Import them with third-party packages style. You can run `vela system cue-packages` to list all build-in `kube` packages
+   to know the `third-party packages` supported currently.
+    ```shell
+    $ vela system cue-packages
+    DEFINITION-NAME                	IMPORT-PATH                         	 USAGE
+    #Deployment                    	k8s.io/apps/v1                      	Kube Object for apps/v1.Deployment
+    #Service                       	k8s.io/core/v1                      	Kube Object for v1.Service
+    #Secret                        	k8s.io/core/v1                      	Kube Object for v1.Secret
+    #Node                          	k8s.io/core/v1                      	Kube Object for v1.Node
+    #PersistentVolume              	k8s.io/core/v1                      	Kube Object for v1.PersistentVolume
+    #Endpoints                     	k8s.io/core/v1                      	Kube Object for v1.Endpoints
+    #Pod                           	k8s.io/core/v1                      	Kube Object for v1.Pod
+    ```
+   In fact, they are all built-in packages, but you can import them with the `import-path` like the `third-party packages`.
+   In this way, you could debug with `cue` cli client.
+   
+
+#### A workflow to debug with `kube` packages
+
+Here's a workflow that you can debug and test the CUE template with `cue` CLI and use **exactly the same CUE template** in KubeVela.
+
+1. Create a test directory, Init CUE modules.
 
 ```shell
-$ mergedef.sh def.yaml def.cue > componentdef.yaml
+mkdir cue-debug && cd cue-debug/
+cue mod init oam.dev
+go mod init oam.dev
+touch def.cue
 ```
 
-Then, let's create an Application named `test-app.yaml`.
+2. Download the `third-party packages` by using `cue` CLI.
 
-```yaml
-apiVersion: core.oam.dev/v1beta1
-kind: Application
-metadata:
-  name: boutique
-  namespace: default
-spec:
-  components:
-    - name: frontend
-      type: microservice
-      properties:
-        image: registry.cn-hangzhou.aliyuncs.com/vela-samples/frontend:v0.2.2
-        servicePort: 80
-        containerPort: 8080
-        env:
-          PORT: "8080"
-        cpu: "100m"
-        memory: "64Mi"
-```
+In KubeVela, we don't need to download these packages as they're automatically generated from K8s API.
+But for local test, we need to use `cue get go` to fetch Go packages and convert them to CUE format files.
 
-Dry run the application by using `vela system dry-run`.
+So, by using K8s `Deployment` and `Serivice`, we need download and convert to CUE definitions for the `core` and `apps` Kubernetes modules like below:
 
 ```shell
-$ vela system dry-run -f test-app.yaml -d componentdef.yaml
----
-# Application(boutique) -- Comopnent(frontend)
----
-
-apiVersion: apps/v1
-kind: Deployment
-metadata:
-  labels:
-    app.oam.dev/component: frontend
-    app.oam.dev/name: boutique
-    workload.oam.dev/type: microservice
-  name: frontend
-  namespace: default
-spec:
-  selector:
-    matchLabels:
-      app: frontend
-  template:
-    metadata:
-      labels:
-        app: frontend
-        version: v1
-    spec:
-      containers:
-      - env:
-        - name: PORT
-          value: "8080"
-        image: registry.cn-hangzhou.aliyuncs.com/vela-samples/frontend:v0.2.2
-        name: frontend
-        ports:
-        - containerPort: 8080
-        resources:
-          requests:
-            cpu: 100m
-            memory: 64Mi
-      serviceAccountName: default
-      terminationGracePeriodSeconds: 30
-
----
-apiVersion: v1
-kind: Service
-metadata:
-  labels:
-    app: frontend
-    app.oam.dev/component: frontend
-    app.oam.dev/name: boutique
-    trait.oam.dev/resource: service
-    trait.oam.dev/type: AuxiliaryWorkload
-  name: frontend
-spec:
-  ports:
-  - port: 80
-    targetPort: 8080
-  selector:
-    app: frontend
-  type: ClusterIP
-
----
+cue get go k8s.io/api/core/v1
+cue get go k8s.io/api/apps/v1
 ```
 
-### Import `kube` Package
+After that, the module directory will show the following contents:
 
-KubeVela automatically generates internal CUE packages for all built-in Kubernetes API resources, so you can import them in CUE template. This could simplify how you write the template because some default values are already there, and the imported package will help you validate the template.
+```shell
+├── cue.mod
+│   ├── gen
+│   │   └── k8s.io
+│   │       ├── api
+│   │       │   ├── apps
+│   │       │   └── core
+│   │       └── apimachinery
+│   │           └── pkg
+│   ├── module.cue
+│   ├── pkg
+│   └── usr
+├── def.cue
+├── go.mod
+└── go.sum
+```
 
-Let's try to define a template with help of `kube` package:
+The package import path in CUE template should be:
 
 ```cue
 import (
-   apps "kube/apps/v1"
-   corev1 "kube/v1"
+   apps "k8s.io/api/apps/v1"
+   corev1 "k8s.io/api/core/v1"
+)
+```
+
+3. Refactor directory hierarchy.
+
+Our goal is to test template locally and use the same template in KubeVela.
+So we need to refactor our local CUE module directories a bit to align with the import path provided by KubeVela,
+
+Copy the `apps` and `core` from `cue.mod/gen/k8s.io/api` to `cue.mod/gen/k8s.io`.
+(Note we should keep the source directory `apps` and `core` in `gen/k8s.io/api` to avoid package dependency issues).
+
+```bash
+cp -r cue.mod/gen/k8s.io/api/apps cue.mod/gen/k8s.io
+cp -r cue.mod/gen/k8s.io/api/core cue.mod/gen/k8s.io
+```
+
+The modified module directory should like:
+
+```shell
+├── cue.mod
+│   ├── gen
+│   │   └── k8s.io
+│   │       ├── api
+│   │       │   ├── apps
+│   │       │   └── core
+│   │       ├── apimachinery
+│   │       │   └── pkg
+│   │       ├── apps
+│   │       └── core
+│   ├── module.cue
+│   ├── pkg
+│   └── usr
+├── def.cue
+├── go.mod
+└── go.sum
+```
+
+So, you can import the package use the following path that aligns with KubeVela:
+
+```cue
+import (
+   apps "k8s.io/apps/v1"
+   corev1 "k8s.io/core/v1"
+)
+```
+
+4. Test and Run.
+
+Finally, we can test CUE Template which use the `Kube` package.
+
+```cue
+import (
+   apps "k8s.io/apps/v1"
+   corev1 "k8s.io/core/v1"
 )
 
 // output is validated by Deployment.
@@ -467,16 +501,166 @@ parameter: {
 	cpu?:    string
 	memory?: string
 }
+
+// mock context data
+context: {
+    name: "test"
+}
+
+// mock parameter data
+parameter: {
+	image:          "test-image"
+	servicePort:    8000
+	env: {
+        "HELLO": "WORLD"
+    }
+}
 ```
 
-Then merge them.
+Use `cue export` to see the export result.
 
 ```shell
-mergedef.sh def.yaml def.cue > componentdef.yaml
+$ cue export def.cue --out yaml
+output:
+  metadata:
+    name: test
+    namespace: default
+  spec:
+    selector:
+      matchLabels:
+        app: test
+    template:
+      metadata:
+        labels:
+          app: test
+          version: v1
+      spec:
+        terminationGracePeriodSeconds: 30
+        containers:
+        - name: test
+          image: test-image
+          ports:
+          - containerPort: 8000
+          env:
+          - name: HELLO
+            value: WORLD
+          resources:
+            requests: {}
+outputs:
+  service:
+    metadata:
+      name: test
+      labels:
+        app: test
+    spec:
+      selector:
+        app: test
+      ports:
+      - port: 8000
+        targetPort: 8000
+parameter:
+  version: v1
+  image: test-image
+  servicePort: 8000
+  podShutdownGraceSeconds: 30
+  env:
+    HELLO: WORLD
+context:
+  name: test
 ```
 
-And dry run to see the rendered resources:
+## Dry-Run the `Application`
+
+When CUE template is good, we can use `vela system dry-run` to dry run and check the rendered resources in real Kubernetes cluster. This command will exactly execute the same render logic in KubeVela's `Application` Controller adn output the result for you.
+
+First, we need use `mergedef.sh` to merge the definition and cue files.
 
 ```shell
-vela system dry-run -f test-app.yaml -d componentdef.yaml
+$ mergedef.sh def.yaml def.cue > componentdef.yaml
+```
+
+Then, let's create an Application named `test-app.yaml`.
+
+```yaml
+apiVersion: core.oam.dev/v1beta1
+kind: Application
+metadata:
+  name: boutique
+  namespace: default
+spec:
+  components:
+    - name: frontend
+      type: microservice
+      properties:
+        image: registry.cn-hangzhou.aliyuncs.com/vela-samples/frontend:v0.2.2
+        servicePort: 80
+        containerPort: 8080
+        env:
+          PORT: "8080"
+        cpu: "100m"
+        memory: "64Mi"
+```
+
+Dry run the application by using `vela system dry-run`.
+
+```shell
+$ vela system dry-run -f test-app.yaml -d componentdef.yaml
+---
+# Application(boutique) -- Comopnent(frontend)
+---
+
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  labels:
+    app.oam.dev/component: frontend
+    app.oam.dev/name: boutique
+    workload.oam.dev/type: microservice
+  name: frontend
+  namespace: default
+spec:
+  selector:
+    matchLabels:
+      app: frontend
+  template:
+    metadata:
+      labels:
+        app: frontend
+        version: v1
+    spec:
+      containers:
+      - env:
+        - name: PORT
+          value: "8080"
+        image: registry.cn-hangzhou.aliyuncs.com/vela-samples/frontend:v0.2.2
+        name: frontend
+        ports:
+        - containerPort: 8080
+        resources:
+          requests:
+            cpu: 100m
+            memory: 64Mi
+      serviceAccountName: default
+      terminationGracePeriodSeconds: 30
+
+---
+apiVersion: v1
+kind: Service
+metadata:
+  labels:
+    app: frontend
+    app.oam.dev/component: frontend
+    app.oam.dev/name: boutique
+    trait.oam.dev/resource: service
+    trait.oam.dev/type: AuxiliaryWorkload
+  name: frontend
+spec:
+  ports:
+  - port: 80
+    targetPort: 8080
+  selector:
+    app: frontend
+  type: ClusterIP
+
+---
 ```

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

@@ -2,8 +2,7 @@
 title:  Definition CRD
 ---
 
-This documentation explains how to register and manage available *components* and *traits* in your platform with
-`ComponentDefinition` and `TraitDefinition`, so end users could instantiate and "assemble" them into an `Application`.
+This documentation explains `ComponentDefinition` and `TraitDefinition` in detail.
 
 > All definition objects are expected to be maintained and installed by platform team, think them as *capability providers* in your platform.
 
@@ -76,7 +75,8 @@ spec:
     - webservice
   conflictsWith: 
     - service
-  workloadRefPath: spec.wrokloadRef 
+  workloadRefPath: spec.wrokloadRef
+  podDisruptive: false
 ```
 
 Let's explain them in detail.
@@ -116,12 +116,20 @@ If this field is omitted, it means this trait is NOT conflicting with any traits
 ##### `.spec.workloadRefPath`
 
 This field defines the field path of the trait which is used to store the reference of the workload to which the trait is applied.
-- It accepts a string as value, e.g., `spec.workloadRef`.  
+- It accepts a string as value, e.g., `spec.workloadRef`.
 
 If this field is set, KubeVela core will automatically fill the workload reference into target field of the trait. Then the trait controller can get the workload reference from the trait latter. So this field usually accompanies with the traits whose controllers relying on the workload reference at runtime. 
 
 Please check [scaler](https://github.com/oam-dev/kubevela/blob/master/charts/vela-core/templates/defwithtemplate/manualscale.yaml) trait as a demonstration of how to set this field.
 
+##### `.spec.podDisruptive`
+
+This field defines that adding/updating the trait will disruptive the pod or not.
+In this example, the answer is not, so the field is `false`, it will not affect the pod when the trait is added or updated.
+If the field is `true`, then it will cause the pod to disruptive and restart when the trait is added or updated.
+By default, the value is `false` which means this trait will not affect.
+Please take care of this field, it's really important and useful for serious large scale production usage scenarios.
+
 ### Capability Encapsulation and Abstraction
 
 The templating and parameterizing of given capability are defined in `spec.schematic` field. For example, below is the full definition of *Web Service* type in KubeVela:

docs/en/platform-engineers/keda.md

@@ -69,7 +69,7 @@ In this step, we will define the schematic of KEDA based autoscaling trait, i.e.
 schematic:
   cue:
     template: |-
-      outputs: cpu-scaler: {
+      outputs: kedaScaler: {
       	apiVersion: "keda.sh/v1alpha1"
       	kind:       "ScaledObject"
       	metadata: {
@@ -80,17 +80,17 @@ schematic:
       			name: context.name
       		}
       		triggers: [{
-      			type: paramter.type
+      			type: parameter.triggerType
       			metadata: {
       				type:  "Utilization"
-      				value: paramter.value
+      				value: parameter.value
       			}
       		}]
       	}
       }
-      paramter: {
+      parameter: {
       	// +usage=Types of triggering application elastic scaling, Optional: cpu, memory
-      	type: string
+      	triggerType: string
       	// +usage=Value to trigger scaling actions, represented as a percentage of the requested value of the resource for the pods. like: "60"(60%)
       	value: string
       }

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

@@ -62,8 +62,6 @@ Below is a form rendered with `form-render`:
 
 ![](../../resources/json-schema-render-example.jpg)
 
-> Hence, end users of KubeVela do NOT need to learn about definition object to use a capability, they always work with a visualized form or learn the generated schema if they want.
-
 # What's Next
 
 It's by design that KubeVela supports multiple ways to define the schematic. Hence, we will explain `.schematic` field in detail with following guides.

docs/en/platform-engineers/overview.md

@@ -6,15 +6,15 @@ This documentation will explain what is `Application` object and why you need it
 
 ## Motivation
 
-Encapsulation is probably the mostly widely used approach to enable easier developer experience and allow users to deliver the whole application resources as one unit. For example, many tools today encapsulate Kubernetes *Deployment* and *Service* into a *Web Service* module, and then instantiate this module by simply providing parameters such as *image=foo* and *ports=80*. This pattern can be found in cdk8s (e.g. [`web-service.ts` ](https://github.com/awslabs/cdk8s/blob/master/examples/typescript/web-service/web-service.ts)), CUE (e.g. [`kube.cue`](https://github.com/cuelang/cue/blob/b8b489251a3f9ea318830788794c1b4a753031c0/doc/tutorial/kubernetes/quick/services/kube.cue#L70)), and many widely used Helm charts (e.g. [Web Service](https://docs.bitnami.com/tutorials/create-your-first-helm-chart/)).
+Encapsulation based abstraction is probably the mostly widely used approach to enable easier developer experience and allow users to deliver the whole application resources as one unit. For example, many tools today encapsulate Kubernetes *Deployment* and *Service* into a *Web Service* module, and then instantiate this module by simply providing parameters such as *image=foo* and *ports=80*. This pattern can be found in cdk8s (e.g. [`web-service.ts` ](https://github.com/awslabs/cdk8s/blob/master/examples/typescript/web-service/web-service.ts)), CUE (e.g. [`kube.cue`](https://github.com/cuelang/cue/blob/b8b489251a3f9ea318830788794c1b4a753031c0/doc/tutorial/kubernetes/quick/services/kube.cue#L70)), and many widely used Helm charts (e.g. [Web Service](https://docs.bitnami.com/tutorials/create-your-first-helm-chart/)).
 
-Despite the efficiency and extensibility in defining abstractions with encapsulation, both DSL tools (e.g. cdk8s , CUE and Helm templating) are mostly used as client side tools and can be barely used as a platform level building block. This leaves platform builders either have to create restricted/inextensible abstractions, or re-invent the wheels of what DSL/templating has already been doing great.
+Despite the efficiency and extensibility in defining abstractions, both DSL tools (e.g. cdk8s , CUE and Helm templating) are mostly used as client side tools and can be barely used as a platform level building block. This leaves platform builders either have to create restricted/inextensible abstractions, or re-invent the wheels of what DSL/templating has already been doing great.
 
 KubeVela allows platform teams to create developer-centric abstractions with DSL/templating but maintain them with the battle tested [Kubernetes Control Loop](https://kubernetes.io/docs/concepts/architecture/controller/). 
 
-## Abstraction
+## Application
 
-First of all, KubeVela introduces an `Application` CRD as its main abstraction that could capture all needed resources to run the application, and exposes configurable parameters for end users. Every application is composed by multiple components, and each of them is defined by workload specification and traits (operational behaviors). For example:
+First of all, KubeVela introduces an `Application` CRD as its main abstraction that could capture a full application deployment. To model the modern microservices, every application is composed by multiple components with attached traits (operational behaviors). For example:
 
 ```yaml
 apiVersion: core.oam.dev/v1beta1
@@ -43,21 +43,11 @@ spec:
       bucket: "my-bucket"
 ```
 
-## Encapsulation
+The schema of *component* and *trait* specification in this application is actually enforced by another set of building block objects named *"definitions"*, for example, `ComponentDefinition` and `TraitDefinition`.
 
-With `Application` provides an abstraction to deploy apps, each *component* and *trait* specification in this application is actually enforced by another set of building block objects named *"definitions"*, for example, `ComponentDefinition` and `TraitDefinition`.
+`XxxDefinition` resources are designed to leverage encapsulation solutions such as `CUE`, `Helm` and `Terraform modules` to template and parameterize Kubernetes resources as well as cloud services. This enables users to assemble templated capabilities into an `Application` by simply setting parameters. In the `application-sample` above, it models a Kubernetes Deployment (component `foo`) to run container and a Alibaba Cloud OSS bucket (component `bar`) alongside.
 
-Definitions are designed to leverage encapsulation technologies such as `CUE`, `Helm` and `Terraform modules` to template and parameterize Kubernetes resources as well as cloud services. This enables users to assemble templated capabilities into an `Application` by simply setting parameters. In the `application-sample` above, it models a Kubernetes Deployment (component `foo`) to run container and a Alibaba Cloud OSS bucket (component `bar`) alongside.
-
-This encapsulation and abstraction mechanism is the key for KubeVela to provide *PaaS-like* experience (*i.e. app-centric, higher level abstractions, self-service operations etc*) to end users.
-
-### No Configuration Drift
-
-Many of the existing encapsulation solutions today work at client side, for example, DSL/IaC (Infrastructure as Code) tools and Helm. This approach is easy to be adopted and has less invasion in the user cluster.
-
-But client side abstractions, though light-weighted, always lead to an issue called infrastructure/configuration drift, i.e. the generated component instances are not in line with the expected configuration. This could be caused by incomplete coverage, less-than-perfect processes or emergency changes.
-
-Hence, the encapsulation engine of KubeVela is designed to be a [Kubernetes Control Loop](https://kubernetes.io/docs/concepts/architecture/controller/) and leverage Kubernetes control plane to eliminate the issue of configuration drifting, and still keeps the flexibly and velocity enabled by existing encapsulation solutions (e.g. DSL/IaC and templating).
+This abstraction mechanism is the key for KubeVela to provide *PaaS-like* experience (*i.e. app-centric, higher level abstractions, self-service operations etc*) to end users, with benefits highlighted as below.
 
 ### No "Juggling" Approach to Manage Kubernetes Objects
 
@@ -67,7 +57,15 @@ The issue above could be even painful if the component instance is not *Deployme
 
 #### Standard Contract Behind The Abstraction
 
-The encapsulation engine of KubeVela is designed to relieve such burden of managing versionized Kubernetes resources manually. In nutshell, all the needed Kubernetes resources for an app are now encapsulated in a single abstraction, and KubeVela will maintain the instance name, revisions, labels and selector by the battle tested reconcile loop automation, not by human hand. At the meantime, the existence of definition objects allow the platform team to customize the details of all above metadata behind the abstraction, even control the behavior of how to do revision.
+KubeVela is designed to relieve such burden of managing versionized Kubernetes resources manually. In nutshell, all the needed Kubernetes resources for an app are now encapsulated in a single abstraction, and KubeVela will maintain the instance name, revisions, labels and selector by the battle tested reconcile loop automation, not by human hand. At the meantime, the existence of definition objects allow the platform team to customize the details of all above metadata behind the abstraction, even control the behavior of how to do revision.
 
-Thus, all those metadata now become a standard contract that any day 2 operation controller such as Istio or rollout can rely on. This is the key to ensure our platform could provide user friendly experience but keep "transparent" to the operational behaviors.
+Thus, all those metadata now become a standard contract that any "day 2" operation controller such as Istio or rollout can rely on. This is the key to ensure our platform could provide user friendly experience but keep "transparent" to the operational behaviors.
+
+### No Configuration Drift
+
+Light-weighted and flexible in defining abstractions, any of the existing encapsulation solutions today work at client side, for example, DSL/IaC (Infrastructure as Code) tools and Helm. This approach is easy to be adopted and has less invasion in the user cluster.
+
+But client side abstractions always lead to an issue called *Infrastructure/Configuration Drift*, i.e. the generated component instances are not in line with the expected configuration. This could be caused by incomplete coverage, less-than-perfect processes or emergency changes.
+
+Hence, all abstractions in KubeVela is designed to be maintained with [Kubernetes Control Loop](https://kubernetes.io/docs/concepts/architecture/controller/) and leverage Kubernetes control plane to eliminate the issue of configuration drifting, and still keeps the flexibly and velocity enabled by existing encapsulation solutions (e.g. DSL/IaC and templating).
 

docs/en/rollout/appdeploy.md

@@ -1,21 +1,22 @@
 ---
-title: Multi-Version Multi-Cluster Application Deployment
+title: Multi-Cluster Application Deployment
 ---
 
 # Introduction
 
-KubeVela provides Application CRD which templates the low level resources and exposes high level parameters to users. But that's not enough -- it often requires a couple of standard techniques to deploy an application in production:
-
-- Rolling upgrade: To continuously deploy apps requires to rollout in a safe manner which usually involves step by step rollout batches and analysis.
+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.
-- Multi-cluster: Modern application infrastructure involves multiple clusters to ensure high availability and maximize service throughput.
 
 ## AppDeployment CRD
 
-The AppDeployment CRD has been provided to satisfy such requirements. Here's an overview of the API:
+The `AppDeployment` CRD has been provided to satisfy such requirements. Here's an overview of the API:
 
 ```yaml
+apiVersion: core.oam.dev/v1beta1
 kind: AppDeployment
+metadata:
+  name: sample-appdeploy
 spec:
   traffic:
     hosts:
@@ -76,6 +77,7 @@ spec:
 The clusters selected in the `placement` part from above is defined in Cluster CRD. Here's what it looks like:
 
 ```yaml
+apiVersion: core.oam.dev/v1beta1
 kind: Cluster
 metadata:
   name: prod-cluster-1
@@ -89,7 +91,8 @@ spec:
 The secret must contain the kubeconfig credentials in `config` field:
 
 ```yaml
-kind: secret:
+apiVersion: v1
+kind: Secret
 metadata:
   name: kubeconfig-cluster-1
 data:
@@ -130,7 +133,7 @@ You must run all commands in that directory.
    example-app-v1   116s
    ```
 
-   With above annotation this won't create any pod instances.
+   > Note: with `app.oam.dev/revision-only: "true"` annotation, above `Application` resource won't create any pod instances and leave the real deployment process to `AppDeployment`.
 
 1. Then use the above AppRevision to create an AppDeployment.
 
@@ -138,7 +141,7 @@ You must run all commands in that directory.
    $ kubectl apply -f appdeployment-1.yaml
    ```
 
-   > Note that in order to AppDeployment to work, your workload object must have a `spec.replicas` field for scaling.
+   > Note: in order to AppDeployment to work, your workload object must have a `spec.replicas` field for scaling.
 
 1. Now you can check that there will 1 deployment and 2 pod instances deployed
 

docs/en/rollout/rollout.md

@@ -18,7 +18,7 @@ We design KubeVela rollout solutions with the following principles in mind
   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.
+  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
@@ -49,9 +49,9 @@ spec:
 ```
 
 ## User Experience Workflow
-Here is the end to end user experience
+Here is the end to end user experience based on [CloneSet](https://openkruise.io/en-us/docs/cloneset.html)
 
-1. Install Open Kurise and CloneSet based workloadDefinition
+1. Install CloneSet and create a `ComponentDefinition` for it.
 ```shell
 helm install kruise https://github.com/openkruise/kruise/releases/download/v0.7.0/kruise-chart.tgz
 ```
@@ -234,7 +234,7 @@ spec:
         replicas: 5
 ```
 
-5. Apply the application rollout that upgarde the application from v1 to v2
+5. Apply the application rollout that upgrade the application from v1 to v2
 ```yaml
 apiVersion: core.oam.dev/v1beta1
 kind: AppRollout
@@ -263,4 +263,4 @@ Here is the high level state transition graph
 
 ## Roadmap
 
-Our recent roadmap for progressive rollout is [here](./roadmap).
+Our recent roadmap for progressive rollout is [here](./roadmap).

docs/examples/app-with-status/template.yaml

@@ -80,6 +80,7 @@ spec:
       message: "type: "+ context.outputs.service.spec.type +",\t clusterIP:"+ context.outputs.service.spec.clusterIP+",\t ports:"+ "\(context.outputs.service.spec.ports[0].port)"+",\t domain"+context.outputs.ingress.spec.rules[0].host
     healthPolicy: |
       isHealth: len(context.outputs.service.spec.clusterIP) > 0
+  podDisruptive: false
   schematic:
     cue:
       template: |

docs/examples/cloneset-rollout/app-scale.yaml

@@ -1,9 +1,8 @@
 apiVersion: core.oam.dev/v1beta1
 kind: Application
 metadata:
-  name: test-rolling-pause
+  name: test-rolling
   annotations:
-    "app.oam.dev/rolling-components": "metrics-provider"
     "app.oam.dev/rollout-template": "true"
 spec:
   components:
@@ -13,7 +12,6 @@ spec:
         cmd:
           - ./podinfo
           - stress-cpu=1
-        image: stefanprodan/podinfo:4.0.3
+        image: stefanprodan/podinfo:4.0.6
         port: 8080
-        updateStrategyType: InPlaceIfPossible
-        replicas: 10
+        updateStrategyType: InPlaceIfPossible

docs/examples/cloneset-rollout/app-source.yaml

@@ -3,7 +3,6 @@ kind: Application
 metadata:
   name: test-rolling
   annotations:
-    "app.oam.dev/rolling-components": "metrics-provider"
     "app.oam.dev/rollout-template": "true"
 spec:
   components:

docs/examples/cloneset-rollout/app-target.yaml

@@ -3,7 +3,6 @@ kind: Application
 metadata:
   name: test-rolling
   annotations:
-    "app.oam.dev/rolling-components": "metrics-provider"
     "app.oam.dev/rollout-template": "true"
 spec:
   components:

docs/examples/cloneset-rollout/appRollout-revert.yaml

@@ -5,7 +5,7 @@ metadata:
 spec:
   # application (revision) reference
   sourceAppRevisionName: test-rolling-v2
-  targetAppRevisionName: test-rolling-v3
+  targetAppRevisionName: test-rolling-v1
   componentList:
     - metrics-provider
   rolloutPlan:

docs/examples/cloneset-rollout/appRollout-scale.yaml

@@ -8,8 +8,10 @@ spec:
   componentList:
     - metrics-provider
   rolloutPlan:
+    targetSize: 6
     rolloutStrategy: "IncreaseFirst"
     rolloutBatches:
-      - replicas: 10%
-      - replicas: 2
-      - replicas: 2
+      - replicas: 1
+      - replicas: 20%
+      - replicas: 40%
+      - replicas: 40%

docs/examples/dry-run/definitions/myingress.yaml

@@ -5,6 +5,7 @@ metadata:
 spec:
   appliesToWorkloads:
     - "*"
+  podDisruptive: false
   schematic:
     cue:
       template: |

docs/examples/helm-module/virtual-group-td.yaml

@@ -9,6 +9,7 @@ spec:
     - webservice
     - worker
     - deployments.apps
+  podDisruptive: true
   extension:
     template: |-
       patch: {

docs/examples/kube-module/virtual-group-td.yaml

@@ -9,6 +9,7 @@ spec:
     - webservice
     - worker
     - deployments.apps
+  podDisruptive: true
   extension:
     template: |-
       patch: {

docs/examples/registry/autoscale.yaml

@@ -12,6 +12,7 @@ spec:
   workloadRefPath: spec.workloadRef
   definitionRef:
     name: autoscalers.standard.oam.dev
+  podDisruptive: true
   extension:
     install:
       helm:

docs/examples/registry/for-loop.yaml

@@ -4,6 +4,7 @@ metadata:
   name: expose
   namespace: vela-system
 spec:
+  podDisruptive: false
   schematic:
     cue:
       template: |-

docs/examples/registry/hpa.yaml

@@ -8,6 +8,7 @@ spec:
   appliesToWorkloads:
     - webservice
     - worker
+  podDisruptive: true
   schematic:
     cue:
       template: |

docs/examples/registry/initcontainer.yaml

@@ -9,6 +9,7 @@ spec:
   appliesToWorkloads:
     - webservice
     - worker
+  podDisruptive: true
   schematic:
     cue:
       template: |-

docs/examples/registry/kautoscale.yaml

@@ -8,6 +8,7 @@ metadata:
 spec:
   appliesToWorkloads:
     - webservice # this should be some knative like workload
+  podDisruptive: true
   schematic:
     cue:
       template: |-

docs/examples/registry/node-affinity.yaml

@@ -9,6 +9,7 @@ spec:
   appliesToWorkloads:
     - webservice
     - worker
+  podDisruptive: true
   schematic:
     cue:
       template: |-

docs/examples/registry/patch-replica.yaml

@@ -9,6 +9,7 @@ spec:
   appliesToWorkloads:
     - webservice
     - worker
+  podDisruptive: true
   schematic:
     cue:
       template: |-

docs/examples/registry/rollout.yaml

@@ -12,6 +12,7 @@ spec:
     name: canaries.flagger.app
   workloadRefPath: spec.targetRef
   revisionEnabled: true
+  podDisruptive: true
   extension:
     install:
       helm:

docs/examples/registry/route.yaml

@@ -11,6 +11,7 @@ spec:
   workloadRefPath: spec.workloadRef
   definitionRef:
     name: routes.standard.oam.dev
+  podDisruptive: false
   extension:
     install:
       helm:

docs/examples/registry/sidecar.yaml

@@ -8,6 +8,7 @@ spec:
   appliesToWorkloads:
     - webservice
     - worker
+  podDisruptive: true
   schematic:
     cue:
       template: |-

docs/examples/registry/virtualgroup.yaml

@@ -9,6 +9,7 @@ spec:
   appliesToWorkloads:
     - webservice
     - worker
+  podDisruptive: false
   schematic:
     cue:
       template: |-

docs/index.js

@@ -1,118 +0,0 @@
-import React from 'react';
-import clsx from 'clsx';
-import Layout from '@theme/Layout';
-import Link from '@docusaurus/Link';
-import features from '../data/features'
-import Translate, { translate } from '@docusaurus/Translate';
-import useDocusaurusContext from '@docusaurus/useDocusaurusContext';
-import useBaseUrl from '@docusaurus/useBaseUrl';
-import GitHubButton from 'react-github-btn';
-import styles from './styles.module.css';
-
-function Feature({ imgUrl, title, description, reverse }) {
-  return (
-    <div className={clsx('row', styles.feature, reverse ? styles.featureReverse : '')}>
-      <div className="col col--3">
-        <div className="text--center">
-          {imgUrl && <img className={styles.featureImage} src={useBaseUrl(imgUrl)} alt={title} />}
-        </div>
-      </div>
-      <div className={clsx('col col--9', styles.featureDesc)}>
-        <div>
-          <h2>{title}</h2>
-          <div>{description}</div>
-        </div>
-      </div>
-    </div>
-  )
-}
-
-const Button = ({ children, href }) => {
-  return (
-    <div className="col col--2 margin-horiz--sm">
-      <Link
-        className="button button--outline button--primary button--lg"
-        to={href}>
-        {children}
-      </Link>
-    </div>
-  );
-};
-
-export default function Home() {
-  const context = useDocusaurusContext();
-  const { siteConfig = {} } = context;
-
-  return (
-    <Layout title={siteConfig.tagline} description={siteConfig.tagline}>
-      <header className={clsx('hero', styles.hero)}>
-        <div className="container text--center">
-          <div className={styles.heroLogoWrapper}>
-            <img className={styles.heroLogo} src={useBaseUrl('img/logo.svg')} alt="Kubevela Logo" />
-          </div>
-          <h2 className={clsx('hero__title', styles.heroTitle)}>{siteConfig.title}</h2>
-          <GitHubButton
-            href="https://github.com/oam-dev/kubevela"
-            data-icon="octicon-star"
-            data-size="large"
-            data-show-count="true"
-            aria-label="Star facebook/metro on GitHub">
-            Star
-         </GitHubButton>
-          <p className="hero__subtitle">{siteConfig.tagline}</p>
-          <div
-            className={clsx(styles.heroButtons, 'name', 'margin-vert--md')}>
-            <Button href={useBaseUrl('docs/quick-start')}>Get Started</Button>
-            <Button href={useBaseUrl('docs/')}>Learn More</Button>
-          </div>
-        </div>
-      </header>
-
-      <WhatIs />
-
-      <main className={clsx('hero', styles.hero)}>
-        <div className="container">
-          <section className={styles.features}>
-            <div className="container">
-              {features.map((f, idx) => (
-                <Feature key={idx} {...f} />
-              ))}
-            </div>
-          </section>
-        </div>
-      </main>
-
-    </Layout>
-  );
-}
-
-const WhatIs = () => (
-  <div className={clsx('hero', styles.hero)}>
-    <div className="container">
-      <div className="row">
-        <div className="col col--6">
-          <h1><Translate>What is KubeVela?</Translate></h1>
-          <p className="hero__subtitle">
-            <small>
-              <strong><Translate>For platform builders</Translate></strong>: <Translate>
-                KubeVela serves as a framework that empowers them to create user friendly yet highly extensible platforms at ease
-              </Translate>
-              <br />
-              <strong><Translate>For developers</Translate></strong>: <Translate>
-                such Application abstraction built with KubeVela will enable them to design and ship their applications to Kubernetes with minimal effort.
-              </Translate>
-              </small>
-          </p>
-        </div>
-        <div className="col">
-          <img
-            className="image"
-            src={useBaseUrl("img/what-is-kubevela.png")}
-            align="right"
-            alt="what is kubevela"
-          />
-        </div>
-      </div>
-    </div>
-  </div>
-);

docs/install.ps1

@@ -1,116 +0,0 @@
-# Implemented based on Dapr Cli https://github.com/dapr/cli/tree/master/install
-
-param (
-    [string]$Version,
-    [string]$VelaRoot = "c:\vela"
-)
-
-Write-Output ""
-$ErrorActionPreference = 'stop'
-
-#Escape space of VelaRoot path
-$VelaRoot = $VelaRoot -replace ' ', '` '
-
-# Constants
-$VelaCliFileName = "vela.exe"
-$VelaCliFilePath = "${VelaRoot}\${VelaCliFileName}"
-
-# GitHub Org and repo hosting Vela CLI
-$GitHubOrg = "oam-dev"
-$GitHubRepo = "kubevela"
-
-# Set Github request authentication for basic authentication.
-if ($Env:GITHUB_USER) {
-    $basicAuth = [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes($Env:GITHUB_USER + ":" + $Env:GITHUB_TOKEN));
-    $githubHeader = @{"Authorization" = "Basic $basicAuth" }
-}
-else {
-    $githubHeader = @{}
-}
-
-if ((Get-ExecutionPolicy) -gt 'RemoteSigned' -or (Get-ExecutionPolicy) -eq 'ByPass') {
-    Write-Output "PowerShell requires an execution policy of 'RemoteSigned'."
-    Write-Output "To make this change please run:"
-    Write-Output "'Set-ExecutionPolicy RemoteSigned -scope CurrentUser'"
-    break
-}
-
-# Change security protocol to support TLS 1.2 / 1.1 / 1.0 - old powershell uses TLS 1.0 as a default protocol
-[Net.ServicePointManager]::SecurityProtocol = "tls12, tls11, tls"
-
-# Check if KubeVela CLI is installed.
-if (Test-Path $VelaCliFilePath -PathType Leaf) {
-    Write-Warning "vela is detected - $VelaCliFilePath"
-    Invoke-Expression "$VelaCliFilePath --version"
-    Write-Output "Reinstalling KubeVela..."
-}
-else {
-    Write-Output "Installing Vela..."
-}
-
-# Create Vela Directory
-Write-Output "Creating $VelaRoot directory"
-New-Item -ErrorAction Ignore -Path $VelaRoot -ItemType "directory"
-if (!(Test-Path $VelaRoot -PathType Container)) {
-    throw "Cannot create $VelaRoot"
-}
-
-# Get the list of release from GitHub
-$releases = Invoke-RestMethod -Headers $githubHeader -Uri "https://api.github.com/repos/${GitHubOrg}/${GitHubRepo}/releases" -Method Get
-if ($releases.Count -eq 0) {
-    throw "No releases from github.com/oam-dev/kubevela repo"
-}
-
-# Filter windows binary and download archive
-$os_arch = "windows-amd64"
-if (!$Version) {
-    $windowsAsset = $releases | Where-Object { $_.tag_name -notlike "*rc*" } | Select-Object -First 1 | Select-Object -ExpandProperty assets | Where-Object { $_.name -Like "*${os_arch}.zip" }
-    if (!$windowsAsset) {
-        throw "Cannot find the windows KubeVela CLI binary"
-    }
-    $zipFileUrl = $windowsAsset.url
-    $assetName = $windowsAsset.name
-} else {
-    $assetName = "vela-${Version}-${os_arch}.zip"
-    $zipFileUrl = "https://github.com/${GitHubOrg}/${GitHubRepo}/releases/download/${Version}/${assetName}"
-}
-
-$zipFilePath = $VelaRoot + "\" + $assetName
-Write-Output "Downloading $zipFileUrl ..."
-
-$githubHeader.Accept = "application/octet-stream"
-Invoke-WebRequest -Headers $githubHeader -Uri $zipFileUrl -OutFile $zipFilePath
-if (!(Test-Path $zipFilePath -PathType Leaf)) {
-    throw "Failed to download Vela Cli binary - $zipFilePath"
-}
-
-# Extract KubeVela CLI to $VelaRoot
-Write-Output "Extracting $zipFilePath..."
-Microsoft.Powershell.Archive\Expand-Archive -Force -Path $zipFilePath -DestinationPath $VelaRoot
-$ExtractedVelaCliFilePath = "${VelaRoot}\${os_arch}\${VelaCliFileName}"
-Copy-Item $ExtractedVelaCliFilePath -Destination $VelaCliFilePath
-if (!(Test-Path $VelaCliFilePath -PathType Leaf)) {
-    throw "Failed to extract Vela Cli archive - $zipFilePath"
-}
-
-# Check the KubeVela CLI version
-Invoke-Expression "$VelaCliFilePath --version"
-
-# Clean up zipfile
-Write-Output "Clean up $zipFilePath..."
-Remove-Item $zipFilePath -Force
-
-# Add VelaRoot directory to User Path environment variable
-Write-Output "Try to add $VelaRoot to User Path Environment variable..."
-$UserPathEnvironmentVar = [Environment]::GetEnvironmentVariable("PATH", "User")
-if ($UserPathEnvironmentVar -like '*vela*') {
-    Write-Output "Skipping to add $VelaRoot to User Path - $UserPathEnvironmentVar"
-}
-else {
-    [System.Environment]::SetEnvironmentVariable("PATH", $UserPathEnvironmentVar + ";$VelaRoot", "User")
-    $UserPathEnvironmentVar = [Environment]::GetEnvironmentVariable("PATH", "User")
-    Write-Output "Added $VelaRoot to User Path - $UserPathEnvironmentVar"
-}
-
-Write-Output "`r`nKubeVela CLI is installed successfully."
-Write-Output "To get started with KubeVela, please visit https://kubevela.io."

docs/install.sh

@@ -1,189 +0,0 @@
-#!/usr/bin/env bash
-
-# Implemented based on Dapr Cli https://github.com/dapr/cli/tree/master/install
-
-# Vela CLI location
-: ${VELA_INSTALL_DIR:="/usr/local/bin"}
-
-# sudo is required to copy binary to VELA_INSTALL_DIR for linux
-: ${USE_SUDO:="false"}
-
-# Http request CLI
-VELA_HTTP_REQUEST_CLI=curl
-
-# GitHub Organization and repo name to download release
-GITHUB_ORG=oam-dev
-GITHUB_REPO=kubevela
-
-# Vela CLI filename
-VELA_CLI_FILENAME=vela
-
-VELA_CLI_FILE="${VELA_INSTALL_DIR}/${VELA_CLI_FILENAME}"
-
-getSystemInfo() {
-    ARCH=$(uname -m)
-    case $ARCH in
-        armv7*) ARCH="arm";;
-        aarch64) ARCH="arm64";;
-        x86_64) ARCH="amd64";;
-    esac
-
-    OS=$(echo `uname`|tr '[:upper:]' '[:lower:]')
-
-    # Most linux distro needs root permission to copy the file to /usr/local/bin
-    if [ "$OS" == "linux" ] && [ "$VELA_INSTALL_DIR" == "/usr/local/bin" ]; then
-        USE_SUDO="true"
-    fi
-}
-
-verifySupported() {
-    local supported=(darwin-amd64 linux-amd64 linux-arm linux-arm64)
-    local current_osarch="${OS}-${ARCH}"
-
-    for osarch in "${supported[@]}"; do
-        if [ "$osarch" == "$current_osarch" ]; then
-            echo "Your system is ${OS}_${ARCH}"
-            return
-        fi
-    done
-
-    echo "No prebuilt binary for ${current_osarch}"
-    exit 1
-}
-
-runAsRoot() {
-    local CMD="$*"
-
-    if [ $EUID -ne 0 -a $USE_SUDO = "true" ]; then
-        CMD="sudo $CMD"
-    fi
-
-    $CMD
-}
-
-checkHttpRequestCLI() {
-    if type "curl" > /dev/null; then
-        VELA_HTTP_REQUEST_CLI=curl
-    elif type "wget" > /dev/null; then
-        VELA_HTTP_REQUEST_CLI=wget
-    else
-        echo "Either curl or wget is required"
-        exit 1
-    fi
-}
-
-checkExistingVela() {
-    if [ -f "$VELA_CLI_FILE" ]; then
-        echo -e "\nVela CLI is detected:"
-        $VELA_CLI_FILE --version
-        echo -e "Reinstalling Vela CLI - ${VELA_CLI_FILE}...\n"
-    else
-        echo -e "Installing Vela CLI...\n"
-    fi
-}
-
-getLatestRelease() {
-    local velaReleaseUrl="https://api.github.com/repos/${GITHUB_ORG}/${GITHUB_REPO}/releases"
-    local latest_release=""
-
-    if [ "$VELA_HTTP_REQUEST_CLI" == "curl" ]; then
-        latest_release=$(curl -s $velaReleaseUrl | grep \"tag_name\" | grep -v rc | awk 'NR==1{print $2}' |  sed -n 's/\"\(.*\)\",/\1/p')
-    else
-        latest_release=$(wget -q --header="Accept: application/json" -O - $velaReleaseUrl | grep \"tag_name\" | grep -v rc | awk 'NR==1{print $2}' |  sed -n 's/\"\(.*\)\",/\1/p')
-    fi
-
-    ret_val=$latest_release
-}
-
-downloadFile() {
-    LATEST_RELEASE_TAG=$1
-
-    VELA_CLI_ARTIFACT="${VELA_CLI_FILENAME}-${LATEST_RELEASE_TAG}-${OS}-${ARCH}.tar.gz"
-    # convert `-` to `_` to let it work
-    DOWNLOAD_BASE="https://github.com/${GITHUB_ORG}/${GITHUB_REPO}/releases/download"
-    DOWNLOAD_URL="${DOWNLOAD_BASE}/${LATEST_RELEASE_TAG}/${VELA_CLI_ARTIFACT}"
-
-    # Create the temp directory
-    VELA_TMP_ROOT=$(mktemp -dt vela-install-XXXXXX)
-    ARTIFACT_TMP_FILE="$VELA_TMP_ROOT/$VELA_CLI_ARTIFACT"
-
-    echo "Downloading $DOWNLOAD_URL ..."
-    if [ "$VELA_HTTP_REQUEST_CLI" == "curl" ]; then
-        curl -SsL "$DOWNLOAD_URL" -o "$ARTIFACT_TMP_FILE"
-    else
-        wget -q -O "$ARTIFACT_TMP_FILE" "$DOWNLOAD_URL"
-    fi
-
-    if [ ! -f "$ARTIFACT_TMP_FILE" ]; then
-        echo "failed to download $DOWNLOAD_URL ..."
-        exit 1
-    fi
-}
-
-installFile() {
-    tar xf "$ARTIFACT_TMP_FILE" -C "$VELA_TMP_ROOT"
-    local tmp_root_vela_cli="$VELA_TMP_ROOT/${OS}-${ARCH}/$VELA_CLI_FILENAME"
-
-    if [ ! -f "$tmp_root_vela_cli" ]; then
-        echo "Failed to unpack Vela CLI executable."
-        exit 1
-    fi
-
-    chmod o+x $tmp_root_vela_cli
-    runAsRoot cp "$tmp_root_vela_cli" "$VELA_INSTALL_DIR"
-
-    if [ -f "$VELA_CLI_FILE" ]; then
-        echo "$VELA_CLI_FILENAME installed into $VELA_INSTALL_DIR successfully."
-
-        $VELA_CLI_FILE --version
-    else 
-        echo "Failed to install $VELA_CLI_FILENAME"
-        exit 1
-    fi
-}
-
-fail_trap() {
-    result=$?
-    if [ "$result" != "0" ]; then
-        echo "Failed to install Vela CLI"
-        echo "For support, go to https://kubevela.io"
-    fi
-    cleanup
-    exit $result
-}
-
-cleanup() {
-    if [[ -d "${VELA_TMP_ROOT:-}" ]]; then
-        rm -rf "$VELA_TMP_ROOT"
-    fi
-}
-
-installCompleted() {
-    echo -e "\nTo get started with KubeVela, please visit https://kubevela.io"
-}
-
-# -----------------------------------------------------------------------------
-# main
-# -----------------------------------------------------------------------------
-trap "fail_trap" EXIT
-
-getSystemInfo
-verifySupported
-checkExistingVela
-checkHttpRequestCLI
-
-
-if [ -z "$1" ]; then
-    echo "Getting the latest Vela CLI..."
-    getLatestRelease
-else
-    ret_val=v$1
-fi
-
-echo "Installing $ret_val Vela CLI..."
-
-downloadFile $ret_val
-installFile
-cleanup
-
-installCompleted

docs/sidebars.js

@@ -5,7 +5,6 @@ module.exports = {
       label: 'Overview',
       items: [
         'introduction',
-        'concepts',
       ],
     },
     {
@@ -14,27 +13,30 @@ module.exports = {
       items: [
         'install',
         'quick-start',
+        'concepts',
       ],
     },
     {
       type: 'category',
-      label: 'Rollout Features',
+      label: 'Define Application',
+      items:[
+        'platform-engineers/overview',
+        'application',
+      ]
+    },
+    {
+      type: 'category',
+      label: 'Rollout Application',
       items:[
         "rollout/rollout",
-        "rollout/appdeploy"
+        'rollout/appdeploy'
       ]
     },
     {
       type: 'category',
       label: 'Platform Builder Guide',
       items: [
-        {
-          'Design Abstraction': [
-            'platform-engineers/overview',
-            'application',
-            'platform-engineers/definition-and-templates',
-          ]
-        },
+        'platform-engineers/definition-and-templates',
         {
           'Visualization': [
             'platform-engineers/openapi-v3-json-schema'
@@ -63,27 +65,33 @@ module.exports = {
                   'kube/trait',
               ]
             },
-            {
-              'Defining Traits': [
-                  'cue/trait',
-                  'cue/patch-trait',
-                  'cue/status',
-                  'cue/advanced',
-              ]
-            },
-            {
-              'Defining Cloud Service': [
-                'platform-engineers/cloud-services',
-              ]
-            },
-            {
-              'Hands-on Lab': [
-                  'platform-engineers/debug-test-cue',
-                  'platform-engineers/keda'
-              ]
-            }
           ]
-        }
+        },
+        {
+          type: 'category',
+          label: 'Defining Traits',
+          items: [
+            'cue/trait',
+            'cue/patch-trait',
+            'cue/status',
+            'cue/advanced',
+          ]
+        },
+        {
+          type: 'category',
+          label: 'Defining Cloud Service',
+          items: [
+            'platform-engineers/cloud-services'
+          ]
+        },
+        {
+          type: 'category',
+          label: 'Hands-on Lab',
+          items: [
+            'platform-engineers/debug-test-cue',
+            'platform-engineers/keda'
+          ]
+        },
       ],
     },
     {

hack/crd/update.go

@@ -64,16 +64,6 @@ func fixNewSchemaValidationCheck(crds []string) error {
 			}
 			ioutil.WriteFile(crd, []byte(strings.Join(newData, "\n")), 0644)
 		}
-		// fix issue https://github.com/oam-dev/kubevela/issues/993
-		if strings.HasSuffix(crd, "legacy/charts/vela-core-legacy/crds/standard.oam.dev_routes.yaml") {
-			for _, line := range strings.Split(string(data), "\n") {
-				if strings.Contains(line, "default: Issuer") {
-					continue
-				}
-				newData = append(newData, line)
-			}
-			ioutil.WriteFile(crd, []byte(strings.Join(newData, "\n")), 0644)
-		}
 	}
 	return nil
 }

hack/vela-templates/definitions/ingress.yaml

@@ -20,6 +20,7 @@ spec:
   appliesToWorkloads:
     - webservice
     - worker
+  podDisruptive: false
   schematic:
     cue:
       template: |

hack/vela-templates/definitions/manualscale.yaml

@@ -12,6 +12,7 @@ spec:
   definitionRef:
     name: manualscalertraits.core.oam.dev
   workloadRefPath: spec.workloadRef
+  podDisruptive: true
   schematic:
     cue:
       template: |

hack/website/release.sh

@@ -0,0 +1,87 @@
+#!/bin/bash -l
+#
+# 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.
+#
+
+set -e
+
+if [[ -n "$SSH_DEPLOY_KEY" ]]
+then
+  mkdir -p ~/.ssh
+  echo "$SSH_DEPLOY_KEY" > ~/.ssh/id_rsa
+  chmod 600 ~/.ssh/id_rsa
+fi
+
+echo "git clone"
+git config --global user.email "yangsoonlx@gmail.com"
+git config --global user.name "kubevela-bot"
+git clone --single-branch --depth 1 git@github.com:oam-dev/kubevela.io.git git-page
+
+echo "sidebars updates"
+cat docs/sidebars.js > git-page/sidebars.js
+
+echo "clear en docs"
+rm -r git-page/docs/*
+#echo "clear zh docs"
+#rm -r git-page/i18n/zh/docusaurus-plugin-content-docs/*
+echo "clear resources"
+rm -r git-page/resources/*
+
+echo "update resources"
+cp -R docs/resources/* git-page/resources/
+
+echo "update docs"
+cp -R docs/en/* git-page/docs/
+#cp -R docs/zh-CN/* git-page/i18n/zh/docusaurus-plugin-content-docs/
+
+echo "git push"
+cd git-page
+
+# Check for release only
+SUB='release-'
+if [[ "$VERSION" == *"$SUB"* ]]
+then
+
+  # release-x.y -> vx.y
+  version=$(echo $VERSION|sed -e 's/\/*.*\/*-/v/g')
+  echo "updating website for version $version"
+
+  if grep -q $version versions.json; then
+    rm -r versioned_docs/version-${version}/
+    rm versioned_sidebars/version-${version}-sidebars.json
+    sed -i.bak "/${version}/d" versions.json
+    rm versions.json.bak
+  fi
+
+  yarn add nodejieba
+  if [ -e yarn.lock ]; then
+  yarn install --frozen-lockfile
+  elif [ -e package-lock.json ]; then
+  npm ci
+  else
+  npm i
+  fi
+
+  yarn run docusaurus docs:version $version
+fi
+
+if git diff --quiet
+then
+  echo "nothing need to push, finished!"
+else
+  git add .
+  git commit -m "sync commit $COMMIT_ID from kubevela-$VERSION"
+  git push origin main
+fi

hack/website/test-build.sh

@@ -1,4 +1,4 @@
-#!/bin/sh -l
+#!/bin/bash -l
 #
 # Copyright 2021. The KubeVela Authors.
 #
@@ -24,12 +24,6 @@ git clone --single-branch --depth 1 https://github.com/oam-dev/kubevela.io.git g
 echo "sidebars updates"
 cat ${docs_path}/sidebars.js > git-page/sidebars.js
 
-echo "docusaurus.config updates"
-cat ${docs_path}/docusaurus.config.js >  git-page/docusaurus.config.js
-
-echo "index info updates"
-cat ${docs_path}/index.js > git-page/src/pages/index.js
-
 echo "clear en docs"
 rm -r git-page/docs/*
 echo "clear zh docs"
@@ -58,4 +52,32 @@ npm i
 fi
 
 echo "run build"
-npm run build
+npm run build
+
+# Check for release only
+SUB='release-'
+if [[ "$VERSION" == *"$SUB"* ]]
+then
+
+  # release-x.y -> vx.y
+  version=$(echo $VERSION|sed -e 's/\/*.*\/*-/v/g')
+  echo "updating website for version $version"
+
+  if grep -q $version versions.json; then
+    rm -r versioned_docs/version-${version}/
+    rm versioned_sidebars/version-${version}-sidebars.json
+    sed -i.bak "/${version}/d" versions.json
+    rm versions.json.bak
+  fi
+
+  yarn add nodejieba
+  if [ -e yarn.lock ]; then
+  yarn install --frozen-lockfile
+  elif [ -e package-lock.json ]; then
+  npm ci
+  else
+  npm i
+  fi
+
+  yarn run docusaurus docs:version $version
+fi

legacy/charts/vela-core-legacy/crds/core.oam.dev_appdeployments.yaml

@@ -14,6 +14,8 @@ spec:
     kind: AppDeployment
     listKind: AppDeploymentList
     plural: appdeployments
+    shortNames:
+    - appdeploy
     singular: appdeployment
   scope: Namespaced
   subresources:

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

@@ -9,9 +9,13 @@ metadata:
 spec:
   group: core.oam.dev
   names:
+    categories:
+    - oam
     kind: ApplicationRevision
     listKind: ApplicationRevisionList
     plural: applicationrevisions
+    shortNames:
+    - apprev
     singular: applicationrevision
   scope: Namespaced
   validation:
@@ -402,8 +406,12 @@ spec:
                     rollingState:
                       description: RollingState is the Rollout State
                       type: string
+                    rolloutOriginalSize:
+                      description: RolloutTargetSize is the size of the target resources. This is determined once the initial spec verification and does not change until the rollout is restarted
+                      format: int32
+                      type: integer
                     rolloutTargetSize:
-                      description: RolloutTargetTotalSize is the size of the target resources. This is determined once the initial spec verification and does not change until the rollout is restarted
+                      description: RolloutTargetSize is the size of the target resources. This is determined once the initial spec verification and does not change until the rollout is restarted
                       format: int32
                       type: integer
                     services:
@@ -747,6 +755,9 @@ spec:
                         description: Extension is used for extension needs by OAM platform builders
                         type: object
                         
+                      podDisruptive:
+                        description: PodDisruptive specifies whether using the trait will cause the pod to restart or not.
+                        type: boolean
                       revisionEnabled:
                         description: Revision indicates whether a trait is aware of component revision
                         type: boolean

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

@@ -14,6 +14,8 @@ spec:
     kind: Application
     listKind: ApplicationList
     plural: applications
+    shortNames:
+    - app
     singular: application
   scope: Namespaced
   validation:
@@ -390,8 +392,12 @@ spec:
             rollingState:
               description: RollingState is the Rollout State
               type: string
+            rolloutOriginalSize:
+              description: RolloutTargetSize is the size of the target resources. This is determined once the initial spec verification and does not change until the rollout is restarted
+              format: int32
+              type: integer
             rolloutTargetSize:
-              description: RolloutTargetTotalSize is the size of the target resources. This is determined once the initial spec verification and does not change until the rollout is restarted
+              description: RolloutTargetSize is the size of the target resources. This is determined once the initial spec verification and does not change until the rollout is restarted
               format: int32
               type: integer
             services:

legacy/charts/vela-core-legacy/crds/core.oam.dev_approllouts.yaml

@@ -7,6 +7,25 @@ metadata:
     controller-gen.kubebuilder.io/version: v0.2.4
   name: approllouts.core.oam.dev
 spec:
+  additionalPrinterColumns:
+  - JSONPath: .status.rolloutTargetSize
+    name: TARGET
+    type: string
+  - JSONPath: .status.upgradedReplicas
+    name: UPGRADED
+    type: string
+  - JSONPath: .status.upgradedReadyReplicas
+    name: READY
+    type: string
+  - JSONPath: .status.batchRollingState
+    name: BATCH-STATE
+    type: string
+  - JSONPath: .status.rollingState
+    name: ROLLING-STATE
+    type: string
+  - JSONPath: .metadata.creationTimestamp
+    name: AGE
+    type: date
   group: core.oam.dev
   names:
     categories:
@@ -14,6 +33,8 @@ spec:
     kind: AppRollout
     listKind: AppRolloutList
     plural: approllouts
+    shortNames:
+    - approllout
     singular: approllout
   scope: Namespaced
   validation:
@@ -37,7 +58,7 @@ spec:
                 type: string
               type: array
             revertOnDelete:
-              description: RevertOnDelete revert the rollout when the rollout CR is deleted It will remove the target app from the kubernetes if it's set to true
+              description: RevertOnDelete revert the failed rollout when the rollout CR is deleted It will revert the change back to the source version at once (not in batches) Default is false
               type: boolean
             rolloutPlan:
               description: RolloutPlan is the details on how to rollout the resources
@@ -317,8 +338,12 @@ spec:
             rollingState:
               description: RollingState is the Rollout State
               type: string
+            rolloutOriginalSize:
+              description: RolloutTargetSize is the size of the target resources. This is determined once the initial spec verification and does not change until the rollout is restarted
+              format: int32
+              type: integer
             rolloutTargetSize:
-              description: RolloutTargetTotalSize is the size of the target resources. This is determined once the initial spec verification and does not change until the rollout is restarted
+              description: RolloutTargetSize is the size of the target resources. This is determined once the initial spec verification and does not change until the rollout is restarted
               format: int32
               type: integer
             targetGeneration:

legacy/charts/vela-core-legacy/crds/core.oam.dev_componentdefinitions.yaml

@@ -7,6 +7,16 @@ metadata:
     controller-gen.kubebuilder.io/version: v0.2.4
   name: componentdefinitions.core.oam.dev
 spec:
+  additionalPrinterColumns:
+  - JSONPath: .spec.workload.definition.kind
+    name: WORKLOAD-KIND
+    type: string
+  - JSONPath: .metadata.annotations.definition\.oam\.dev/description
+    name: DESCRIPTION
+    type: string
+  - JSONPath: .metadata.creationTimestamp
+    name: AGE
+    type: date
   group: core.oam.dev
   names:
     categories:
@@ -14,6 +24,8 @@ spec:
     kind: ComponentDefinition
     listKind: ComponentDefinitionList
     plural: componentdefinitions
+    shortNames:
+    - comp
     singular: componentdefinition
   scope: Namespaced
   subresources:

legacy/charts/vela-core-legacy/crds/core.oam.dev_resourcetrackers.yaml

@@ -14,8 +14,12 @@ spec:
     kind: ResourceTracker
     listKind: ResourceTrackerList
     plural: resourcetrackers
+    shortNames:
+    - tracker
     singular: resourcetracker
   scope: Cluster
+  subresources:
+    status: {}
   validation:
     openAPIV3Schema:
       description: An ResourceTracker represents a tracker for track cross namespace resources
@@ -28,6 +32,35 @@ spec:
           type: string
         metadata:
           type: object
+        status:
+          description: ResourceTrackerStatus define the status of resourceTracker
+          properties:
+            trackedResources:
+              items:
+                description: A TypedReference refers to an object by Name, Kind, and APIVersion. It is commonly used to reference across-namespace objects
+                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
+                  namespace:
+                    description: Namespace of the objects outside the application namespace.
+                    type: string
+                  uid:
+                    description: UID of the referenced object.
+                    type: string
+                required:
+                - apiVersion
+                - kind
+                - name
+                type: object
+              type: array
+          type: object
       type: object
   version: v1beta1
   versions:

legacy/charts/vela-core-legacy/crds/core.oam.dev_scopedefinitions.yaml

@@ -18,6 +18,8 @@ spec:
     kind: ScopeDefinition
     listKind: ScopeDefinitionList
     plural: scopedefinitions
+    shortNames:
+    - scope
     singular: scopedefinition
   scope: Namespaced
   subresources: {}