diff --git a/design/vela-core/APIServer-Catalog.md b/design/vela-core/APIServer-Catalog.md index 2d82e47ff..ac899016b 100644 --- a/design/vela-core/APIServer-Catalog.md +++ b/design/vela-core/APIServer-Catalog.md @@ -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/` 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 diff --git a/design/vela-core/apply-once-only.md b/design/vela-core/apply-once-only.md index 850f8cfe6..6fc073e51 100644 --- a/design/vela-core/apply-once-only.md +++ b/design/vela-core/apply-once-only.md @@ -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. diff --git a/design/vela-core/apply-workload-and-trait.md b/design/vela-core/apply-workload-and-trait.md index 2eb649741..2f8ecd908 100644 --- a/design/vela-core/apply-workload-and-trait.md +++ b/design/vela-core/apply-workload-and-trait.md @@ -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 diff --git a/design/vela-core/environment.md b/design/vela-core/environment.md index 5ca2bb500..b4b01c6c3 100644 --- a/design/vela-core/environment.md +++ b/design/vela-core/environment.md @@ -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 diff --git a/design/vela-core/restful-interface.md b/design/vela-core/restful-interface.md index c89dffe48..7fcee7a35 100644 --- a/design/vela-core/restful-interface.md +++ b/design/vela-core/restful-interface.md @@ -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 } ``` diff --git a/design/vela-core/workflow_policy.md b/design/vela-core/workflow_policy.md index ce4731940..88a69c443 100644 --- a/design/vela-core/workflow_policy.md +++ b/design/vela-core/workflow_policy.md @@ -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