From bb350998f48fd013dd111592f77bdde2bc1c788c Mon Sep 17 00:00:00 2001 From: JT Gray Date: Sun, 24 Jan 2016 20:28:58 -0500 Subject: [PATCH] Fixing typos --- source/guide/3.0/understanding-blueprints.md | 24 ++++++++--------- source/guide/3.1/understanding-blueprints.md | 28 ++++++++++---------- 2 files changed, 26 insertions(+), 26 deletions(-) diff --git a/source/guide/3.0/understanding-blueprints.md b/source/guide/3.0/understanding-blueprints.md index 270cae718..d71181aa8 100644 --- a/source/guide/3.0/understanding-blueprints.md +++ b/source/guide/3.0/understanding-blueprints.md @@ -38,7 +38,7 @@ A Topology is a graph of application components and their relationships describe Components can be of 3 levels: -* **Infrastructrue** - Components provided by the IaaS layer (e.g. VM, virtual network, virtual load balancer or storage volume) or by non-cloud phyiscal or virtualized layer (e.g. Host and storage voluem) +* **Infrastructure** - Components provided by the IaaS layer (e.g. VM, virtual network, virtual load balancer or storage volume) or by non-cloud physical or virtualized layer (e.g. Host and storage volume) * **Platform / Middleware** - Components that serve as the application containers (such as webservers, application servers, message servers and database servers) @@ -70,11 +70,11 @@ Each `node` is an instance of a `type`. A `type` can be defined in the blueprint There are two types of `type`: portable and concerete. -A portable type that has no implementation details. For examply `cloudify.types.host` is an abstract type. It doesn't have any implementation details advising the orchestrator how to materialize an instance of it on a particular environment. A portable type will declare an `interface` a set of hooks named `operations` that can be implemented by concrete types using a `operation` mapping to `plugin` methods. For example `cloudify.openstack.server` is an `Openstack` implementation of `cloudify.types.host` using a `plugin` that uses the `Nova` compute API. +A portable type that has no implementation details. For example `cloudify.types.host` is an abstract type. It doesn't have any implementation details advising the orchestrator how to materialize an instance of it on a particular environment. A portable type will declare an `interface` a set of hooks named `operations` that can be implemented by concrete types using a `operation` mapping to `plugin` methods. For example `cloudify.openstack.server` is an `Openstack` implementation of `cloudify.types.host` using a `plugin` that uses the `Nova` compute API. -* Abstract types are mainly used as marking interfaces for the user to know which type of compentent the concrete type represents +* Abstract types are mainly used as marking interfaces for the user to know which type of component the concrete type represents -* Use concrete types with your blueprint to make them more easy to read. Use protable nodes ONLY if you plan to deploy the same blueprint on different clouds. +* Use concrete types with your blueprint to make them more easy to read. Use portable nodes ONLY if you plan to deploy the same blueprint on different clouds. ## The lifecycle Interface The `cloudify.types.base_type` declares the `lifecycle` interface which all types inherit. This interface has the most essential installation and uninstallation hooks. The cloudify built-in `install` and `uninstall` workflows use these hooksto deploy and undeploy applications. @@ -88,7 +88,7 @@ The operations for this interface are: ## Node Properties The `node` `properties` section is a YAML `map`. It can be as nested map as you want. Node properties are defined by the `type` this node is instance of. Usually, the `node` properties will be only ones that are indifferent to the underlying cloud or to the tool used to materialize the component. For example a webserver port property is indifferent to any infrastructure or tool (while image_id is a term for specific clouds and the value differes from one cloud to another) -The `type implementation` which is specific for a particular environment or toolchain will have sepcific properties decalred by the concrete type and specific values for this particular instance. +The `type implementation` which is specific for a particular environment or toolchain will have specific properties declared by the concrete type and specific values for this particular instance. **Cloudify enforces the first level properties declared by types as a schema** @@ -107,26 +107,26 @@ In this case Cloudify will deploy 4 instances of the frontend_host or in other w ## Relationships -Relationshipd secribes the type of dependency between 2 nodes. There are 3 types of abstract built-inrealtionships: +Relationship describes the type of dependency between 2 nodes. There are 3 types of abstract built-in relationships: * `contained_in` : when one node is installed on another node. for example an apache webserver is installed on a VM. A WAR file is deployed on a Tomcat server, etc. This `relationship` ensures that the `target node` will exist before attempting to create the `source node` * `connected_to` : when one node needs a connection to another node. For example a Tomcat server needs a JDBC connection to a mySQL database server. The relationship allows the user to configure the `source node`, the `target node` or both of them before starting these nodes. It also helps to pass runtime information to the `source node` about the `target node` -* `depends_on` : when one node must be started or created after another node already exist, but without any connection between them +* `depends_on` : when one node must be started or created after another node already exist, but without any connection between them ### Concrete relationship types -The above abstract rerltionship types do not provide the implementations for a specific relationship configuration +The above abstract relationship types do not provide the implementations for a specific relationship configuration For example a connected_to can be a JDBC connection to Oracle or a connection to MongoDb or even a connection between subnet and a router on a specific cloud. There is a need for concrete repationship types that will use concrete plugins to configure specific types of relationships ### Relationship Interface -The realtionship interface is optional. In many cases you don't need to perform any special actions, you just expect the orchestrator to time right the creation and startup of components. However, in cases you do need to change configration in order to wire together two components, the relationship interface and the workflow mechnism for using it come-in handy. +The relationship interface is optional. In many cases you don't need to perform any special actions, you just expect the orchestrator to time right the creation and startup of components. However, in cases you do need to change configuration in order to wire together two components, the relationship interface and the workflow mechanism for using it come-in handy. -The interface decalres the following operations (on source and on target separately) +The interface declares the following operations (on source and on target separately) * `preconfigure` - actions to perform before configuring the component * `postconfigure` - actions to perform after configuring the component @@ -144,7 +144,7 @@ In many cases you will not see any `workflows` section in the `blueprint`. In th ## What is a Workflow? A `workflow` is an orchestration algorithm written in a lnaguage that a workflow can execute. -In the case of Cloudify it is a Pyhton script using dedicated Cloudify APIs and DOM (Domain Object Model) +In the case of Cloudify it is a Python script using dedicated Cloudify APIs and DOM (Domain Object Model) ## Built-in Workflows Currently Cloudify comes with 2 built-in workflows: @@ -154,7 +154,7 @@ Currently Cloudify comes with 2 built-in workflows: * uninstall - a workflow that gracefully uninstalls an application ## Custom Workflows -In order to add a custom workflow you need to create a rdial script in the same folder of your `blueprint` +In order to add a custom workflow you need to create a radial script in the same folder of your `blueprint` Inside the blueprint add the following block: {% highlight YAML %} diff --git a/source/guide/3.1/understanding-blueprints.md b/source/guide/3.1/understanding-blueprints.md index 92b8f5fd1..3251c767b 100644 --- a/source/guide/3.1/understanding-blueprints.md +++ b/source/guide/3.1/understanding-blueprints.md @@ -35,7 +35,7 @@ A Topology is a graph of application components and their relationships describe Components can be of 3 levels: -* **Infrastructrue** - Components provided by the IaaS layer (e.g. VM, virtual network, virtual load balancer or storage volume) or by non-cloud phyiscal or virtualized layer (e.g. Host and storage voluem) +* **Infrastructure** - Components provided by the IaaS layer (e.g. VM, virtual network, virtual load balancer or storage volume) or by non-cloud physical or virtualized layer (e.g. Host and storage volume) * **Platform / Middleware** - Components that serve as the application containers (such as webservers, application servers, message servers and database servers) @@ -67,11 +67,11 @@ Each `node` is an instance of a `type`. A `type` can be defined in the blueprint There are two types of `type`: portable and concerete. -A portable type that has no implementation details. For examply `cloudify.nodes.Compute` is an abstract type. It doesn't have any implementation details advising the orchestrator how to materialize an instance of it on a particular environment. A portable type will declare an `interface` a set of hooks named `operations` that can be implemented by concrete types using a `operation` mapping to `plugin` methods. For example `cloudify.openstack.nodes.Server` is an `Openstack` implementation of `cloudify.nodes.Compute` using a `plugin` that uses the `Nova` compute API. +A portable type that has no implementation details. For example `cloudify.nodes.Compute` is an abstract type. It doesn't have any implementation details advising the orchestrator how to materialize an instance of it on a particular environment. A portable type will declare an `interface` a set of hooks named `operations` that can be implemented by concrete types using a `operation` mapping to `plugin` methods. For example `cloudify.openstack.nodes.Server` is an `Openstack` implementation of `cloudify.nodes.Compute` using a `plugin` that uses the `Nova` compute API. -* Abstract types are mainly used as marking interfaces for the user to know which type of compentent the concrete type represents +* Abstract types are mainly used as marking interfaces for the user to know which type of component the concrete type represents -* Use concrete types with your blueprint to make them more easy to read. Use protable nodes ONLY if you plan to deploy the same blueprint on different clouds. +* Use concrete types with your blueprint to make them more easy to read. Use portable nodes ONLY if you plan to deploy the same blueprint on different clouds. ## The lifecycle Interface The `cloudify.nodes.Root` declares the `lifecycle` interface which all types inherit. This interface has the most essential installation and uninstallation hooks. The cloudify built-in `install` and `uninstall` workflows use these hooksto deploy and undeploy applications. @@ -85,7 +85,7 @@ The operations for this interface are: ## Node Properties The `node` `properties` section is a YAML `map`. It can be as nested map as you want. Node properties are defined by the `type` this node is instance of. Usually, the `node` properties will be only ones that are indifferent to the underlying cloud or to the tool used to materialize the component. For example a webserver port property is indifferent to any infrastructure or tool (while image_id is a term for specific clouds and the value differes from one cloud to another) -The `type implementation` which is specific for a particular environment or toolchain will have sepcific properties decalred by the concrete type and specific values for this particular instance. +The `type implementation` which is specific for a particular environment or toolchain will have specific properties declared by the concrete type and specific values for this particular instance. **Cloudify enforces the first level properties declared by types as a schema** @@ -104,26 +104,26 @@ In this case Cloudify will deploy 4 instances of the frontend_host or in other w ## Relationships -Relationshipd secribes the type of dependency between 2 nodes. There are 3 types of abstract built-inrealtionships: +Relationship describes the type of dependency between 2 nodes. There are 3 types of abstract built-in relationships: * `contained_in` : when one node is installed on another node. for example an apache webserver is installed on a VM. A WAR file is deployed on a Tomcat server, etc. This `relationship` ensures that the `target node` will exist before attempting to create the `source node` * `connected_to` : when one node needs a connection to another node. For example a Tomcat server needs a JDBC connection to a mySQL database server. The relationship allows the user to configure the `source node`, the `target node` or both of them before starting these nodes. It also helps to pass runtime information to the `source node` about the `target node` -* `depends_on` : when one node must be started or created after another node already exist, but without any connection between them +* `depends_on` : when one node must be started or created after another node already exist, but without any connection between them ### Concrete relationship types -The above abstract rerltionship types do not provide the implementations for a specific relationship configuration -For example a connected_to can be a JDBC connection to Oracle or a connection to MongoDb or even a connection between subnet and a router on a specific cloud. There is a need for concrete repationship types that will use concrete plugins to configure specific types of relationships +The above abstract relationship types do not provide the implementations for a specific relationship configuration +For example a connected_to can be a JDBC connection to Oracle or a connection to MongoDb or even a connection between subnet and a router on a specific cloud. There is a need for concrete relationship types that will use concrete plugins to configure specific types of relationships ### Relationship Interface -The realtionship interface is optional. In many cases you don't need to perform any special actions, you just expect the orchestrator to time right the creation and startup of components. However, in cases you do need to change configration in order to wire together two components, the relationship interface and the workflow mechnism for using it come-in handy. +The relationship interface is optional. In many cases you don't need to perform any special actions, you just expect the orchestrator to time right the creation and startup of components. However, in cases you do need to change configuration in order to wire together two components, the relationship interface and the workflow mechanism for using it come in handy. -The interface decalres the following operations (on source and on target separately) +The interface declares the following operations (on source and on target separately) * `preconfigure` - actions to perform before configuring the component * `postconfigure` - actions to perform after configuring the component @@ -137,11 +137,11 @@ The interface decalres the following operations (on source and on target separat Cloudify can orchestrate any process described in a `workflow` workflows can be explictly listed in the `workflows` section of the `blueprint` -In many cases you will not see any `workflows` section in the `blueprint`. In this case Cloudify assumes you are allowd to run the built-in workflows on the topology `nodes` listed in this `blueprint` +In many cases you will not see any `workflows` section in the `blueprint`. In this case Cloudify assumes you are allowed to run the built-in workflows on the topology `nodes` listed in this `blueprint` ## What is a Workflow? A `workflow` is an orchestration algorithm written in a lnaguage that a workflow can execute. -In the case of Cloudify it is a Pyhton script using dedicated Cloudify APIs and DOM (Domain Object Model) +In the case of Cloudify it is a Python script using dedicated Cloudify APIs and DOM (Domain Object Model) ## Built-in Workflows Currently Cloudify comes with 2 built-in workflows: @@ -151,7 +151,7 @@ Currently Cloudify comes with 2 built-in workflows: * uninstall - a workflow that gracefully uninstalls an application ## Custom Workflows -In order to add a custom workflow you need to create a rdial script in the same folder of your `blueprint` +In order to add a custom workflow you need to create a radial script in the same folder of your `blueprint` Inside the blueprint add the following block: {% highlight YAML %}