Merge pull request #2595 from open-horizon/Fix_typos_in_docs

Fix typos in anax docs

docs/api.md

@@ -1785,7 +1785,7 @@ Set the node's user input for the service configuration. The node on the exchang
 
 body:
 
-The bosy is an array of the following: 
+The body is an array of the following: 
 
 | name | type | description |
 | ---- | ---- | ---------------- |
@@ -1830,7 +1830,7 @@ Patch the node's user input for the service configuration. The node on the excha
 
 body:
 
-The bosy is an array of the following: 
+The body is an array of the following: 
 
 | name | type | description |
 | ---- | ---- | ---------------- |
@@ -1966,7 +1966,7 @@ Set the node policy. The node on the exchange will be updated too with the new p
 
 body:
 
-The bosy is an array of the following: 
+The body is an array of the following: 
 
 | name | type | description |
 | ---- | ---- | ---------------- |
@@ -2011,7 +2011,7 @@ Patch the properties or the constraints for the node policy. The node on the exc
 
 body:
 
-The bosy is an array of the following: 
+The body is an array of the following: 
 
 | name | type | description |
 | ---- | ---- | ---------------- |

docs/attributes.md

@@ -25,7 +25,7 @@ Valid values are:
 * [MeteringAttributes](#ma)
 * [AgreementProtocolAttributes](#agpa)
 
-Each attrinbute type is described in it's own section below.
+Each attribute type is described in it's own section below.
 
 The `label` field is a string that is displayed in the Horizon user interface when working with this attribute.
 
@@ -48,7 +48,7 @@ The value for `publishable` should be `true`.
 
 The value for `host_only` should be `false`.
 
-The `service_specs` specifies what services the attribue applies to. If the `url` is an empty string, it applies to all the services. If you set the UserInputAttributes through the `/service/config` api, you do not need to specify the `service_specs` because the service is specified in other fields. However, if you use `/attribute` api to set the UserInputAttributes, you must specify the `service_specs`. 
+The `service_specs` specifies what services the attribute applies to. If the `url` is an empty string, it applies to all the services. If you set the UserInputAttributes through the `/service/config` api, you do not need to specify the `service_specs` because the service is specified in other fields. However, if you use `/attribute` api to set the UserInputAttributes, you must specify the `service_specs`. 
 
 The variables you can set are defined by the service definition.
 Suppose the service definition contained the following userInputs section:
@@ -222,11 +222,11 @@ The variables that can be configured are:
 * `tokens` - The number of tokens to be granted per unit time as specified below.
 * `perTimeUnit` - The unit of time over which the tokens are granted. Valid values are: `min`, `hour`, `day`.
 * `notificationInterval` - An integer indication how often, in seconds, the agbot should notify the node that tokens are being granted.
-* `service_specs` - An array specifies what services the attribue applies to. If the `url` is an empty string, it applies to all the services. If you set the MeteringAttributes through the `/service/config` api, you do not need to specify the `service_specs` because the service is specified in other fields. However, if you use `/attribute` api to set the MeteringAttributes, you must specify the `service_specs`. 
+* `service_specs` - An array specifies what services the attribute applies to. If the `url` is an empty string, it applies to all the services. If you set the MeteringAttributes through the `/service/config` api, you do not need to specify the `service_specs` because the service is specified in other fields. However, if you use `/attribute` api to set the MeteringAttributes, you must specify the `service_specs`. 
 
 If the agbot also specifies a metering policy, the metering attributes specified by the node must be satisfied by the agbot's policy.
 If a nodes wants more token per unit time than the agbot is willing to provide, then an agreement cannot be made.
-If an agbot is able to satisfy the node, then the tokens per unit time specified by the node willbe used.
+If an agbot is able to satisfy the node, then the tokens per unit time specified by the node will be used.
 
 For example, the service wants the agbot to grant 2 tokens per hour, and notify the mode that the agreement is still valid every hour (3600 seconds).
 ```
@@ -257,7 +257,7 @@ By default, the Horizon system uses the "Basic" protocol (which requires nothing
 
 Agreement protocols are chosen by the agbot based on the order they appear in the node's service's attributes.
 
-The `service_specs` specifies what services the attribue applies to. If the `url` is an empty string, it applies to all the services. If you set the AgreementProtocolAttributes through the `/service/config` api, you do not need to specify the `service_specs` because the service is specified in other fields. However, if you use `/attribute` api to set the AgreementProtocolAttributes, you must specify the `service_specs`. 
+The `service_specs` specifies what services the attribute applies to. If the `url` is an empty string, it applies to all the services. If you set the AgreementProtocolAttributes through the `/service/config` api, you do not need to specify the `service_specs` because the service is specified in other fields. However, if you use `/attribute` api to set the AgreementProtocolAttributes, you must specify the `service_specs`. 
 
 ```
     {

docs/deployment_policy.md

@@ -6,7 +6,7 @@ A deployment policy is just one aspect of the deployment capability, and is desc
 Use the `hzn exchange deployment new` command to generate an empty deployment policy.
 The `hzn dev service new` command will also generate a deployment policy along with a new service.
 
-Use the `hzn deploycheck` command to evaluate the compatibility of your deployment policy with the node where you want the service to be dpeloyed.
+Use the `hzn deploycheck` command to evaluate the compatibility of your deployment policy with the node where you want the service to be deployed.
 
 Following are the fields in the JSON representation of a deployment policy:
 - `label`: A short description of the deployment policy suitable to be displayed in a UI. This field is not required.
@@ -18,10 +18,10 @@ Following are the fields in the JSON representation of a deployment policy:
   - `serviceVersions`: A list of versions of the service. At least 1 version MUST be specified.
     - `version`: One of the versions of the service in `name`. This is the same value as found in the `version` field [here](./service_def.md).
     - `priority`: The relative priority of deploying this version over another version in the list of service versions.
-      - `priority_value`: The priority value assigned to this version. Priority is expressed in human terms, where a lower ordinal value means higher priority. Priority values within the list are not required to be sequential, just unique within the list. When deploying a service, OpenHorizon will attempt to deploy the higest priority version first. If the service is not successfully started, the next highest version will be attempted.
+      - `priority_value`: The priority value assigned to this version. Priority is expressed in human terms, where a lower ordinal value means higher priority. Priority values within the list are not required to be sequential, just unique within the list. When deploying a service, OpenHorizon will attempt to deploy the highest priority version first. If the service is not successfully started, the next highest version will be attempted.
       - `retries`: The number of times to retry starting a failed service.
       - `retry_durations`: The number of seconds (i.e. elapsed time) in which the indicated number of `retries` must occur before giving up and moving on to the next highest priority service version.
-  - `nodeHealth`: For nodes that are expected to remain network connected to the management, these setting indicate how agressive the Agbot should be in determining if a node is out of policy.
+  - `nodeHealth`: For nodes that are expected to remain network connected to the management, these setting indicate how aggressive the Agbot should be in determining if a node is out of policy.
     - `missing_heartbeat_interval`: The number of seconds a heartbeat can be missed (from the perspective of the management hub) until the node is considered missing. When a node is detected as missing, its agreements are cancelled by the Agbot.
     - `check_agreement_status`: The number of seconds between checks (by the management hub) to verify that the node still has an agreement for this service.
 - `properties`: Policy properties as described [here](./properties_and_constraints.md) which a node policy constraint can refer to.
@@ -38,7 +38,7 @@ Following are the fields in the JSON representation of a deployment policy:
 The following is an example of a deployment policy that deploys a service called `my.company.com.service.this-service`.
 The service is defined within organization `yourOrg`.
 This policy will deploy the service to any node which matches one of the architectures for which the service is defined, and is also compatible with nodes that have the property `aNodeProperty` set to `someValue`.
-Two versions of the service are mentioned, with version `2.3.1` having a higher priority for dpeloyment than version `2.3.0`.
+Two versions of the service are mentioned, with version `2.3.1` having a higher priority for deployment than version `2.3.0`.
 The deployed service is dependent on service `my.company.com.service.other` which has a variable `var1` that needs to be set in order for it to deploy correctly.
 ```
 {
@@ -96,4 +96,4 @@ The deployed service is dependent on service `my.company.com.service.other` whic
     }
   ]
 }
-```
+```

docs/deployment_string.md

@@ -37,7 +37,7 @@ Because Horizon uses the Docker API to start the containers on an edge node, man
     - `network`: `"host"` - start the container with host network mode. When network is set to host, the service can only be deployed to nodes with property openhorizon.allowPrivileged set to true.
     - `entrypoint`: `["executable", "param1", "param2"]` - override ENTRYPOINT specified in the dockerfile.
     - `max_memory_mb`: `4096` - the maximum amount of memory the service's container can use
-    - `max_cpus`: `1.5` - how much of the available CPU resources ther service's container can use. For instance, if the host machine has two CPUs and you set value to 1.5, the container is guaranteed to use at most one and a half of the CPUs
+    - `max_cpus`: `1.5` - how much of the available CPU resources the service's container can use. For instance, if the host machine has two CPUs and you set value to 1.5, the container is guaranteed to use at most one and a half of the CPUs
     - `log_driver`: the logging driver (e.g. `json-file`) to use for container logs, instead of default one (syslog)
 
 ## clusterDeployment String Fields

docs/model_policy.md

@@ -1,10 +1,10 @@
 # Model Object
 
 Model objects in OpenHorizon are the metadata representation of application metadata objects.
-Applications are often written such that external metadata can be injected into the applciation in order to alter the behavior of the logic.
+Applications are often written such that external metadata can be injected into the application in order to alter the behavior of the logic.
 This is notably true in the case of machine learning and AI inferencing, where the logic which analyzes a data stream is instructed via a machine learning model how to process the data to derive an analysis result.
 OpenHorizon allows application to be structured using this metadata driven approach, by supporting the ability to deploy the application's metadata on different lifecycle boundaries than the service (inferencing logic) which consumes the metadata.
-In OpenHorizon the application's metadata is called a model, and it is represented by a model objct with the JSON serialization shown below.
+In OpenHorizon the application's metadata is called a model, and it is represented by a model object with the JSON serialization shown below.
 
 One aspect of the model object is the policy expressions it contains. The OpenHorizon policy based, autonomous deployment capability is described [here](./policy.md).
 The key to understanding model policy is remember that models are associated with services, and thus follow those services in terms of where the services are deployed.
@@ -22,7 +22,7 @@ Following are the fields in the JSON representation of a model object:
 - `destinationPolicy`:
   - `properties`: Policy properties as described [here](./properties_and_constraints.md) which a node policy constraint can refer to.
   - `constraints`: Policy constraints as described [here](./properties_and_constraints.md) which refer to node policy properties.
-  - `services`: A list of services which can consume the associate dmodel object.
+  - `services`: A list of services which can consume the associated model object.
     - `serviceName`: The name of the service that will consume the model object. This is the same value as found in the `url` field [here](./service_def.md).
     - `orgID` : The organization in which the service in `serviceName` is defined.
     - `version`: A version range indicating the set of service versions with which this model object is associated.
@@ -59,4 +59,4 @@ The model object associated with this policy will be deployed on nodes where the
   },
   "version": "1.0.0"
 }
-```
+```

docs/properties_and_constraints.md

@@ -98,12 +98,12 @@ Each property type has operators that can be used to evaluate property values:
 * `version` - supports `==, =, in` where `in` is used to indicate that a version is within a given range, e.g. any version 1 service is specified as: "[1.0.0,2.0.0)".
 * `list of strings` - supports `in` where the property has one of the values specified in the constraint.
 
-The JSON represenation of a constraint is:
+The JSON representation of a constraint is:
 ```
 [
 	"<constraint-expression-one>",
 	"<constraint-expression-two>", ...
 ]
 ```
 
-Constraint expressions that appears in a list are logically ANDed together to produce a single true or false result.
+Constraint expressions that appears in a list are logically ANDed together to produce a single true or false result.

docs/service_def.md

@@ -5,7 +5,7 @@ Services are defined by a service definition, encoded in JSON. The attributes of
 
 ## Structure
 
-Service defintions come in 2 forms;
+Service definitions come in 2 forms;
 - `source`: A service definition file that is part of the source code in a service project, e.g. https://github.com/open-horizon/examples/blob/master/edge/services/helloworld/horizon/service.definition.json.
 In this case, the service definition is used to create or update a service definition in the OpenHorizon Exchange.
 - `display`: A service definition displayed by `hzn exchange service list`.