Merge pull request #1248 from wonderflow/fixdoc

Update v1.8 version doc with faq

i18n/zh/docusaurus-plugin-content-docs/version-v1.8/end-user/traits/sidecar.md

@@ -62,13 +62,29 @@ APP                 	COMPONENT     	TYPE       	TRAITS 	PHASE  	HEALTHY	STATUS	C
 vela-app-with-sidecar	log-gen-worker	worker     	sidecar           	running	healthy	      	2021-08-29 22:07:07 +0800 CST
 ```
 
-
 成功后，查看 Sidecar 所输出的日志
 
 
-```
+```shell
-vela logs vela-app-with-sidecar -c count-log
+vela logs vela-app-with-sidecar --container count-log
 ```
 
 从输出的日志可以看到读取日志的 sidecar 已经生效。
 
+<details>
+<summary>expected output</summary>
+
+```console
+0: Fri Apr 16 11:08:45 UTC 2021
+1: Fri Apr 16 11:08:46 UTC 2021
+2: Fri Apr 16 11:08:47 UTC 2021
+3: Fri Apr 16 11:08:48 UTC 2021
+4: Fri Apr 16 11:08:49 UTC 2021
+5: Fri Apr 16 11:08:50 UTC 2021
+6: Fri Apr 16 11:08:51 UTC 2021
+7: Fri Apr 16 11:08:52 UTC 2021
+8: Fri Apr 16 11:08:53 UTC 2021
+9: Fri Apr 16 11:08:54 UTC 2021 
+```
+
+</details>

i18n/zh/docusaurus-plugin-content-docs/version-v1.8/reference/addons/nginx-ingress-controller.md

@@ -7,7 +7,7 @@ title: Nginx Ingress Controller
 ##  安装
 
 ```shell
-vela addon enable ingress-controller
+vela addon enable ingress-nginx
 ```
 
 ## 指定 Service Type
@@ -16,12 +16,12 @@ vela addon enable ingress-controller
 
 - `LoadBalancer` 需要你的集群运行在某个公有云上，并有一种支持的 cloud LoadBalancer。
     ```shell script
-    vela addon enable ingress-controller serviceType=LoadBalancer
+    vela addon enable ingress-nginx serviceType=LoadBalancer
     ```   
   
 - `NodePort` 类型需要你能够访问集群节点的 IP和端口
     ```shell script
-    vela addon enable ingress-controller serviceType=NodePort
+    vela addon enable ingress-nginx serviceType=NodePort
     ```
   
 ## 获取网关地址
@@ -29,19 +29,19 @@ vela addon enable ingress-controller
 如果指定了服务类型是 `NodePort` 和 `LoadBalancer`，你可以通过下面的命令，获取到网关的地址：
 
 ```shell
-vela status addon-ingress-controller -n vela-system --endpoint
+vela status addon-ingress-nginx -n vela-system --endpoint
 ```
 
 如果是 `ClusterIP` 类型，又可以通过 `vela port-forward` 命令将网关的端口映射到本地：
 
 ```shell
-vela port-forward -n vela-system addon-ingress-controller 9080:80
+vela port-forward -n vela-system addon-ingress-nginx 9080:80
 ```
 
 ## 卸载
 
 ```shell
-vela addon disable ingress-controller
+vela addon disable ingress-nginx
 ```
 
 ## 例子
@@ -76,6 +76,3 @@ EOF
 $ curl -H "Host: canary-demo.com" <ingress-controller-endpoint>/version
 Demo: V1
 ```
-
-
-

i18n/zh/docusaurus-plugin-content-docs/version-v1.8/tutorials/helm.md

@@ -12,6 +12,7 @@ description: 本文介绍通过 KubeVela 交付 Helm Chart
 ## 开始之前
 
 - 选择一个你希望交付的 Chart 包，本文我们以 [bitnami/redis](https://github.com/bitnami/charts/tree/master/bitnami/redis) 为例。
+- 如果你在使用 [bitnami/redis](https://github.com/bitnami/charts/tree/master/bitnami/redis)，看一下[这里](https://artifacthub.io/packages/helm/bitnami/redis)是否官方还在提供你使用的版本.
 - 确保你交付的集群具有可用的默认 StorageClass，我们交付中间件大多需要数据持久化，需要默认的 StorageClass 来分配 PV。
 
 ## 启用 fluxcd 插件
@@ -47,7 +48,7 @@ vela addon enable fluxcd
 参考上图，需要做如下配置：
 
 - Repo Type: 仓库类型，目前支持 Git 和 Helm，本例我们选择 Helm 类型。
-- Repo URL: 仓库地址，基于不同的仓库类型填写仓库地址，这里我们填写：https://charts.bitnami.com/bitnami。另外，如果你在 [配置集成](../how-to/dashboard/config/helm-repo) 里配置了 helm 仓库，这里可以直接在下拉框中进行选择。
+- Repo URL: 仓库地址，基于不同的仓库类型填写仓库地址，这里我们填写：[https://charts.bitnami.com/bitnami](https://charts.bitnami.com/bitnami)。另外，如果你在 [配置集成](../how-to/dashboard/config/helm-repo) 里配置了 helm 仓库，这里可以直接在下拉框中进行选择。
 - Chart: 填写仓库地址之后，这里会自动列举出所有可用的 Helm chart，这里我们选择: redis
 - Version: 选择 chart 之后，这里的下拉框会展示出所有当前 chart 所有可用的版本，这里我们选择 16.8.5  
 - Values: 确定 chart 和版本之后，这里的下来框会展出当前 chart 的自定义配置参数，这里由于我们使用的是 ACK 集群，PV 有最小容量要求，这里填写 15Gi。同理，其他配置参数也可以通过该方式进行配置，你需要根据你的集群情况进行配置。
@@ -77,7 +78,7 @@ spec:
         repoType: "helm"
         url: "https://charts.bitnami.com/bitnami"
         chart: "redis"
-        version: "16.8.5"
+        version: "17.7.3"
         values:
           master:
             persistence:

versioned_docs/version-v1.8/developers/references/devex/faq.md

@@ -24,9 +24,19 @@ KubeVela natively support Crossplane as they're already CRDs, while terraform wa
 
 ## Common Issues
 
-### The document website is very slow to access.
+### Why things of https://*.kubevela.net is out of date?
 
-You can use https://kubevela.net/ as a faster alternative.
+Recently, we're removing the dependency of the domain `kubevela.net` due to some compliance issues, so things are migrated. Please check the following lists to find the new address:
+
+Content | old | new
+--- | --- | ---
+Documentation | https://kubevela.net | https://kubevela.io
+Image Hub | "hub.kubevela.net" | "docker.io" or "ghcr.io/kubevela" 
+Helm charts | https://charts.kubevela.net/core | https://kubevela.github.io/charts
+Official Addon Registry | https://addons.kubevela.net | https://kubevela.github.io/catalog/official
+Experimental Addon Registry | - | https://kubevela.github.io/catalog/experimental
+CLI | https://kubevela.net/script/install.sh | download from [release page](https://github.com/kubevela/kubevela/releases)
+VelaD | - | migrating 
 
 ### You have reached rate limit for Docker Image Registry 
 
@@ -37,9 +47,7 @@ By default, the community use images from docker registry for installation. You
 * Before v1.4.1, the image format is `ghcr.io/<git-repo>/vela-core:<version>`, e.g. "ghcr.io/kubevela/kubevela/vela-core:latest".
 * After v1.4.1, the image format has changed to `ghcr.io/kubevela/<align with docker hub>`, e.g. "ghcr.io/kubevela/oamdev/vela-core:latest".
 
-2. Alibaba Container Registry also sponsor KubeVela community, you can use `acr.kubevela.net/` as prefix for the docker registry, acr has a sync for each KubeVela official images. Use it like `acr.kubevela.net/oamdev/vela-core:latest`.
+2. If you insist on using Docker registry, you may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit .
-
-3. If you insist on using Docker registry, you may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit .
  
 ### SchemaError of ApplicationRevision CRD
 

versioned_docs/version-v1.8/end-user/traits/sidecar.md

@@ -65,7 +65,7 @@ vela-app-with-sidecar	log-gen-worker	worker     	sidecar           	running	heal
 And check the logging output of sidecar. 
 
 ```shell
-vela logs vela-app-with-sidecar -c count-log
+vela logs vela-app-with-sidecar --container count-log
 ```
 
 <details>

versioned_docs/version-v1.8/how-to/dashboard/trigger/overview.md

@@ -72,6 +72,68 @@ After CI have executed this step, we can see that application is deployed succes
 
 You can refer to [Jenkins CI](../../../tutorials/jenkins) guide for a real use case about custom trigger.
 
+Apart from this, Custom Triggers also supports some other type of actions, they are :
+
+#### Execute workflow
+
+Integrate Custom Triggers into your CI tool to execute a workflow. This action behaves the same as the default custom trigger with no action provided. The request body for executing a workflow using Custom Triggers is as follows:
+
+```json
+  {
+    "action":"execute"
+    // required, the upgrade of this deployment
+    "upgrade": {
+      // key is the name of application
+      "<application-name>": {
+        // the fields that need to be patched
+        "image": "<image-name>"
+      }
+    },
+    // optional, the code info of this deployment
+    "codeInfo": {
+      "commit": "<commit-id>",
+      "branch": "<branch>",
+      "user": "<user>",
+    }
+  }
+```
+
+#### Approve workflow
+
+During the `suspending` phase of a workflow step, the CI tool can approve the workflow by calling the Custom Trigger with the following request body:
+
+```json
+  {
+    "action":"approve",
+    // optional, name of the suspending step
+    "step":"suspend"
+  }
+```
+
+#### Terminate workflow
+
+If a workflow step is in the `suspending` phase, the CI tool can terminate the workflow by calling the Custom Trigger with the following request body:
+
+```json
+  {
+    "action":"terminate",
+    // optional, name of the suspending step
+    "step":"suspend"
+  }
+```
+
+#### Rollback workflow
+
+If a workflow step is in the `suspending` phase, the CI tool can initiate a rollback of an application workflow to the latest revision by calling the Custom Trigger with the following request body:
+
+```json
+  {
+    "action":"rollback",
+    // optional, name of the suspending step
+    "step":"suspend"
+  }
+```
+
 ### Harbor Trigger
 
 Harbor Trigger can be integrated with Harbor image registry.

versioned_docs/version-v1.8/installation/kubernetes.mdx

@@ -176,7 +176,7 @@ helm v3.2.0+ required
 :::
 
 ```
-helm repo add kubevela https://charts.kubevela.net/core
+helm repo add kubevela https://kubevela.github.io/charts
 helm repo update
 helm install --create-namespace -n vela-system kubevela kubevela/vela-core --wait
 ```

versioned_docs/version-v1.8/platform-engineers/addon/intro.md

@@ -100,7 +100,7 @@ deployTo:
 
 dependencies:
 - name: addon_name
-  version: addon_version
+  version: ">= 1.0.0, < 2.0.0"
 
 system:
   vela: ">=v1.4.0"
@@ -119,7 +119,9 @@ Here's the usage of every field:
 |          icon           |    no    |               string                |                                                                                            Icon of the addon, will display in addon dashboard.                                                                                             |
 |           url           |    no    |               string                |                                                                                           The official website of the project behind the addon.                                                                                            |
 |          tags           |    no    |              []string               |                                                                                                The tags to display and organize the addon.                                                                                                 |
-|      dependencies       |    no    | []{ name: string, version: string } | Infos of other addons it depends on. You can specify the version of dependency addon by defining the `version` filed, otherwise would use latest one. KubeVela will make sure these dependencies are enabled before installing this addon. |
+|      dependencies[]     |    no    |          array of objects           | Addons which this addon depends upon. KubeVela will make sure these dependencies are enabled before installing this addon.                                                                                                                 |
+|   dependencies[].name   |   yes    |               string                | Name of the addon dependency.                                                                                                                                                                                                              |
+| dependencies[].version  |    no    |               string                | Required version constraints for the dependency. You can specify a range like ">= 1.0.0, < 2.0.0". KubeVela will select the latest version matching the constraints. If no constraint is given, KubeVela will select the latest version.   |
 |       system.vela       |    no    |               string                |                                                         Required version of vela controller, vela CLI will block the installation if vela controller can't match the requirements.                                                         |
 |    system.kubernetes    |    no    |               string                |                                                          Required version of Kubernetes, vela CLI will block the installation if Kubernetes cluster can't match the requirements.                                                          |
 | deployTo.runtimeCluster |    no    |                bool                 |        By default, the addon will not be installed in the managed clusters. If it's `true`, it will be delivered to all managed clusters automatically. (This field only take effect when application template file is YAML typed)         |

versioned_docs/version-v1.8/reference/addons/velaux.md

@@ -26,9 +26,11 @@ By default, VelaUX didn't have any exposed port.
 
 Port forward will work as a proxy to allow visiting VelaUX dashboard by local port.
 
-```bash
-vela port-forward addon-velaux -n vela-system 8000:8000
 ```
+vela port-forward addon-velaux -n vela-system
+```
+
+Choose `> local | velaux | velaux` for visit.
 
 ## Setup with Specified Service Type
 
@@ -49,23 +51,23 @@ If you want to expose your VelaUX dashboard for convenience, you can specify the
 
 After the service type specified to `LoadBalancer` or `NodePort`, you can obtain the access address through `vela status`:
 
-```bash
+```
 vela status addon-velaux -n vela-system --endpoint
 ```
 
 The expected output:
 
-```bash
+```
-+---------+---------------+-----------------------------------+--------------------------------+-------+
++----------------------------+----------------------+
-| CLUSTER |   COMPONENT   |     REF(KIND/NAMESPACE/NAME)      |            ENDPOINT            | INNER |
+|  REF(KIND/NAMESPACE/NAME)  |       ENDPOINT       |
-+---------+---------------+-----------------------------------+--------------------------------+-------+
++----------------------------+----------------------+
-| local   | velaux-server | Service/vela-system/velaux-server | velaux-server.vela-system:8000 | true  |
+| Service/vela-system/velaux | http://<IP address> |
-+---------+---------------+-----------------------------------+--------------------------------+-------+
++----------------------------+----------------------+
 ```
 
 ## Setup with Ingress domain
 
-If you have ingress and domain available in your cluster, you can also deploy VelaUX by specifying a domain like below:
+If you have ingress and domain available in your cluster, you can also deploy VelaUX by specify a domain like below:
 
 ```bash
 vela addon enable velaux domain=example.domain.com
@@ -73,16 +75,16 @@ vela addon enable velaux domain=example.domain.com
 
 The expected output:
 
-```bash
+```
 I0112 15:23:40.428364   34884 apply.go:106] "patching object" name="addon-velaux" resource="core.oam.dev/v1beta1, Kind=Application"
 I0112 15:23:40.676894   34884 apply.go:106] "patching object" name="addon-secret-velaux" resource="/v1, Kind=Secret"
 Addon: velaux enabled Successfully.
 Please access the velaux from the following endpoints:
-+-----------------------------------+---------------------------+
++----------------------------+---------------------------+
-|  REF(KIND/NAMESPACE/NAME)         |         ENDPOINT          |
+|  REF(KIND/NAMESPACE/NAME)  |         ENDPOINT          |
-+-----------------------------------+---------------------------+
++----------------------------+---------------------------+
-| Ingress/vela-system/velaux-server | http://example.domain.com |
+| Ingress/vela-system/velaux | http://example.domain.com |
-+-----------------------------------+---------------------------+
++----------------------------+---------------------------+
 ```
 
 If you enabled the traefik addon, you can set the `gatewayDriver` parameter to use the Gateway API.
@@ -170,13 +172,13 @@ spec:
         type: deploy
 ```
 
-After deployment, let's get the root password from the secret `vela-system/velaux-db-mongodb`.
+After deployed, let's get the root password from the secret `vela-system/velaux-db-mongodb`.
 
 ## Specify the addon image
 
 By default the image repo is docker hub, you can specify the image repo by the `repo` parameter:
 
-```bash
+```
 vela addon enable velaux repo=acr.kubevela.net
 ```
 

versioned_docs/version-v1.8/tutorials/helm.md

@@ -11,6 +11,7 @@ Starting from here, you will learn to use the KubeVela Addons to install plug-in
 ## Before starting
 
 - Choose a Helm Chart you want to deploy. In the tutorial, we take [bitnami/redis](https://github.com/bitnami/charts/tree/master/bitnami/redis) as an example.
+- If you are using [bitnami/redis](https://github.com/bitnami/charts/tree/master/bitnami/redis), check if the chart version you specified is still listed [here](https://artifacthub.io/packages/helm/bitnami/redis) and available.
 - Ensure that the cluster you deliver has a usable default StorageClass. Most of our delivery middleware requires data persistence, and the default StorageClass is needed to allocate PV.
 - Make sure you have VelaUX addon enabled for UI console. If you are only CLI users, you can skip to [Deploy via CLI](#deploy-via-cli)
   ```
@@ -52,7 +53,7 @@ spec:
         repoType: "helm"
         url: "https://charts.bitnami.com/bitnami"
         chart: "redis"
-        version: "16.8.5"
+        version: "17.7.3"
         values: 
           master:
             persistence:
@@ -235,4 +236,4 @@ spec:
 Your fluxcd addon version must be `1.3.1+`.
 :::
 
-Now, you have learned the basic helm delivery. If you want to delivery Helm Chart into multi-clusters, you can refer to [this blog](https://kubevela.io/blog/2022/07/07/helm-multi-cluster).
+Now, you have learned the basic helm delivery. If you want to delivery Helm Chart into multi-clusters, you can refer to [this blog](https://kubevela.io/blog/2022/07/07/helm-multi-cluster).

versioned_docs/version-v1.8/tutorials/sso.md

@@ -16,10 +16,13 @@ After the platform is initialized, local login is used by default. Platform admi
 
 ![alt](https://static.kubevela.net/images/1.3/dex-addon.png)
 
+2. After enabling the Dex Addon, we also need to upgrade the VelaUX addon and open its Dex option:
+
+![alt](https://static.kubevela.net/images/1.5/enable-dex-in-velaux.png)
+
 ## Configure Dex Connectors
 
 Next, we need to configure the Dex Connectors. 
-
 ### Configure GitHub Connector
 
 Take GitHub Connector as an example, if you don't have a GitHub Oauth App, you need to create an OAuth App on GitHub's Developer settings first, and set the App's Authorization callback URL to `[Vela UX address]/dex/callback`.

versions.json

@@ -2,4 +2,4 @@
   "v1.8",
   "v1.7",
   "v1.6"
-]
+]