Merge pull request #546 from zzxwill/issue-autoscaler

Fix autoscale inconsistence UI

Makefile

@@ -38,8 +38,8 @@ npm-build:
 npm-install:
 	cd dashboard && npm install && cd ./..
 
-generate-doc:
-	rm -r docs/cli/*
+doc-gen:
+	rm -r docs/en/cli/*
 	go run hack/docgen/gen.go
 
 generate-source:

README.md

@@ -11,18 +11,18 @@ For platform builders, KubeVela serves as a framework that empowers them to crea
 - Slack: [Discuss](https://cloud-native.slack.com/archives/C01BLQ3HTJA)
 - Gitter: [Community](https://gitter.im/oam-dev/community)
 
+> NOTE: KubeVela is still in early stage and iterating quickly. It's currently under preview release.
+
 ## Quick Start
 
 Quick start guides are available on [this section](docs/quick-start.md).
 
 ## Documentation
 
-Full documentation is available on the [documentation section](docs/README.md).
+To see full documentation, visit [kubevela.io](https://kubevela.io/).
 
 ## Contributing
 Check out [CONTRIBUTING](./CONTRIBUTING.md) to see how to develop with KubeVela.
 
 ## Code of Conduct
 This project has adopted the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md). See [CODE OF CONDUCT](CODE_OF_CONDUCT.md) for details.
-
-> NOTE: KubeVela is an early project and iterating quickly to continue to make it easier to ship applications and build platforms atop. It's still under preview release for now.

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

@@ -0,0 +1,50 @@
+apiVersion: core.oam.dev/v1alpha2
+kind: TraitDefinition
+metadata:
+  name: rollout
+spec:
+  appliesToWorkloads:
+    - podspecworkload.standard.oam.dev
+    - deployments.apps
+  definitionRef:
+    name: canaries.flagger.app
+  workloadRefPath: spec.targetRef
+  revisionEnabled: true
+  extension:
+    template: |-
+      output: {
+      	apiVersion: "flagger.app/v1beta1"
+      	kind:       "Canary"
+      	spec: {
+      		provider:                "smi"
+      		progressDeadlineSeconds: 60
+      		service: {
+      			// Currently Traffic route is not supported, but this is required field for flagger CRD
+      			port: 80
+      			// Currently Traffic route is not supported, but this is required field for flagger CRD
+      			targetPort: 8080
+      		}
+      		analysis: {
+      			interval: parameter.interval
+      			// max number of failed metric checks before rollback
+      			threshold: 10
+      			// max traffic percentage routed to canary
+      			// percentage (0-100)
+      			maxWeight: 50
+      			// canary increment step
+      			// percentage (0-100)
+      			stepWeight: parameter.stepWeight
+      			// max replicas scale up to canary
+      			maxReplicas: parameter.replica
+      		}
+      	}
+      }
+      parameter: {
+      	// +usage=total replica of the workload
+      	replica: *5 | int
+      	// +alias=step-weight
+      	// +usage=weight percent of every step in rolling update
+      	stepWeight: *20 | int
+      	interval:   *"30s" | string
+      }
+      

charts/vela-core/templates/velaConfig.yaml

@@ -14,11 +14,11 @@ data:
     }
   flagger.app: |
     {
-      "repo": "flagger",
-      "urL": "https://flagger.app",
+      "repo": "oam-flagger",
+      "urL": "https://oam.dev/flagger/archives/",
       "name": "flagger",
       "namespace": "vela-system",
-      "version": "1.2.0"
+      "version": "1.1.0"
     }
   keda: |
     {
@@ -27,4 +27,4 @@ data:
       "name": "keda",
       "namespace": "keda",
       "version": "2.0.0-rc3"
-    }
+    }

design/vela-core/appfile-design.md

@@ -72,7 +72,7 @@ It will build container image, render deployment manifests in yaml, and apply th
 
 ### Extensible Design
 
-The Appfile could be extended with more configurations by adding more capabilities to the OAM system. The config fields in Appfile are strongly correlated to the [capabilities system of OAM](https://github.com/oam-dev/kubevela/blob/master/DESIGN.md#capability-register-and-discovery) – Config fields are registered in the capabilities system and exposed via a [CUE template](https://cuelang.org/).
+The Appfile could be extended with more configurations by adding more capabilities to the OAM system. The config fields in Appfile are strongly correlated to the [capabilities system of OAM](https://github.com/oam-dev/kubevela/blob/master/docs/design.md#2-capability-oriented-architecture) – Config fields are registered in the capabilities system and exposed via a [CUE template](https://cuelang.org/).
 
 Here is an example of a capability definition that platform builders register:
 
@@ -140,7 +140,7 @@ In the following, we will discuss technical details of the proposed design.
 
 ### Registration via Definition/Capability
 
-Vela allows platform builders to extend Appfile config fields by registering them via [capabilities system of OAM](https://github.com/oam-dev/kubevela/blob/master/DESIGN.md#capability-register-and-discovery).
+Vela allows platform builders to extend Appfile config fields by registering them via [capabilities system of OAM](https://github.com/oam-dev/kubevela/blob/master/docs/design.md#2-capability-oriented-architecture).
 
 The entire template should be put under `spec.extension.template` as raw string:
 
@@ -356,4 +356,4 @@ spec:
           }]
         }
       }
-```
+```

docs/CNAME

@@ -0,0 +1 @@
+kubevela.io

docs/README.md

@@ -1,34 +1,31 @@
-# KubeVela Documentation
+# KubeVela Website
+[kubevela.io](https://kubevela.io)
 
-Learn and use KubeVela with tutorials and user stories.
+## Contributing
 
-**Overview**
-- [Introduction](introduction.md)
-- [Installation](./install.md)
-- [Quick Start](quick-start.md)
-- [Concepts](concepts.md)
+- Fork and clone
 
-**For Developers**
-- [Setting Up Deployment Environment](developers/config-enviroments.md)
-- [Initializing Application](developers/app-init.md)
-- [Setting Routes](developers/set-route.md)
-- [Setting Auto-scaling Policy](developers/set-autoscale.md)
-- [Setting Rollout Strategy](developers/set-rollout.md)
-- [Monitoring Application](developers/set-metrics.md)
-- [Using Appfile](developers/devex/appfile.md)
-- [Check Application Logs](developers/check-logs.md)
-- [Execute Commands in Container](developers/exec-cmd.md)
-- [Port Forward to Container](developers/port-forward.md)
-- [Configuring data/env in Application](developers/config-app.md)
-- [Consuming Cloud Services](developers/cloud-service.md)
-- [Managing Capabilities](developers/cap-center.md)
-- [Capability References](developers/references/README.md)
+  ```
+  $ git clone git@github.com:oam-dev/kubevela.git
+  $ cd kubevela/docs
+  ```
 
-**For Platform Engineers**
-- [Extending KubeVela](platform-engineers/extending-kubevela.md)
+- Install docsify-cli
+  ```
+  $ npm i docsify-cli -g
+  ```
 
-**Internals**
-- [Design and Architecture](design.md)
+- Make your changes
 
-**Roadmap**
-- [Roadmap of KubeVela](roadmap.md)
+- Local preview
+  ```
+  $ docsify serve
+  Serving /xxx/kubevela.io now.
+  Listening at http://localhost:3000
+  ```
+
+  Preview your changes at [http://127.0.0.1:3000/](http://127.0.0.1:3000/).
+
+- Push your commit
+
+  Thanks for your contribution!

docs/_coverpage.md

@@ -0,0 +1,9 @@
+<p align="center">
+ <img src="static/logo.svg" alt="kubevela logo" width=300 height=300 />
+</p>
+
+> Make shipping applications more enjoyable.
+
+
+[GitHub](https://github.com/oam-dev/kubevela)
+[Get Started](en/quick-start)

docs/_navbar.md

@@ -0,0 +1,5 @@
+- [Home](/)
+<!-- - [Blog](/en/blog/README.md) -->
+<!-- - Language
+  - [中文](/zh-cn/)
+  - [English](/en/) -->

docs/_sidebar.md

@@ -0,0 +1,64 @@
+- Overview
+  - [Introduction](/en/introduction.md)
+  - [Installation](/en/install.md)
+  - [Quick Start](/en/quick-start.md)
+  - [Concepts](/en/concepts.md)
+
+- For Developers
+  - [Setting Up Deployment Environment](/en/developers/config-enviroments.md)
+  - [Initializing Application](/en/developers/app-init.md)
+  - [Setting Routes](/en/developers/set-route.md)
+  - [Setting Auto-scaling Policy](/en/developers/set-autoscale.md)
+  - [Setting Rollout Strategy](/en/developers/set-rollout.md)
+  - [Monitoring Application](/en/developers/set-metrics.md)
+  - [Using Appfile](/en/developers/devex/appfile.md)
+  - [Check Application Logs](/en/developers/check-logs.md)
+  - [Execute Commands in Container](/en/developers/exec-cmd.md)
+  - [Port Forward to Container](/en/developers/port-forward.md)
+  - [Configuring data/env in Application](/en/developers/config-app.md)
+  - [Consuming Cloud Services](/en/developers/cloud-service.md)
+  - [Managing Capabilities](/en/developers/cap-center.md)
+  - [Capability References](/en/developers/references/README.md)
+
+- For Platform Engineers
+  - [Extending KubeVela](/en/platform-engineers/extending-kubevela.md)
+
+- Internals
+  - [Design and Architecture](/en/design.md)
+
+- Roadmap
+  - [KubeVela Roadmap](/en/roadmap.md)
+
+- CLI Reference
+  - General
+    - [vela config](/en/cli/vela_config.md)
+    - [vela env](/en/cli/vela_env.md)
+    - [vela init](/en/cli/vela_init.md)
+    - [vela install](/en/cli/vela_install.md)
+    - [vela up](/en/cli/vela_up.md)
+    - [vela version](/en/cli/vela_version.md)
+  - Applications
+    - [vela delete](/en/cli/vela_delete.md)
+    - [vela exec](/en/cli/vela_exec.md)
+    - [vela logs](/en/cli/vela_logs.md)
+    - [vela ls](/en/cli/vela_ls.md)
+    - [vela port-forward](/en/cli/vela_port-forward.md)
+    - [vela show](/en/cli/vela_show.md)
+    - [vela status](/en/cli/vela_status.md)
+    - [vela svc](/en/cli/vela_svc.md)
+  - Workload Types
+    - [vela workloads](/en/cli/vela_workloads.md)
+  - Traits
+    - [vela traits](/en/cli/vela_traits.md)
+    - [vela scaler](/en/cli/vela_scaler.md)
+    - [vela route](/en/cli/vela_route.md)
+    - [vela autoscale](/en/cli/vela_autoscale.md)
+    - [vela rollout](/en/cli/vela_rollout.md)
+    - [vela metric](/en/cli/vela_metric.md)
+  - System
+    - [vela completion](/en/cli/vela_completion.md)
+    - [vela dashboard](/en/cli/vela_dashboard.md)
+    - [vela system](/en/cli/vela_system.md)
+    - [vela template](/en/cli/vela_template.md)
+  - Extensibility
+    - [vela cap](/en/cli/vela_cap.md)

docs/cli/vela_system_update.md

@@ -1,35 +0,0 @@
-## vela system update
-
-Sync definition from cluster
-
-### Synopsis
-
-Refresh and sync definition files from cluster
-
-```
-vela system update
-```
-
-### Examples
-
-```
-vela system update
-```
-
-### Options
-
-```
-  -h, --help   help for update
-```
-
-### Options inherited from parent commands
-
-```
-  -e, --env string   specify environment name for application
-```
-
-### SEE ALSO
-
-* [vela system](vela_system.md)	 - System management utilities
-
-###### Auto generated by spf13/cobra on 6-Nov-2020

docs/design.md

@@ -1,159 +0,0 @@
-# KubeVela Design
-
-This document is the detailed design and architecture of the KubeVela being built in this repository.
-
-> All the diagram in this documentation could be found in [this slides](https://docs.google.com/presentation/d/1Y3gnKrd7fUZGgee7Ia9vBsRIYhcZLQwMUCDkk1RJvQc/edit?usp=sharing).
-
-## Overview
-
-KubeVela is a simple, complete, but highly extensible cloud native application platform based on Kubernetes. KubeVela intends to bring application-centric experience to end users and democratize building cloud native application platforms for platform engineers.
-
-## User Stories
-
-As a end user (e.g. application developers, operators etc) of the platform, I only want to focus on coding my business logic and ship them to various environments at ease. Let's say:
-- Here's my source code.
-- Here's my application configuration (described in end user PoV).
-- Deploy it in test environment.
-- Deploy it in production environment.
-- Monitoring, debugging, rollout/rollback the application.
-- Dockerfile is fine, but please keep it simple. 
-
-As a platform engineer, I want to build a easy-to-use platform for end users. In detail, the platform should be:
-- Heroku-like (_in terms of both user experience and functionality_). 
-  - and I prefer to build my own version with OSS tools, particularly, with Kubernetes (for obvious reason).
-- Easy to build. 
-  - I am too busy to reinvent any wheel, I want to reuse every capability in Kubernetes community as possible,  with minimal effort. Writing some simple CRD and controllers is fine, but please, just the simple ones like copy-paste.
-- Powerful and highly extensible.
-  - I don't want to lock users with restricted abstractions and capabilities like traditional PaaS or FaaS/Serverless. I love Kubernetes and what it has enabled. So in terms of capability, I hope my platform is fully open and has unlimited possibilities like Kubernetes itself, rather than another opinionated close system like traditional PaaS.
-
-
-## Core Principles
-
-In nutshell, the principles for KubeVela project are:
-
-- For end users, it out-of-the-box provides a fully featured PaaS-like experience, nothing special.
-- For platform builders, it works like a special Kubernetes "distro" or extensible PaaS core that could be used to build something more complex on top of. It allows platform builders to integrate any existing capabilities in Kubernetes ecosystem to end users with minimal effort, or develop a new capability at ease in a standardized and Kubernetes-native approach.
-
-## Design Details
-
-### 1. Application Centric
-
-The API and interfaces of KubeVela intends to make users think in terms of application, not containers or infrastructure. 
-
-Lacking application context impacts the user experience and significantly raised the bar to adopt cloud native stack. We believe "application" is the natural mindset of developers and it's the core concept an application platform should expose.
-
-![alt](../resources/app-centric.png)
-
-KubeVela intends to let developers push code, define application in developer facing primitives, and make daily operations as configurations of the application.  
-
-Thus, KubeVela choose to:
-1. Introduce "application" as first class citizen and main API.
-2. Build the whole system around "application", i.e. model capabilities of Kubernetes as application configuration, with clarity and manageability.
-
-#### Solution
-
-Instead of creating a in-house "application CRD", KubeVela adopts [Open Application Model (OAM)](https://github.com/oam-dev/spec) as its application definition, since OAM:
-1. defines micro-services application by default.
-2. models day 2 operations as part of the application (i.e. `Application Traits`).
-2. is highly extensible: every workload and trait in OAM is a independent definition, no abstraction or capability lock-in.
-
-### 2. Capability Oriented Architecture
-
-To enable platform builders use KubeVela to create their own application platforms in an easy and Kubernetes native approach, KubeVela intends to make its every capability a standalone "plug-in".
-
-![alt](../resources/coa.png)
-
-For example, there are several "built-in" workload types in KubeVela such as `Web Service` or `Task`. It is by design that they are all independent CRD controllers that abstract Kubernetes built-in workloads and create Service automatically if needed. KubeVela itself is **NOT** aware of the specification or implementation of these workload types.
-
-This means platform builders are free to bring their own workload types by simply install a CRD controller, or even just reference a k8s built-in resource like StatefulSet as new workload type.
-
-Similarly, all the "built-in" operations such as `scaling` or `rollout` (i.e. "traits" in KubeVela) are also independent CRD controllers which are **NOT** bound with specific workload types. Platform builders are free to bring their own traits implementations by simply providing a CRD controller, reference a k8s built-in resource like `HPA` or `NetworkPolicy` as trait is also possible.
-
-This loosely coupled design of KubeVela adopts the idea of Capability Oriented Architecture (COA), i.e. instead of creating a close system like traditional PaaS, KubeVela intends to become an application-centric framework to connect end users with underlying infrastructure capabilities.
-
-#### Solution
-
-KubeVela core is built with [OAM Kubernetes Runtime](https://github.com/crossplane/oam-kubernetes-runtime) which met the requirements of KubeVela such as supporting bring in standalone controllers as workload type and trait, it also defined a clear interface between how a trait could operate a workload instance in a generic approach. Overall, this library defined a set of abstraction and interfaces for platform builder to assemble various Kubernetes capabilities into a PaaS without coupling them together or introducing any glue code.  
-
-##### Capability Register and Discovery
-
-KubeVela leverages [OAM definition objects](https://github.com/oam-dev/spec/blob/master/4.workload_definitions.md) to register and discover workloads and traits:
-
-
-```console
-$ kubectl apply -f workload-definition.yaml # register a new workload type
-$ kubectl apply -f trait-definition.yaml # register a new trait
-```
-
-Note that OAM definition objects only care about API resource, not including the controllers. Thus KubeVela intends to include a **CRD registry** so whenever a new API resource is installed as workload or trait, KubeVela could install its controller automatically from the registry. That of course means we envision the CRD registry could register a CRD and Helm chart (which contains the manifest of the controller). In practice, we are currently evaluating RedHat's Operator Lifecycle Manager (OLM) but no the final conclusion yet.
-
-##### Cloud Services Integration
-
-For capabilities like cloud services, KubeVela intends to leverage Kubernetes as the universal control plane so [Crossplane](https://github.com/crossplane/crossplane) core will be used to register cloud services as workload types.
-
-
-### 3. Extensible User Interface
-
-KubeVela is built with Kubernetes and OAM (which adopts Kubernetes API model). So in nutshell, **ALL** functionalities of KubeVela core can be handled by simple `kubectl`, for example:
-
-```yaml
-$ kubectl apply -f frontend-component.yaml # create frontend component
-$ kubectl apply -f backend-component.yaml # create backend component
-$ kubectl apply -f application-config.yaml # assign operational traits to components and deploy the whole application
-```
-
-We call these server side objects "the application model of KubeVela", they are essentially the Kubernetes API objects KubeVela exposes.
-
-However, we also agree that Kubernetes API model is great to build platforms like KubeVela with but when directly exposed to end users, it creates heavy mental burden and high learning curve. Hence, as any other user facing platforms, KubeVela intend to introduce a lightweight user facing layer with following goals in mind:
-
-- Shorten the learning curve of new developers. Most capabilities in KubeVela are developed by big
-companies that run very complex workloads. However, for the bigger developer community, the new user facing layer will provide a much simpler path to on-board KubeVela.
-- Developers can describe their applications and behavior of their components without making assumptions on availability of specific Kubernetes API. For instance, a developer will be able to model auto-scaling needs without referring to the CRD of auto-scaling trait.
-- Provides a single source of truth of the application description. The user facing layer allows developers to work with a single artifact to capture the application definition. This artifact is the definitive truth of how the application is supposed to look like. It simplifies administrative tasks such as change management. It also serves as an anchor for application truth to avoid configuration drifts during operation.
-- Highly extensible. For example, when a new workload type or trait is installed, the end users could access this new capability directly from user interface layer, no re-compile or re-deploy of KubeVela is required.
-
-#### Solution
-
-We concluded such "highly extensible user interface layer" as a need for a dynamic "modeling language" on top of the KubeVela's application model objects. After evaluation, we decided to adopt [CUElang](https://github.com/cuelang/cue) since it's perfect as a pure data configuration language that allow us to build developer facing tools, nothing more, nothing less.
-
-In detail, we integrated CUE based abstraction as part of OAM implementation since the *abstraction* and *model* are closely related. For platform builders, every workload or trait definition in KubeVela references a CUE template as its abstraction between human and the underlying Kubernetes capability, platform builders are free to modify those templates at any time
-
-On the other hand, it's by intention that the end users of KubeVela don't need to learn or write CUE. Instead, we created following tools for them by leveraging above OAM + CUE user interface layer:
-
-1. A command line tool.
-2. A GUI dashboard.
-3. A Docker Compose style `appfile`.
-
-For example, the `vela cli`:
-
-```console
-$ vela svc deploy frontend -t webservice --image oamdev/testapp:v1 --port 80 --app helloworld
-```
-
-The `-t webservice --image oamdev/testapp:v1 --port 80` arguments are not hard coded, they are schema defined by in-line CUE template of `WebService` workload definition.
-
-The `appfile` is essentially a YAML version of command line tool but it can support more complex structures with a single command like `$ vela up`:
-
-![alt](../resources/appfile.png)
-
-The schema of above `appfile` is not hard coded as well, they are organized following OAM and enforced by CUE templates of `WebService` workload definition, `Scaling` trait definition and `Canary` trait definition.
-
-> Appfile has its [independent design doc](./design/appfile-design.md) which includes more details. There's also [an example](./design/appfile-design.md#multiple-outputs-in-traitdefinition) showing how platform builder could use CUE to define a `route` capability in KubeVela.
-
-We will skip the example of dashboard, but similarly, the schema of GUI forms are defined by in-lined CUE template of definition objects.
-
-## Architecture
-
-![alt](../resources/arch.png)
-
-From highest level, KubeVela is composed by only two components:
-
-### 1. User interface layer
-Including: `cli`, `dashboard`, `appfile`, they are all client side tools based on the CUE based abstractions mentioned above.
-### 2. KubeVela core
-Including:
-  - [OAM Kubernetes runtime](https://github.com/crossplane/oam-kubernetes-runtime) to provide application-centric building blocks such as `Component` and `Application` etc.
-  - [Built-in workload and trait controllers](https://github.com/oam-dev/kubevela/tree/master/pkg/controller/v1alpha1) to provide core capabilities such as `webservice`, `route` and `rollout` etc.
-  - Capability Management: manage features of KubeVela following Capability Oriented Architecture. 
-    - Every feature of KubeVela is a "addon", and it is registered by Kubernetes API resource (including CRD) leveraging OAM definition objects.
-    - CRD Registry: register controllers of Kubernetes add-ons and discover them by CRD. This will enable automatically install controllers/operators when CRD is missing in the cluster.

docs/developers/set-rollout.md

@@ -1,3 +0,0 @@
-# Setting Rollout Strategy
-
-> TODO

docs/en/README.md

@@ -0,0 +1,25 @@
+![alt](resources/KubeVela-03.png)
+
+*Make shipping applications more enjoyable.*
+
+# KubeVela
+
+For developers, KubeVela is an easy-to-use tool that enables them to describe and ship their applications to Kubernetes with minimal effort.
+
+For platform builders, KubeVela serves as a framework that empowers them to create developer facing yet highly extensible platforms at ease.
+
+- Slack: [Discuss](https://cloud-native.slack.com/archives/C01BLQ3HTJA)
+- Gitter: [Community](https://gitter.im/oam-dev/community)
+
+> NOTE: KubeVela is still in early stage and iterating quickly. It's currently under preview release.
+
+## Quick Start
+
+Quick start guides are available on [this section](/en/quick-start).
+
+
+## Contributing
+Check out [CONTRIBUTING](https://github.com/oam-dev/kubevela/blob/master/CONTRIBUTING.md) to see how to develop with KubeVela.
+
+## Code of Conduct
+This project has adopted the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md). See [CODE OF CONDUCT](CODE_OF_CONDUCT.md) for details.

docs/en/blog/README.md

@@ -0,0 +1 @@
+## Some blog

docs/en/blog/_sidebar.md

@@ -0,0 +1 @@
+- [Blog](/en/blog/README.md)

docs/en/cli/vela.md

@@ -33,6 +33,7 @@ vela [flags]
 * [vela ls](vela_ls.md)	 - List services
 * [vela metric](vela_metric.md)	 - Attach metric trait to an app
 * [vela port-forward](vela_port-forward.md)	 - Forward one or more local ports to a Pod of a service in an application
+* [vela rollout](vela_rollout.md)	 - Attach rollout trait to an app
 * [vela route](vela_route.md)	 - Attach route trait to an app
 * [vela scaler](vela_scaler.md)	 - Attach scaler trait to an app
 * [vela show](vela_show.md)	 - Get details of an application
@@ -45,4 +46,4 @@ vela [flags]
 * [vela version](vela_version.md)	 - Prints out build version information
 * [vela workloads](vela_workloads.md)	 - List workloads
 
-###### Auto generated by spf13/cobra on 6-Nov-2020
+###### Auto generated by spf13/cobra on 10-Nov-2020

docs/en/cli/vela_autoscale.md

@@ -44,4 +44,4 @@ vela autoscale frontend
 
 * [vela](vela.md)	 - 
 
-###### Auto generated by spf13/cobra on 6-Nov-2020
+###### Auto generated by spf13/cobra on 10-Nov-2020

docs/en/cli/vela_cap.md

@@ -26,4 +26,4 @@ Capability Management with config, list, add, remove capabilities
 * [vela cap ls](vela_cap_ls.md)	 - List capabilities from cap-center
 * [vela cap uninstall](vela_cap_uninstall.md)	 - Uninstall capability from cluster
 
-###### Auto generated by spf13/cobra on 6-Nov-2020
+###### Auto generated by spf13/cobra on 10-Nov-2020

docs/en/cli/vela_cap_center.md

@@ -26,4 +26,4 @@ Manage Capability Center with config, sync, list
 * [vela cap center remove](vela_cap_center_remove.md)	 - Remove specified capability center
 * [vela cap center sync](vela_cap_center_sync.md)	 - Sync capabilities from remote center, default to sync all centers
 
-###### Auto generated by spf13/cobra on 6-Nov-2020
+###### Auto generated by spf13/cobra on 10-Nov-2020

docs/en/cli/vela_cap_center_config.md

@@ -33,4 +33,4 @@ vela cap center config mycenter https://github.com/oam-dev/catalog/cap-center
 
 * [vela cap center](vela_cap_center.md)	 - Manage Capability Center
 
-###### Auto generated by spf13/cobra on 6-Nov-2020
+###### Auto generated by spf13/cobra on 10-Nov-2020

docs/en/cli/vela_cap_center_ls.md

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

docs/en/cli/vela_cap_center_remove.md

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

docs/en/cli/vela_cap_center_sync.md

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

docs/en/cli/vela_cap_install.md

@@ -33,4 +33,4 @@ vela cap install mycenter/route
 
 * [vela cap](vela_cap.md)	 - Capability Management
 
-###### Auto generated by spf13/cobra on 6-Nov-2020
+###### Auto generated by spf13/cobra on 10-Nov-2020

docs/en/cli/vela_cap_ls.md

@@ -32,4 +32,4 @@ vela cap ls
 
 * [vela cap](vela_cap.md)	 - Capability Management
 
-###### Auto generated by spf13/cobra on 6-Nov-2020
+###### Auto generated by spf13/cobra on 10-Nov-2020

docs/en/cli/vela_cap_uninstall.md

@@ -33,4 +33,4 @@ vela cap uninstall route
 
 * [vela cap](vela_cap.md)	 - Capability Management
 
-###### Auto generated by spf13/cobra on 6-Nov-2020
+###### Auto generated by spf13/cobra on 10-Nov-2020

docs/en/cli/vela_completion.md

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

docs/en/cli/vela_completion_bash.md

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

docs/en/cli/vela_completion_zsh.md

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

docs/en/cli/vela_config.md

@@ -26,4 +26,4 @@ Manage application configurations under given env
 * [vela config ls](vela_config_ls.md)	 - List configs
 * [vela config set](vela_config_set.md)	 - Set data for a config
 
-###### Auto generated by spf13/cobra on 6-Nov-2020
+###### Auto generated by spf13/cobra on 10-Nov-2020

docs/en/cli/vela_config_del.md

@@ -32,4 +32,4 @@ vela config del <config-name>
 
 * [vela config](vela_config.md)	 - Manage application configurations
 
-###### Auto generated by spf13/cobra on 6-Nov-2020
+###### Auto generated by spf13/cobra on 10-Nov-2020

docs/en/cli/vela_config_get.md

@@ -32,4 +32,4 @@ vela config get <config-name>
 
 * [vela config](vela_config.md)	 - Manage application configurations
 
-###### Auto generated by spf13/cobra on 6-Nov-2020
+###### Auto generated by spf13/cobra on 10-Nov-2020

docs/en/cli/vela_config_ls.md

@@ -32,4 +32,4 @@ vela config ls
 
 * [vela config](vela_config.md)	 - Manage application configurations
 
-###### Auto generated by spf13/cobra on 6-Nov-2020
+###### Auto generated by spf13/cobra on 10-Nov-2020

docs/en/cli/vela_config_set.md

@@ -32,4 +32,4 @@ vela config set <config-name> KEY=VALUE K2=V2
 
 * [vela config](vela_config.md)	 - Manage application configurations
 
-###### Auto generated by spf13/cobra on 6-Nov-2020
+###### Auto generated by spf13/cobra on 10-Nov-2020

docs/en/cli/vela_dashboard.md

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

docs/en/cli/vela_delete.md

@@ -33,4 +33,4 @@ vela delete frontend
 
 * [vela](vela.md)	 - 
 
-###### Auto generated by spf13/cobra on 6-Nov-2020
+###### Auto generated by spf13/cobra on 10-Nov-2020

docs/en/cli/vela_env.md

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

docs/en/cli/vela_env_delete.md

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

docs/en/cli/vela_env_init.md

@@ -23,6 +23,7 @@ vela env init test --namespace test --email my@email.com
       --email string       specify email for production TLS Certificate notification
   -h, --help               help for init
       --namespace string   specify K8s namespace for env
+  -s, --sync               synchronize capabilities from cluster into local (default true)
 ```
 
 ### Options inherited from parent commands
@@ -35,4 +36,4 @@ vela env init test --namespace test --email my@email.com
 
 * [vela env](vela_env.md)	 - Manage application environments
 
-###### Auto generated by spf13/cobra on 6-Nov-2020
+###### Auto generated by spf13/cobra on 10-Nov-2020

docs/en/cli/vela_env_ls.md

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

docs/en/cli/vela_env_set.md

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

docs/en/cli/vela_exec.md

@@ -29,4 +29,4 @@ vela exec [flags] AppName -- COMMAND [args...]
 
 * [vela](vela.md)	 - 
 
-###### Auto generated by spf13/cobra on 6-Nov-2020
+###### Auto generated by spf13/cobra on 10-Nov-2020

docs/en/cli/vela_init.md

@@ -33,4 +33,4 @@ vela init
 
 * [vela](vela.md)	 - 
 
-###### Auto generated by spf13/cobra on 6-Nov-2020
+###### Auto generated by spf13/cobra on 10-Nov-2020

docs/en/cli/vela_install.md

@@ -31,4 +31,4 @@ vela install [flags]
 
 * [vela](vela.md)	 - 
 
-###### Auto generated by spf13/cobra on 6-Nov-2020
+###### Auto generated by spf13/cobra on 10-Nov-2020

docs/en/cli/vela_logs.md

@@ -27,4 +27,4 @@ vela logs [flags]
 
 * [vela](vela.md)	 - 
 
-###### Auto generated by spf13/cobra on 6-Nov-2020
+###### Auto generated by spf13/cobra on 10-Nov-2020

docs/en/cli/vela_ls.md

@@ -33,4 +33,4 @@ vela ls
 
 * [vela](vela.md)	 - 
 
-###### Auto generated by spf13/cobra on 6-Nov-2020
+###### Auto generated by spf13/cobra on 10-Nov-2020

docs/en/cli/vela_metric.md

@@ -40,4 +40,4 @@ vela metric frontend
 
 * [vela](vela.md)	 - 
 
-###### Auto generated by spf13/cobra on 6-Nov-2020
+###### Auto generated by spf13/cobra on 10-Nov-2020

docs/en/cli/vela_port-forward.md

@@ -28,4 +28,4 @@ vela port-forward APP_NAME [options] [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:
 
 * [vela](vela.md)	 - 
 
-###### Auto generated by spf13/cobra on 6-Nov-2020
+###### Auto generated by spf13/cobra on 10-Nov-2020

docs/en/cli/vela_rollout.md

@@ -0,0 +1,41 @@
+## vela rollout
+
+Attach rollout trait to an app
+
+### Synopsis
+
+Attach rollout trait to an app
+
+```
+vela rollout <appname> [args]
+```
+
+### Examples
+
+```
+vela rollout frontend
+```
+
+### Options
+
+```
+      --detach            detach trait from service
+  -h, --help              help for rollout
+      --interval string    (default "30s")
+      --replica int       total replica of the workload (default 5)
+  -s, --staging           only save changes locally without real update application
+      --step-weight int   weight percent of every step in rolling update (default 20)
+      --svc string        specify one service belonging to the application
+```
+
+### Options inherited from parent commands
+
+```
+  -e, --env string   specify environment name for application
+```
+
+### SEE ALSO
+
+* [vela](vela.md)	 - 
+
+###### Auto generated by spf13/cobra on 10-Nov-2020

docs/en/cli/vela_route.md

@@ -37,4 +37,4 @@ vela route frontend
 
 * [vela](vela.md)	 - 
 
-###### Auto generated by spf13/cobra on 6-Nov-2020
+###### Auto generated by spf13/cobra on 10-Nov-2020

docs/en/cli/vela_scaler.md

@@ -36,4 +36,4 @@ vela scaler frontend
 
 * [vela](vela.md)	 - 
 
-###### Auto generated by spf13/cobra on 6-Nov-2020
+###### Auto generated by spf13/cobra on 10-Nov-2020

docs/en/cli/vela_show.md

@@ -33,4 +33,4 @@ vela show <APPLICATION-NAME>
 
 * [vela](vela.md)	 - 
 
-###### Auto generated by spf13/cobra on 6-Nov-2020
+###### Auto generated by spf13/cobra on 10-Nov-2020

docs/en/cli/vela_status.md

@@ -33,4 +33,4 @@ vela status <APPLICATION-NAME>
 
 * [vela](vela.md)	 - 
 
-###### Auto generated by spf13/cobra on 6-Nov-2020
+###### Auto generated by spf13/cobra on 10-Nov-2020

docs/en/cli/vela_svc.md

@@ -24,4 +24,4 @@ Manage services
 * [vela](vela.md)	 - 
 * [vela svc deploy](vela_svc_deploy.md)	 - Initialize and run a service
 
-###### Auto generated by spf13/cobra on 6-Nov-2020
+###### Auto generated by spf13/cobra on 10-Nov-2020

docs/en/cli/vela_svc_deploy.md

@@ -35,4 +35,4 @@ vela svc deploy -t <SERVICE_TYPE>
 
 * [vela svc](vela_svc.md)	 - Manage services
 
-###### Auto generated by spf13/cobra on 6-Nov-2020
+###### Auto generated by spf13/cobra on 10-Nov-2020

docs/en/cli/vela_system.md

@@ -22,6 +22,5 @@ System management utilities
 
 * [vela](vela.md)	 - 
 * [vela system info](vela_system_info.md)	 - Show vela client and cluster chartPath
-* [vela system update](vela_system_update.md)	 - Sync definition from cluster
 
-###### Auto generated by spf13/cobra on 6-Nov-2020
+###### Auto generated by spf13/cobra on 10-Nov-2020

docs/en/cli/vela_system_info.md

@@ -26,4 +26,4 @@ vela system info [flags]
 
 * [vela system](vela_system.md)	 - System management utilities
 
-###### Auto generated by spf13/cobra on 6-Nov-2020
+###### Auto generated by spf13/cobra on 10-Nov-2020

docs/en/cli/vela_template.md

@@ -23,4 +23,4 @@ Manage templates
 * [vela](vela.md)	 - 
 * [vela template context](vela_template_context.md)	 - Show context parameters
 
-###### Auto generated by spf13/cobra on 6-Nov-2020
+###### Auto generated by spf13/cobra on 10-Nov-2020

docs/en/cli/vela_template_context.md

@@ -32,4 +32,4 @@ vela template context
 
 * [vela template](vela_template.md)	 - Manage templates
 
-###### Auto generated by spf13/cobra on 6-Nov-2020
+###### Auto generated by spf13/cobra on 10-Nov-2020

docs/en/cli/vela_traits.md

@@ -34,4 +34,4 @@ vela traits
 
 * [vela](vela.md)	 - 
 
-###### Auto generated by spf13/cobra on 6-Nov-2020
+###### Auto generated by spf13/cobra on 10-Nov-2020

docs/en/cli/vela_up.md

@@ -27,4 +27,4 @@ vela up
 
 * [vela](vela.md)	 - 
 
-###### Auto generated by spf13/cobra on 6-Nov-2020
+###### Auto generated by spf13/cobra on 10-Nov-2020

docs/en/cli/vela_version.md

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

docs/en/cli/vela_workloads.md

@@ -33,4 +33,4 @@ vela workloads
 
 * [vela](vela.md)	 - 
 
-###### Auto generated by spf13/cobra on 6-Nov-2020
+###### Auto generated by spf13/cobra on 10-Nov-2020

docs/en/concepts.md

@@ -7,7 +7,7 @@ This document explains some technical terms that are widely used in KubeVela, su
 ![alt](../resources/concepts.png)
 
 ## Workload Type & Trait
-The core KubeVela APIs are built based on Open Application Model (OAM). Hence, the `workload type` and `trait` concepts are borrowed from OAM.
+The core KubeVela APIs are built based on Open Application Model (OAM). Hence, the `workload type` and `trait` concepts are inherited from OAM.
 
 A [workload type](https://github.com/oam-dev/spec/blob/master/4.workload_definitions.md) declares the characteristics that runtime infrastructure should take into account in application management. A typical workload type could be a "long running service", or a "one-time off task" that can be instantiated as part of your application.
 

docs/en/design.md

@@ -0,0 +1,155 @@
+# KubeVela Design
+
+This document is the detailed design and architecture of the KubeVela being built in this repository.
+
+> All the diagram in this documentation could be found in [this slides](https://docs.google.com/presentation/d/1Y3gnKrd7fUZGgee7Ia9vBsRIYhcZLQwMUCDkk1RJvQc).
+
+## User Stories
+
+As a end user (e.g. application developers, operators etc) of the platform, I only want to focus on coding my business logic and ship them to various environments at ease. Let's say:
+- Here's my source code.
+- Here's my application configuration (described in end user PoV).
+- Deploy it in test environment.
+- Deploy it in production environment.
+- Monitoring, debugging, rollout/rollback the application.
+- Dockerfile is fine, but please keep it simple. 
+
+As a platform engineer, I want to build a easy-to-use platform for end users. In detail, the platform should be:
+- Heroku-like (_in terms of both user experience and functionality_). 
+  - and I prefer to build my own version with OSS tools, particularly, with Kubernetes (for obvious reason).
+- Easy to build. 
+  -  I am too busy to reinvent any wheel, I want to reuse existing capabilities in Kubernetes community as features of my platform with minimal effort. Writing some simple CRD and controllers is fine, but please, just the simple ones.
+- Powerful and highly extensible.
+  - I don't want to lock users with restricted abstractions and capabilities like traditional PaaS or FaaS/Serverless. I love Kubernetes and what it has enabled. So in terms of capability, I hope my platform is fully open and has unlimited possibilities like Kubernetes itself, rather than another opinionated close system like traditional PaaS.
+
+## Core Principles
+
+For developers, KubeVela provides a out-of-the-box PaaS-ish experience that enables better productivity (i.e. focus, self-service, on-demand, and fast-feedback).
+
+For platform builders, KubeVela works like a special Kubernetes "distro" or extensible PaaS core that could be used to build something more complex on top of. It enables platform builders to integrate existing capabilities in Kubernetes ecosystem with minimal effort, and/or develop a new capability at ease in a standard, Kubernetes-native approach.
+
+## Design Details
+
+### 1. Application Centric
+
+Keywords: _focus_, _self-service_.
+
+KubeVela intends to ensure developers only think in the scope of _application_, not container or infrastructure. We've seen lacking application context impacts the developer experience and raises the bar to adopt cloud native technology and we believe _application_ is the natural mindset for developers and it's the core API KubeVela should expose.
+
+![alt](../resources/app-centric.png)
+
+In KubeVela, it is only push code, deploy application in developer facing primitives, and claim operations policies that developers would do. Thus, KubeVela choose to:
+1. Introduce _application_ as its first class API.
+2. Build the whole system around "application", i.e. model capabilities of Kubernetes as application configuration, with clarity and manageability.
+
+#### Solution
+
+One common solution to introduce such concept of "application" to Kubernetes is creating an "application CRD". However, as an extensible PaaS core, KubeVela intends to support any application type and any operation feature in Kubernetes ecosystem, thus instead of creating a in-house and "monolithic" CRD, KubeVela adopts [Open Application Model (OAM)](https://github.com/oam-dev/spec) as its application definition. This is empowers KubeVela with high extensibility since every workload and operation feature in OAM is modeled by independent definition object with full freedom to extend. Besides, the model in OAM is also well-defined as it defines micro-services application by default, and models operation features as part of the application (i.e. `Traits`).
+
+### 2. Capability Oriented Architecture
+
+Keywords: _on-demand_.
+
+Every capability in KubeVela is designed as a standalone "plug-in" in terms of implementation and configuration. This enables the extensibility of the platform, and gives platform builders full freedom to extend KubeVela into anything else they want (e.g. database PaaS, AI PaaS, etc.).
+
+![alt](../resources/coa.png)
+
+This loosely coupled design adopts the idea of Capability Oriented Architecture (COA), i.e. instead of creating a close system like traditional PaaS, KubeVela intends to become an application-centric framework that could connect developers with any underlying infrastructure capability per demand.
+
+#### Solution
+
+KubeVela core is built with [OAM Kubernetes Runtime](https://github.com/crossplane/oam-kubernetes-runtime) which met the requirements of KubeVela such as supporting bring in standalone controllers as workload type and trait. A set of abstraction and interfaces are defined in this library for KubeVela to assemble various Kubernetes capabilities into a platform without coupling them together or introducing any glue code.  
+
+For example, there are several "built-in" workload types in KubeVela such as `Web Service` or `Task`. In implementation, KubeVela discovers them with OAM definition object, it does **NOT** need to be aware of the specification or implementation of these workload types, i.e. they could be Kubernetes built-in resources, or CRD controllers.
+
+This means platform builders are free to bring their own workload types by simply install another CRD controller, or just reference another k8s built-in resource like StatefulSet as new workload type.
+
+Similarly, all the operation features such as `scaling` or `rollout` (i.e. "traits" in KubeVela) are independent from workload implementations. In KubeVela, traits will attempt to understand how to interact with a workload instance following [its characteristic labels](https://github.com/oam-dev/spec/blob/master/4.workload_definitions.md#labels) instead of coupling with specific implementation of workload. This enables platform builders to bring their own traits freely by simply providing another CRD controller, or reference another k8s built-in resource like `HPA` or `NetworkPolicy`.
+
+##### Capability Register and Discovery
+
+KubeVela leverages [OAM definition objects](https://github.com/oam-dev/spec/blob/master/4.workload_definitions.md) to register and discover workloads and traits:
+
+
+```bash
+$ kubectl apply -f workload-definition.yaml # register a new workload type
+$ kubectl apply -f trait-definition.yaml # register a new trait
+```
+
+Note that OAM definition objects only care about API resource, not including the controllers. Thus KubeVela intends to include a **CRD registry** so whenever a new API resource is installed as workload or trait, KubeVela could install its controller automatically from the registry. That of course means we envision the CRD registry could register a CRD and Helm chart (which contains the manifest of the controller). In practice, we are currently evaluating RedHat's Operator Lifecycle Manager (OLM) but no the final conclusion yet.
+
+##### Cloud Services Integration
+
+For capabilities like cloud services, KubeVela intends to leverage [Crossplane](https://github.com/crossplane/crossplane) core to register and provision cloud services as OAM workload types.
+
+### 3. Extensible User Interface
+
+Keywords: _self-service_, _on-demand_, _fast-feedback_
+
+So far, **ALL** functionalities of KubeVela core can be handled by simple `kubectl`, for example:
+
+```yaml
+$ kubectl apply -f frontend-component.yaml # create frontend component
+$ kubectl apply -f backend-component.yaml # create backend component
+$ kubectl apply -f application-config.yaml # assign operational traits to components and deploy the whole application
+```
+
+We call these server side API resources "the model objects" of KubeVela. They are essentially the [Control Plane Objects](https://github.com/oam-dev/spec/blob/master/2.overview_and_terminology.md#control-plane-objects) defined in OAM specification.
+
+On the other hand, KubeVela intend to create a lightweight user facing layer on the top of the model objects, with following goals in mind:
+
+- Shorten the learning curve of new developers. Most capabilities in Kubernetes are developed by big
+companies that run very complex workloads. However, for the bigger developer community, the new user facing layer will provide a much simpler path to on-board these capabilities.
+- Developers can describe their applications and behavior of their components without making assumptions on availability of specific Kubernetes API. For instance, a developer will be able to model auto-scaling needs without referring to the CRD of auto-scaling trait.
+- Provides a single source of truth of the application description. The user facing layer allows developers to work with a single artifact to capture the application definition. This artifact is the definitive truth of how the application is supposed to look like. It simplifies administrative tasks such as change management. It also serves as an anchor for application truth to avoid configuration drifts during operation.
+- Highly extensible. For example, when a new workload type or trait is installed, the end users could access this new capability directly from user interface layer, no re-compile or re-deploy of KubeVela is required.
+
+#### Solution
+
+In KubeVela, we introduced a docker-compose style "appfile" with higher level abstractions as the main user interface of the platform, so developers can define and deploy an application with a single command: `$ vela up`.
+
+Plus, the schema of `appfile` is designed to be "assembled" with independent workload type and traits defined with OAM specification. For example:
+
+```
+services:
+  frontend:
+    type: webservice
+    image: oamdev/testapp:v1
+
+    route:
+      domain: example.com
+      http: # match the longest prefix
+        "/": 8080
+ ```
+
+This `appfile` is composed by a `frontend` component with workload type of `Web Service` and a `route` trait. Developer fill in the values based on indepedent schema documentations for such workload type and trait, and KubeVela will check corresponding definitions objects in OAM Kubernetes implementation to validate and generate the final Kubernetes resources. This is how we make the user interface of KubeVela highly extensible.
+
+Besides, in order to make building higher level abstractions easier, we adopted [CUElang](https://github.com/cuelang/cue) in the implementation of OAM on Kubernetes, especially, for creating last mile abstractions (i.e eliminate non user facing fields or compose multiple objects into one). This makes all the abstractions in `appfile` essentially defined by CUE templates in OAM Control Plane Objects and the platform builders are free to modify those template at any time. This update will take effect immediately in the schema of `appfile`.
+
+![alt](../resources/appfile.png)
+
+> In OAM community, `appfile` is the experimental effort to introduce _User Facing Objects_ alongside with the existing _Control Plane Objects_ in OAM specification. Feel free to check its [design doc](https://github.com/oam-dev/kubevela/blob/master/docs/design/appfile-design.md) for more detail.
+
+KubeVela also introduced a command line to which can generate `appfile` in easy approach. For example, the command below will generate and deploy the above `frontend` service to KubeVela directly:
+
+```bash
+$ vela svc deploy frontend -t webservice --image oamdev/testapp:v1
+```
+
+Similarly, the dashboard of KubeVela is essentially a GUI version of `appfile` where the schema of forms are also highly extensible based on the mechanism above.
+
+## Architecture
+
+![alt](../resources/arch.png)
+
+From highest level, KubeVela is composed by only **two components**:
+
+### KubeVela User Interfaces
+User interfaces of KubeVela, including: `appfile`, `cli` and `dashboard`.
+
+### KubeVela Core
+KubeVela core is a server side controller which is composed by:
+- [Crossplane OAM Kubernetes runtime](https://github.com/crossplane/oam-kubernetes-runtime) to provide Control Plane Objects such as `Component` and `Application Configuration` etc.
+- Built-in workload and trait implementations to provide core capabilities such as `webservice`, `route` and `rollout` etc.
+- Capability Management: manage features (i.e. workload types and traits) of KubeVela as independent add-ons following the design of _Capability Oriented Architecture_ mentioned above.
+- CRD Registry: register and discover Kubernetes controllers by its CRD. This enables KubeVela automatically install dependent controllers/operators triggered by "CRD missing" event when any new workload type or trait is added.

docs/en/developers/app-init.md

@@ -6,7 +6,7 @@ To initialize and deploy an application with one service, run:
 
 > If you only want to initialize without deploying the app, add `--render-only` flag
 
-```console
+```bash
 $ vela  init
 Welcome to use KubeVela CLI! We're going to help you run applications through a couple of questions.
 
@@ -34,7 +34,7 @@ Environment: default, namespace: default
 
 Check the application:
 
-```console
+```bash
 $ vela show testapp
 About:
 
@@ -63,7 +63,7 @@ You can also use KubeVela CLI to deploy multiple services for an application.
 
 Check the available workload types.
 
-```console
+```bash
 $ vela workloads
 NAME      	DESCRIPTION
 worker   	Backend worker without ports exposed
@@ -72,7 +72,7 @@ webservice	Long running service with network routes
 
 Deploy the first service named `frontend` with `Web Service` type:
 
-```console
+```bash
 $ vela svc deploy frontend --app testapp -t webservice --image crccheck/hello-world
 App testapp deployed
 ```
@@ -81,12 +81,12 @@ App testapp deployed
 
 Deploy the second service named `backend` with "Backend Worker" type:
 
-```console
+```bash
 $ vela svc deploy backend --app testapp2 -t worker --image crccheck/hello-world
 App testapp2 deployed
 ```
 
-```console
+```bash
 $ vela ls
 SERVICE 	APP     	TYPE	TRAITS	STATUS 	CREATED-TIME
 frontend	testapp 	    	      	...

docs/en/developers/cap-center.md

@@ -6,7 +6,7 @@ This tutorial talks about how to install capabilities (caps) from remote centers
 
 Add and sync a remote center:
 
-```console
+```bash
 $ vela cap center config my-center https://github.com/oam-dev/catalog/tree/master/registry
 successfully sync 1/1 from my-center remote center
 Successfully configured capability center my-center and sync from remote
@@ -18,7 +18,7 @@ sync finished
 
 ## List Cap Centers
 
-```console
+```bash
 $ vela cap center ls
 NAME     	ADDRESS
 my-center	https://github.com/oam-dev/catalog/tree/master/registry
@@ -26,13 +26,13 @@ my-center	https://github.com/oam-dev/catalog/tree/master/registry
 
 ## [Optional] Remove Cap Center
 
-```console
+```bash
 $ vela cap center remove my-center
 ```
 
 ## List Caps
 
-```console
+```bash
 $ vela cap ls my-center
 NAME     	CENTER   	TYPE 	DEFINITION                  	STATUS     	APPLIES-TO
 kubewatch	my-center	trait	kubewatches.labs.bitnami.com	uninstalled	[]
@@ -40,7 +40,7 @@ kubewatch	my-center	trait	kubewatches.labs.bitnami.com	uninstalled	[]
 
 ## Install Cap
 
-```console
+```bash
 $ vela cap install my-center/kubewatch
 Installing trait capability kubewatch
 "my-repo" has been added to your repositories
@@ -52,7 +52,7 @@ Successfully installed capability kubewatch from my-center
 ```
 
 Check traits installed:
-```console
+```bash
 $ vela traits
 Synchronizing capabilities from cluster⌛ ...
 Sync capabilities successfully ✅ (no changes)
@@ -65,7 +65,7 @@ kubewatch 	trait   	Add a watch for resource
 
 > Note: make sure no apps are using the capability before uninstalling.
 
-```console
+```bash
 $ vela cap uninstall my-center/kubewatch
 Successfully removed chart (kubewatch) with release name (kubewatch)
 ```

docs/en/developers/check-logs.md

@@ -1,6 +1,6 @@
 # Check Logs of Container
 
-```console
+```bash
 $ vela logs testapp
 ```
 

docs/en/developers/cloud-service.md

@@ -16,8 +16,8 @@ KubeVela will delegate the lifecycle management of cloud service to Crossplane.
 
 You will need a Kubernetes cluster ver> 1.16 (Minikube and Kind clusters are fine).   
 Also you will need to have KubeVela installed on the cluster.   
-The folder that containes all the demo scripts are under `../../examples/kubecondemo/`. For your convience, cd to that folder first:  
-`cd ../../examples/kubecondemo/`   
+The folder that containes all the demo scripts are under [examples/kubecondemo/](https://github.com/oam-dev/kubevela.io/tree/master/examples/kubecondemo). For your convience, cd to that folder first:  
+`cd examples/kubecondemo/`
 To provision a cloud resource, you need to have the Access Key and Secret to your Alibaba cloud account.
 
 * Create crossplane namespace: `kubectl create ns crossplane-system`

docs/en/developers/config-app.md

@@ -4,7 +4,7 @@
 
 ## `vela config set`
 
-```console
+```bash
 $ vela config set test a=b c=d
 reading existing config data and merging with user input
 config data saved successfully ✅
@@ -12,7 +12,7 @@ config data saved successfully ✅
 
 ## `vela config get`
 
-```console
+```bash
 $ vela config get test
 Data:
   a: b
@@ -21,14 +21,14 @@ Data:
 
 ## `vela config del`
 
-```console
+```bash
 $ vela config del test
 config (test) deleted successfully
 ```
 
 ## `vela config ls`
 
-```console
+```bash
 $ vela config set test a=b
 $ vela config set test2 c=d
 $ vela config ls
@@ -41,7 +41,7 @@ test2
 
 The config data can be set as the env in applications.
 
-```console
+```bash
 $ vela config set demo DEMO_HELLO=helloworld
 ```
 
@@ -56,7 +56,7 @@ services:
 ```
 
 Then run:
-```console
+```bash
 $ vela up
 Parsing vela.yaml ...
 Loading templates ...

docs/en/developers/config-enviroments.md

@@ -4,14 +4,14 @@ Before working with your application, you need to prepare a deployment environme
 
 ## Create environment
 
-```console
+```bash
 $ vela env init demo --email my@email.com
 environment demo created, Namespace: default, Email: my@email.com
 ```
 
 ## Check the deployment environment metadata
 
-```console
+```bash
 $ vela env ls
 NAME   	CURRENT	NAMESPACE	EMAIL                	DOMAIN
 default	       	default  	
@@ -24,12 +24,12 @@ By default, the environment will use `default` namespace in K8s.
 
 You could change the config by executing the environment again.
 
-```console
+```bash
 $ vela env init demo --namespace demo
 environment demo created, Namespace: demo, Email: my@email.com
 ```
 
-```console
+```bash
 $ vela env ls
 NAME   	CURRENT	NAMESPACE	EMAIL                	DOMAIN
 default	       	default  	
@@ -46,7 +46,7 @@ your app by this domain with an mTLS supported automatically.
 
 For example, you could get the public IP from ingress service.  
 
-```console
+```bash
 $ kubectl get svc -A | grep LoadBalancer
 NAME                         TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)                      AGE
 nginx-ingress-lb             LoadBalancer   172.21.2.174    123.57.10.233   80:32740/TCP,443:32086/TCP   41d
@@ -62,7 +62,7 @@ You could also use `123.57.10.233.xip.io` as your domain, if you don't have a cu
 `xip.io` will automatically route to the prefix IP `123.57.10.233`.
 
 
-```console
+```bash
 $ vela env init demo --domain 123.57.10.233.xip.io
 environment demo updated, Namespace: demo, Email: my@email.com
 ```

docs/en/developers/devex/appfile.md

@@ -1,9 +1,9 @@
 # Using Appfile for More Flexible Configuration
 
 Appfile supports more flexible options than CLI/UI to configure appliation deployment on Vela.
-A detailed design doc could be found [here](../../design/appfile-design.md).
+A detailed design doc could be found [here](https://github.com/oam-dev/kubevela/blob/master/docs/design/appfile-design.md).
 
-In this tutorial, we will build and deploy an example NodeJS app under [examples/testapp/](https://github.com/oam-dev/kubevela/tree/master/examples/testapp).
+In this tutorial, we will build and deploy an example NodeJS app under [examples/testapp/](https://github.com/oam-dev/kubevela.io/tree/master/examples/testapp).
 
 ## Prerequisites
 
@@ -14,16 +14,16 @@ In this tutorial, we will build and deploy an example NodeJS app under [examples
 
 git clone and go to the testapp directory:
 
-```console
-$ git clone https://github.com/oam-dev/kubevela.git
-$ cd kubevela/examples/testapp
+```bash
+$ git clone https://github.com/oam-dev/kubevela.io.git
+$ cd kubevela.io/examples/testapp
 ```
 
 The example contains NodeJS app code, Dockerfile to build the app.
 
 ## 2. Deploy app in one command
 
-In the directory there is a [vela.yaml](../../../examples/testapp/vela.yaml) which follows Appfile format supported by Vela.
+In the directory there is a [vela.yaml](https://github.com/oam-dev/kubevela.io/tree/master/examples/testapp/vela.yaml) which follows Appfile format supported by Vela.
 We are going to use it to build and deploy the app.
 
 ATTENTION: change the image field in vela.yaml to something you can push to on your host:
@@ -36,7 +36,7 @@ ATTENTION: change the image field in vela.yaml to something you can push to on y
 
 Run the following command:
 
-```console
+```bash
 $ vela up
 Parsing vela.yaml ...
 Loading templates ...
@@ -67,7 +67,7 @@ App has not been deployed, creating a new deployment...
 
 Check the status of the service:
 
-```console
+```bash
 $ vela status testapp
   About:
   
@@ -107,7 +107,7 @@ Add local option to `build`:
 
 Then deploy the app to kind:
 
-```console
+```bash
 $ vela up
 ```
 
@@ -165,12 +165,12 @@ servcies:
 
 Apply again:
 
-```console
+```bash
 $ vela up
 ```
 
 Check the status until we see route trait ready:
-```console
+```bash
 $ vela status testapp
 About:
 
@@ -188,7 +188,7 @@ Services:
       Created at: ...
       Updated at: ...
     Routes:
-      - route: 	Visiting URL: http://example.com	IP: localhost
+      - route: 	Visiting URL: http://example.com	IP: <ingress-IP-address>
 ```
 
 **In [kind cluster setup](../../install.md#kind)**, you can visit the service via localhost:
@@ -200,9 +200,25 @@ $ curl -H "Host:example.com" http://localhost/testapp
 Hello World
 ```
 
-## 4. Add monitoring metrics
+## 4. Add auto scaling
 
-TODO
+```yaml
+name: testapp
+
+services:
+  express-server:
+    ...
+
+    autoscale:
+      minReplicas: 1
+      maxReplicas: 4
+      cron:
+        startAt:  "14:00"
+        duration: "2h"
+        days:     "Monday, Thursday"
+        replicas: "2"
+        timezone: "America/Seattle"
+```
 
 ## [Optional] Configure "task" workload type
 
@@ -222,7 +238,7 @@ services:
 
 Then deploy appfile again:
 
-```console
+```bash
 $ vela up
 ```
 

docs/en/developers/devex/cli.md

@@ -6,7 +6,7 @@ Learn about general configurations for `vela` command line tool. For the usage o
 
 #### bash
 
-```console
+```bash
 To load completions in your current shell session:
 $ source <(vela completion bash)
 
@@ -19,7 +19,7 @@ MacOS:
 
 #### zsh
 
-```console
+```bash
 To load completions in your current shell session:
 $ source <(vela completion zsh)
 

docs/en/developers/devex/dashboard.md

@@ -3,7 +3,7 @@
 
 KubeVela has a simple client side dashboard for you to interact with. The functionality is equivalent to the vela cli.
 
-```console
+```bash
 $ vela dashboard
 ```
 

docs/en/developers/references/README.md

@@ -1,7 +1,7 @@
 # KubeVela Capability References
 
-- [workload types](https://github.com/oam-dev/kubevela/tree/master/docs/developers/references/workload-types)
-- [trait](https://github.com/oam-dev/kubevela/tree/master/docs/developers/references/traits)
+- [workload types](https://github.com/oam-dev/kubevela.io/tree/master/en/developers/references/workload-types)
+- [trait](https://github.com/oam-dev/kubevela.io/tree/master/en/developers/references/traits)
 
 
 Note: All the contents under this directory are designed to be referenced by other documentations as the full schema or usage of specific workload types or traits.

docs/en/developers/set-autoscale.md

@@ -29,7 +29,7 @@ is supported.
       Type: webservice
       HEALTHY Ready: 1/1
       Traits:
-        - ✅ autoscale: type: cpu	minReplicas: 1	maxReplicas: 5	CPUUtilization(target/current): 5%/0%	replicas: 0
+        - ✅ autoscale: type: cpu     cpu-utilization(target/current): 5%/0%	replicas(min/max/current): 1/5/0
       Last Deployment:
         Created at: 2020-11-06 16:10:54 +0800 CST
         Updated at: 2020-11-06T16:19:04+08:0
@@ -79,7 +79,7 @@ is supported.
       Type: webservice
       HEALTHY Ready: 1/1
       Traits:
-        - ✅ autoscale: type: cpu	minReplicas: 1	maxReplicas: 5	CPUUtilization(target/current): 5%/10%	replicas: 2
+        - ✅ autoscale: type: cpu     cpu-utilization(target/current): 5%/10%	replicas(min/max/current): 1/5/2
       Last Deployment:
         Created at: 2020-11-05 20:07:23 +0800 CST
         Updated at: 2020-11-05T20:50:42+08:00
@@ -100,7 +100,7 @@ is supported.
       Type: webservice
       HEALTHY Ready: 1/1
       Traits:
-        - ✅ autoscale: type: cpu	minReplicas: 1	maxReplicas: 5	CPUUtilization(target/current): 5%/14%	replicas: 4
+        - ✅ autoscale: type: cpu     cpu-utilization(target/current): 5%/14%	replicas(min/max/current): 1/5/4
       Last Deployment:
         Created at: 2020-11-05 20:07:23 +0800 CST
         Updated at: 2020-11-05T20:50:42+08:00
@@ -114,7 +114,7 @@ Introduce how to automatically scale workloads by cron in Appfile.
 
 - Prepare Appfile
   Follow the instructions of [appfile](./devex/appfile.md) to prepare the `vela.yaml` as below.
-  ```
+  ```yaml
   name: testapp
   
   services:
@@ -132,8 +132,8 @@ Introduce how to automatically scale workloads by cron in Appfile.
       port: 8080
   
       autoscale:
-        minReplicas: 1
-        maxReplicas: 4
+        min: 1
+        max: 4
         cron:
           startAt:  "14:00"
           duration: "2h"
@@ -202,7 +202,7 @@ Introduce how to automatically scale workloads by cron in Appfile.
       Type: webservice
       HEALTHY Ready: 1/1
       Traits:
-        - ✅ autoscale: type: cron	minReplicas: 1	maxReplicas: 4	replicas: 1
+        - ✅ autoscale: type: cron    replicas(min/max/current): 1/4/1
       Last Deployment:
         Created at: 2020-11-05 17:09:03 +0800 CST
         Updated at: 2020-11-05T17:09:02+08:00
@@ -217,19 +217,19 @@ Introduce how to automatically scale workloads by cron in Appfile.
   
     Name:      	testapp
     Namespace: 	default
-    Created at:	2020-11-05 17:09:02.426632 +0800 CST
-    Updated at:	2020-11-05 17:09:02.426632 +0800 CST
+    Created at:	2020-11-10 10:18:59.498079 +0800 CST
+    Updated at:	2020-11-10 10:18:59.49808 +0800 CST
   
   Services:
   
     - Name: express-server
       Type: webservice
-      HEALTHY Ready: 1/1
+      HEALTHY Ready: 2/2
       Traits:
-        - ✅ autoscale: type: cron	minReplicas: 1	maxReplicas: 4	replicas: 2
+        - ✅ autoscale: type: cron    replicas(min/max/current): 1/4/2
       Last Deployment:
-        Created at: 2020-11-05 17:09:03 +0800 CST
-        Updated at: 2020-11-05T17:09:02+08:00
+        Created at: 2020-11-10 10:18:59 +0800 CST
+        Updated at: 2020-11-10T10:18:59+08:00
   ```
   
   Wait after the period ends, the replicas will be one eventually.

docs/en/developers/set-metrics.md

@@ -6,13 +6,13 @@ with the help of `metric` capability.
 Let's run [`christianhxc/gorandom:1.0`](https://github.com/christianhxc/prometheus-tutorial) as an example app.
 The app will emit random latencies as metrics.
 
-```console
+```bash
 $ vela svc deploy metricapp -t webservice --image christianhxc/gorandom:1.0 --port 8080
 ```
 
 Then add metric by:
 
-```console
+```bash
 $ vela metric metricapp
 Adding metric for app metricapp
 ⠋ Deploying ...

docs/en/developers/set-rollout.md

@@ -0,0 +1,83 @@
+# Setting Rollout Strategy
+
+You could use rollout capability to rolling upgrade your app.
+
+The workflow will like below:
+
+Firstly, deploy your app by:
+
+```shell script
+$ vela svc deploy testapp -t webservice --image oamdev/testapp:v1 --port 8080
+App testapp deployed
+```
+
+Add route for visit:
+
+```shell script
+$ vela route testapp --domain myhost.com
+Adding route for app testapp
+⠋ Checking Status ...
+✅ Application Deployed Successfully!
+  - Name: testapp
+    Type: webservice
+    HEALTHY Ready: 1/1
+    Traits:
+      - ✅ route: 	Visiting URL: http://myhost.com	IP: <your-ingress-IP-address>
+
+    Last Deployment:
+      Created at: 2020-11-09 12:50:30 +0800 CST
+      Updated at: 2020-11-09T12:51:19+08:00
+```
+
+```shell script
+$ curl -H "Host:myhost.com" http://<your-ingress-IP-address>/
+Hello World%
+```
+
+Secondly, add rollout policy for your app:
+
+```shell script
+vela rollout testapp --replica 5 --step-weight 20 --interval 5s
+```
+
+Then update your app by:
+
+```shell script
+vela svc deploy testapp -t webservice --image oamdev/testapp:v2 --port 8080
+```
+
+Then it will rolling update your instance, you could try `curl` your app multiple times:
+
+```shell script
+$ curl -H "Host:myhost.com" http://39.97.232.19/
+Hello World  -- Updated Version Two!%                                         
+$ curl -H "Host:myhost.com" http://39.97.232.19/
+Hello World%                                                                  
+$ curl -H "Host:myhost.com" http://39.97.232.19/
+Hello World%                                                                  
+$ curl -H "Host:myhost.com" http://39.97.232.19/
+Hello World  -- Updated Version Two!%                                         
+$ curl -H "Host:myhost.com" http://39.97.232.19/
+Hello World%                                                                  
+$ curl -H "Host:myhost.com" http://39.97.232.19/
+Hello World  -- Updated Version Two!%
+``` 
+
+It will return both version of output info as both instances are all existing.
+
+<details>
+  <summary>Under the hood, it was flagger canary running.</summary>
+
+```shell script
+$ kubectl get canaries.flagger.app testapp-trait-76fc76fddc -w
+NAME                       STATUS        WEIGHT   LASTTRANSITIONTIME
+testapp-trait-76fc76fddc   Progressing   0        2020-11-10T09:06:10Z
+testapp-trait-76fc76fddc   Progressing   20       2020-11-10T09:06:30Z
+testapp-trait-76fc76fddc   Progressing   40       2020-11-10T09:06:40Z
+testapp-trait-76fc76fddc   Progressing   60       2020-11-10T09:07:31Z
+testapp-trait-76fc76fddc   Promoting     0        2020-11-10T09:08:00Z
+testapp-trait-76fc76fddc   Promoting     100      2020-11-10T09:08:10Z
+testapp-trait-76fc76fddc   Finalising    0        2020-11-10T09:08:20Z
+testapp-trait-76fc76fddc   Succeeded     0        2020-11-10T09:08:30Z
+```
+</details>

docs/en/developers/set-route.md

@@ -3,7 +3,7 @@
 Once your web services of the application deployed, you can visit it locally via `port-forward` or
 from outside world via `route` feature. 
 
-```console
+```bash
 $ vela svc ls
 NAME  	    APP  	WORKLOAD  	  TRAITS	STATUS 	    CREATED-TIME
 frontend	testapp	webservice	      	    Deployed	2020-09-18 22:42:04 +0800 CST
@@ -13,7 +13,7 @@ frontend	testapp	webservice	      	    Deployed	2020-09-18 22:42:04 +0800 CST
 
 It will directly open browser for you.
 
-```console
+```bash
 $ vela port-forward testapp
 Forwarding from 127.0.0.1:8080 -> 80
 Forwarding from [::1]:8080 -> 80
@@ -31,7 +31,7 @@ Handling connection for 8080
 
 You can manually configure it by setting domain parameter.
 
-```console
+```bash
 $ vela route testapp --domain frontend.mycustom.domain
 Adding route for app frontend
 
@@ -55,7 +55,7 @@ $ curl -H "Host:frontend.mycustom.domain" 123.57.10.233
 
 ### If you have domain set in environment
 
-```console
+```bash
 $ vela route testapp
 Adding route for app frontend
 

docs/en/install.md

@@ -13,13 +13,13 @@ Follow the minikube [installation guide](https://minikube.sigs.k8s.io/docs/start
 
 Once minikube is installed, create a cluster:
 
-```console
+```bash
 $ minikube start
 ```
 
 Install ingress:
 
-```console
+```bash
 $ minikube addons enable ingress
 ```
 
@@ -29,7 +29,7 @@ Follow [this guide](https://kind.sigs.k8s.io/docs/user/quick-start/#installation
 
 Then spins up a kind cluster:
 
-```console
+```bash
 cat <<EOF | kind create cluster --config=-
 kind: Cluster
 apiVersion: kind.x-k8s.io/v1alpha4
@@ -52,7 +52,7 @@ EOF
 ```
 
 Then install [ingress for kind](https://kind.sigs.k8s.io/docs/user/ingress/#ingress-nginx):
-```console
+```bash
 $ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/provider/kind/deploy.yaml
 ```
 
@@ -61,7 +61,7 @@ $ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/ma
 1. Download the latest `vela` binary from the [releases page](https://github.com/oam-dev/kubevela/releases).
 2. Unpack the `vela` binary and add it to `$PATH` to get started.
 
-```console
+```bash
 $ sudo mv ./vela /usr/local/bin/vela
 ```
 
@@ -69,7 +69,7 @@ $ sudo mv ./vela /usr/local/bin/vela
 
 Run:
 
-```console
+```bash
 $ vela install
 ```
 
@@ -100,7 +100,7 @@ kube-prometheus-stack	monitoring  	1
 
 Run:
 
-```console
+```bash
 $ helm uninstall -n vela-system kubevela
 $ rm -r ~/.vela
 ```

docs/en/introduction.md

@@ -16,7 +16,7 @@ In the end, developers complain those platforms are too rigid and slow in respon
 
 ## What is KubeVela?
 
-For developers, KubeVela itself is an easy-to-use tool that enables them to describe and ship their applications to Kubernetes with minimal effort. Instead of managing a handful Kubernetes YAML files, a simple docker-compose style [Appfile](./docs/developers/devex/appfile.md) is all they need, following an application-centric workflow that can be easily integrated with any CI/CD pipeline.
+For developers, KubeVela itself is an easy-to-use tool that enables them to describe and ship their applications to Kubernetes with minimal effort. Instead of managing a handful Kubernetes YAML files, a simple docker-compose style [Appfile](/en/developers/devex/appfile) is all they need, following an application-centric workflow that can be easily integrated with any CI/CD pipeline.
 
 The above experience cannot be achieved without KubeVela's innovative offerings to the platform builders.
 

docs/en/platform-engineers/extending-kubevela.md

@@ -17,14 +17,14 @@ Prerequisites:
 
 ### Step 1: Install KubeWatch
 
-```console
+```bash
 $ helm repo add vela-demo https://wonderflow.info/kubewatch/archives/
 $ helm install kubewatch vela-demo/kubewatch --version 0.1.0
 ```
 
 ### Step 2: Add Trait Definition with CUE template
 
-```console
+```bash
 $ cat << EOF | kubectl apply -f -
 apiVersion: core.oam.dev/v1alpha2
 kind: TraitDefinition
@@ -57,7 +57,7 @@ That's it! Once you have applied the definition file the feature will be automat
 
 ### Step 3: Verify Kubewatch Trait Installed
 
-```console
+```bash
 $ vela traits
 Synchronizing capabilities from cluster⌛ ...
 Sync capabilities successfully ✅ Add(1) Update(0) Delete(0)
@@ -75,7 +75,7 @@ kubewatch	Add a watch for resource
 
 Write an Appfile:
 
-```console
+```bash
 $ cat << EOF > vela.yaml
 name: testapp
 services:
@@ -90,7 +90,7 @@ EOF
 
 Deploy it:
 
-```console
+```bash
 $ vela up
 ...
 ✅ App has been deployed 🚀🚀🚀
@@ -107,7 +107,7 @@ You can use either of the following options to attach the newly added kubewatch
 
 Add kubewatch trait to the application:
 
-```console
+```bash
 $ vela kubewatch testapp --svc testsvc --webhook https://hooks.slack.com/<your-token>
 Adding kubewatch for app testsvc
 ⠋ Checking Status ...
@@ -128,7 +128,7 @@ Check your Slack channel to verify the nofitications:
 
 Instead of using CLI, you can add `kubewatch` config to Appfile:
 
-```console
+```bash
 $ cat << EOF >> vela.yaml
     kubewatch:
       webhook: https://hooks.slack.com/<your-token>

docs/en/quick-start.md

@@ -8,7 +8,7 @@ Make sure you have finished and verified the installation following [this guide]
 
 ## 1. Initialize Application
 
-```console
+```bash
 $ vela init --render-only
 Welcome to use KubeVela CLI! Please describe your application.
 
@@ -43,7 +43,7 @@ services:
 
 ## 2. Deploy Application
 
-```console
+```bash
 $ vela up
 Parsing vela.yaml ...
 Loading templates ...
@@ -63,7 +63,7 @@ App has not been deployed, creating a new deployment...
 ```
 
 Check the status until we see route trait ready:
-```console
+```bash
 $ vela status testapp
 About:
 
@@ -84,7 +84,7 @@ Services:
       - route: 	Visiting URL: http://testsvc.example.com	IP: localhost
 ```
 
-**In [kind cluster setup](../../install.md#kind)**, you can visit the service via localhost. In other setups, replace localhost with ingress address accordingly.
+**In [kind cluster setup](./install.md#kind)**, you can visit the service via localhost. In other setups, replace localhost with ingress address accordingly.
 
 ```
 $ curl -H "Host:testsvc.example.com" http://localhost/
@@ -108,7 +108,7 @@ Hello World
 Congratulations! You have just deployed an app using KubeVela. Here are some recommended next steps:
 
 - Learn about the project's [motivation](./introduction.md) and [architecture](./design.md)
-- Try out more [tutorials](./README.md)
+- Try out more [tutorials](./developers/config-enviroments.md)
 - Join our community [Slack](https://cloud-native.slack.com/archives/C01BLQ3HTJA) and/or [Gitter](https://gitter.im/oam-dev/community)
 
 Welcome onboard and sail Vela!

docs/examples/kubecondemo/README.md

@@ -0,0 +1,78 @@
+# Kubecon 2020 NA Kubevela Tutorial
+
+## Pre-requisites
+
+* Kubernetes cluster version >1.16
+(minikube or kind are fine)
+* Verify with `kubectl config current-context` and `kubectl version`
+* One of the crossplane supported public cloud (AWS, Azure, Alibaba Cloud, GCK) access key and secret
+* Install Crossplane(later)
+* Download KubeVela release from [release page](https://github.com/oam-dev/kubevela/releases/tag/v0.0.9)
+* Unpack the package and add it to `PATH` by running `sudo mv ./vela /usr/local/bin/vela`
+* Run `vela install`
+
+## Lab 1: Use vela to deploy a simple application
+
+### Purpose: Showcase the simple to use, application centric vela user interfaces.
+
+* Sync with cluster `vela system update`
+* List installed workloads `vela workloads`
+* List installed traits `vela traits`
+* Deploy a simple application with 
+
+  ```
+  vela svc deploy back -t worker --image crccheck/hello-world --app lab1
+  vela svc deploy front -t webservice --image crccheck/hello-world --port 8000 --app lab1
+  ```
+
+* Show application status `vela app show lab1`
+
+## Lab 2: Add and apply KubeWatch
+  
+### Purpose: Showcase the steps to add and use capacity from community
+
+* Create a [slack bot](https://api.slack.com/apps?new_app=1)
+* Add a cap center `vela cap center config mycap https://github.com/oam-dev/catalog/tree/master/registry`
+* Check capabilities `vela cap ls`
+* Install the kubewatch capability `vela cap add mycap/kubewatch`
+* Create an application `vela comp deploy mycomp -t webservice --image crccheck/hello-world --port 8000 --app lab2`
+* Add kubewatch trait to the application `vela kubewatch mycomp --app lab2 --webhook https://hooks.slack.com/<yourid>`
+* Check the slack channel to verify the notifications
+
+## Lab 3: Manage cloud resource and applications in application centric way
+
+### Purpose: Showcase the application centric view of appfile
+
+### Install Crossplane (This lab uses crossplane version 0.13)
+
+Also the examples are based on Alibaba Cloud settings
+
+* Create crossplane namespace: `kubectl create ns crossplane-system`
+* Install crossplane helm chart: `helm install crossplane  charts/crossplane/ --namespace crossplane-system`
+* Install crossplane cli: `curl -sL https://raw.githubusercontent.com/crossplane/crossplane/release-0.13/install.sh | sh`
+* Add crossplane to `PATH`:  `sudo mv kubectl-crossplane /usr/local/bin`
+* Configure cloud provider(Alibaba Cloud) 
+  * Add cloud provider: `kubectl crossplane install provider crossplane/provider-alibaba:v0.3.0`
+  * Create provider secret: `kubectl create secret generic alibaba-creds --from-literal=accessKeyId=<change here> --from-literal=accessKeySecret=<change here> -n crossplane-system`
+  * Configure the provider: `kubectl apply -f script/provider.yaml`
+* Configure infrastructure: `kubectl crossplane install configuration crossplane/getting-started-with-alibaba:v0.13`
+
+### Import the database workload definition
+
+First, register the db workload definition:
+`kubectl apply -f script/def_db.yaml`
+The webservice workload is customized a little.
+`kubectl apply -f script/webservice.yaml`
+Don't forget to update vela:
+`vela system update`
+
+### Apply the appfile
+
+`vela up`
+
+### Access the web-ui
+
+If you have a cluster supporting Ingress, the route trait will work.
+`kubectl get ingress` command will show the ip address of the web-ui. Copy that service and add the `<ip address> kubevela.kubecon.demo ` record to your local machine's `/etc/hosts`. Then you may access the GUI from web browser.
+
+If you don't have Ingress installed, the eaisest way to access the demo app is through port forwarding :`kubectl port-forward <your webui pod name> 8080` and access it from browser using `http://localhost:8080`.

docs/examples/kubecondemo/charts/crossplane/.helmignore

@@ -0,0 +1,21 @@
+# Patterns to ignore when building packages.
+# This supports shell glob matching, relative path matching, and
+# negation (prefixed with !). Only one pattern per line.
+.DS_Store
+# Common VCS dirs
+.git/
+.gitignore
+.bzr/
+.bzrignore
+.hg/
+.hgignore
+.svn/
+# Common backup files
+*.swp
+*.bak
+*.tmp
+*~
+# Various IDEs
+.project
+.idea/
+*.tmproj

docs/examples/kubecondemo/charts/crossplane/Chart.yaml

@@ -0,0 +1,36 @@
+apiVersion: v1
+appVersion: 0.13.0
+description: Crossplane is an open source Kubernetes add-on that extends any cluster
+  with the ability to provision and manage cloud infrastructure, services, and applications
+  using kubectl, GitOps, or any tool that works with the Kubernetes API.
+home: https://crossplane.io
+icon: https://crossplane.io/images/favicon_192x192.png
+keywords:
+- cloud
+- infrastructure
+- services
+- application
+- database
+- cache
+- bucket
+- infra
+- app
+- ops
+- oam
+- gcp
+- azure
+- aws
+- alibaba
+- cloudsql
+- rds
+- s3
+- azuredatabase
+- asparadb
+- gke
+- aks
+- eks
+maintainers:
+- email: info@crossplane.io
+  name: Crossplane Maintainers
+name: crossplane
+version: 0.13.0