Chore(docs): fix typos in design docs (#2053)

2026-08-19 04:26:39 +00:00 · 2021-08-09 19:59:38 +08:00
parent e12a9303eb
commit a874aa3f71
6 changed files with 20 additions and 20 deletions
@@ -51,7 +51,7 @@ There are two distinguished layers:
 - **API layer**: It defines the API discovery and serving endpoints that Vela APIServer implementation must follow. This is the integration point for external system components (e.g. UI) to contact.
 - **Storage layer**: It describes the storage systems and objects that Vela APIServer syncs data with behind the scene. There are three types of storage:
  - **K8s cluster**: Vela APIServer manages multiple k8s clusters with regard to the applications and definitions custom resources.
-  - **Catalog server**: Vela APIServer manages multiple catalogs which contain COTS application pacakges. Currently in our use case the catalogs resides in Git repos. In the future we can extend this to other catalog storage like file server, object storage.
+  - **Catalog server**: Vela APIServer manages multiple catalogs which contain COTS application packages. Currently in our use case the catalogs resides in Git repos. In the future we can extend this to other catalog storage like file server, object storage.
  - **MySQL database**: Vela APIServer stores global, cross-cluster, cross catalog information in a MySQL database. These data do not exist in k8s or catalog and thus need to be managed by APIServer in a separate database. The database is usually hosted on cloud.

 #### Environment API
@@ -134,7 +134,7 @@ Application is a global unit to manage cross-cluster, cross-namespace applicatio
    {
      "id": "cluster-1",

-      // The definitions indicate the capabilties enabled in this cluster
+      // The definitions indicate the capabilities enabled in this cluster
      "definitions": [
        {
          "id": "def-1"
@@ -301,7 +301,7 @@ The structure of one package version contains:

 Please refer to `/catalogs/<catalog>` API endpoint above.

-Under the hood, APIServer will scan the catalog repo based on the predefined structure to parse each packag and versions.
+Under the hood, APIServer will scan the catalog repo based on the predefined structure to parse each packages and versions.

 #### Sync a catalog in APIServer

@@ -78,7 +78,7 @@ By default, the mechanism is disabled, vela-core will always reconcile and apply

 In each round of reconciliation, vela-core compares below Labels & Annotations of existing workload/trait with newly rendered ones before applying.

-After deploying the ApplicationConfiguration in the motivational example, the Deployment created by vela-core will have such lables and annotations.
+After deploying the ApplicationConfiguration in the motivational example, the Deployment created by vela-core will have such labels and annotations.


 ```yaml
@@ -102,7 +102,7 @@ metadata:

 These crucial two are propogated from AppConfig and Component during reconciliation.
 Any change applied to the Deployment directly has no impact on these labels and annotations, e.g., change the Deployment spec just like what we do in the [motivational example](#a-motivational-example).
-If `--apply-once-only` is enabled, since no discrepancy is found on lables and annotations, 
+If `--apply-once-only` is enabled, since no discrepancy is found on labels and annotations, 
 vela-core controller will ignore applying the Deployment and leave it as what it is at that moment.

 By contrast, changes on AppConfig (changing `spec` creates new generation) and Component (updating Component creates new revision) will change the value of these labels and annotations.
@@ -27,7 +27,7 @@ Meanwhile, Apply should have no impact on changes made by others, namely, not el
 ## Implementation

 We employed the same mechanism as `kubectl apply`, that is, computing a 3-way diff based on target object's current state, modified state, and last-appied state. 
-Specifically, a new annotaion, `app.oam.dev/last-applied-configuration`, is introduced to record workload/trait's last-applied state.
+Specifically, a new annotation, `app.oam.dev/last-applied-configuration`, is introduced to record workload/trait's last-applied state.

 Once there's a conflict on field, both changed by AppConfig and others, AppConfig's value will always override others' assignment. 

@@ -44,7 +44,7 @@ The reason why abandon json-merge patch is that, it cannot remove a field throug

 #### Before

-For example, apply below deployment as a workload. json-merge patch cannot remove `minReadySeconds` field through applying a modifiied manifest with `minReadySeconds` omitted .
+For example, apply below deployment as a workload. json-merge patch cannot remove `minReadySeconds` field through applying a modified manifest with `minReadySeconds` omitted .
 ```yaml
 # original workload manifest
 apiVersion: apps/v1
@@ -1,4 +1,4 @@
-# Initilizing Environments For Application Deployment
+# Initializing Environments For Application Deployment

 ## Background

@@ -23,7 +23,7 @@ With the introduction of environment, the user workflow on Vela works like:
 - Platform team defines system Components for Environments.
 - Platform team initializes Environments using system Components.
 - Platform team defines user Components for Applications.
- Developers choose user Components and Environments to deploy Applicatons.
+- Developers choose user Components and Environments to deploy Applications.

 When initializing environments, there are additional requirements:

@@ -32,7 +32,7 @@ When initializing environments, there are additional requirements:

 In the following we propose solutions to implement environment concept for application delivery.

-## Initialzer CRD
+## Initializer CRD

 We propose to add an Initializer CRD:

@@ -174,7 +174,7 @@ spec:
      properties:
        # This app will be checked against the policies in the given target
        target: prod-env
-        # If policy checks failed, send alerts to spcified channels
+        # If policy checks failed, send alerts to specified channels
        notifications:
          slack: slack_url
          dingding: dingding_url
@@ -276,7 +276,7 @@ type oamDefinition struct {
 **Responses Body** : 
 ```go
 type definition struct {
-    definition runtime.RawExtension `json:"definition"` // either the full definition or the cueTempalte
+    definition runtime.RawExtension `json:"definition"` // either the full definition or the cueTemplate
 }
 ```

@@ -349,7 +349,7 @@ type oamDefinition struct {
 **Responses Body** : 
 ```go
 type definition struct {
-    definition runtime.RawExtension `json:"definition"` // either the full definition or the cueTempalte
+    definition runtime.RawExtension `json:"definition"` // either the full definition or the cueTemplate
 }
 ```

@@ -27,7 +27,7 @@ To resolve the aforementioned problems, we propose to add app-level policies and
 ```yaml
 kind: Application
 spec:
-  componnets: ...
+  components: ...

  # Policies are rendered after components are rendered but before workflow are started
  policies:
@@ -71,7 +71,7 @@ spec:

    # promote/rollback
    - type: rollout-promotion
-      propertie:
+      properties:
        manualApproval: true
        rollbackIfNotApproved: true
 ```
@@ -122,7 +122,7 @@ spec:
          resource: context.workload
        }

-        wait: op.#CondtionalWait & {
+        wait: op.#ConditionalWait & {
          continue: apply.status.ready == true
        }

@@ -364,7 +364,7 @@ status:
 ```yaml
 kind: Application
 spec:
-  componnets: ...
+  components: ...
 workflow:
  steps:
  - name: manual-approve
@@ -408,7 +408,7 @@ status:

 2. The application spec changes

-The spec change also means that the application needs to be re-executed, and the application controller will clear the staus of application includes workflow status.
+The spec change also means that the application needs to be re-executed, and the application controller will clear the status of application includes workflow status.


 ## Operator Best Practice
@@ -486,7 +486,7 @@ workflow:

  # promote/rollback
  - type: rollout-promotion
-    propertie:
+    properties:
      manualApproval: true
      rollbackIfNotApproved: true
 ```
@@ -579,7 +579,7 @@ workflow:

 The process goes as:

- Everytime an Appliation event is triggered, the GitOps workflow controller will push the rendered resources to a Git repo. This will trigger ArgoCD/Flux to do continuous deployment.
+- Everytime an Application event is triggered, the GitOps workflow controller will push the rendered resources to a Git repo. This will trigger ArgoCD/Flux to do continuous deployment.

 ### Case 5: Template-based rollout