This is an automated email from the ASF dual-hosted git repository.
duncangrant pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/brooklyn-docs.git
The following commit(s) were added to refs/heads/master by this push:
new 8931d81 Make a bunch of small editorial fixups
new f38fb8b Merge pull request #288 from infrastation/master
8931d81 is described below
commit 8931d81d701700425b550194be16035297891c21
Author: Denis Ovsienko <de...@ovsienko.info>
AuthorDate: Mon Aug 5 18:18:22 2019 +0100
Make a bunch of small editorial fixups
Fix some typos, punctuation and similar errors, put a hyperlink right,
reword some text for clarity. Do not add or remove content otherwise.
---
guide/blueprints/advanced-example.md | 6 +++---
guide/blueprints/clusters.md | 4 ++--
guide/blueprints/configuring-vms.md | 4 ++--
guide/blueprints/custom-entities.md | 4 ++--
guide/blueprints/test/index.md | 2 +-
guide/blueprints/yaml-reference.md | 4 ++--
guide/concepts/configuration-sensor-effectors.md | 2 +-
guide/ops/configuration/index.md | 2 +-
guide/start/managing.md | 4 ++--
guide/start/policies.md | 2 +-
10 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/guide/blueprints/advanced-example.md
b/guide/blueprints/advanced-example.md
index 19a9ef5..696e8ff 100644
--- a/guide/blueprints/advanced-example.md
+++ b/guide/blueprints/advanced-example.md
@@ -27,7 +27,7 @@ For more about the ELK stack, please see the documentation
[here](https://www.el
#### The Blueprints
-----------
-There are four blueprints that make up this application. Each of them are used
to add one or more catalog items to Brooklyn. You can find them below:
+There are four blueprints that make up this application. Each of them is used
to add one or more catalog items to Brooklyn. You can find them below:
* [Elasticsearch](example_yaml/brooklyn-elasticsearch-catalog.bom)
* [Logstash](example_yaml/brooklyn-logstash-catalog.bom)
@@ -36,7 +36,7 @@ There are four blueprints that make up this application. Each
of them are used t
#### Running the example
First, add all four blueprints to the Brooklyn Catalog. This can be done by
going to the "Catalog" module, then clicking the
-buttom "Upload to catalog" and selecting the above blueprints (or
drag-and-drop them) Once this is done, search for an
+button "Upload to catalog" and selecting the above blueprints (or
drag-and-drop them). Once this is done, search for an
entity called "ELK Stack". You will be able to deploy it by clicking on the
"Deploy" button from the details page.
Note that you can also perform this operation from the quick launch panel on
the homepage. Alternatively use the `br` Brooklyn
command line tool and add the files with `br catalog add`.
@@ -98,7 +98,7 @@ customize.command: |
The purpose of this section is to create a YAML file with all of the required
configuration. We use the YAML
literal style `|` indicator to write a multi line command. We start our series
of commands by using the `rm` command to remove the
previous config file. We then use `echo` and `tee` to create the new config
file and insert the config. Part
-of the configuration is a list of all hosts that is set on the parent entity-
this is done by using a combination
+of the configuration is a list of all hosts that is set on the parent entity –
this is done by using a combination
of the `component` and `attributeWhenReady` DSL commands. More on how this
is generated later.
##### Check running
diff --git a/guide/blueprints/clusters.md b/guide/blueprints/clusters.md
index 23281a2..e427b3d 100644
--- a/guide/blueprints/clusters.md
+++ b/guide/blueprints/clusters.md
@@ -58,11 +58,11 @@ The following configuration keys can be specified for
dynamic cluster:
### Effectors
-Dynamic cluster has a set of effectors which allow it's members to be
manipulated, these are detailed below.
+Dynamic cluster has a set of effectors which allow its members to be
manipulated, these are detailed below.
| Effector Name | Parameters | Description
|
|---------------|-------------|-----------------------------------------------------------------|
-| replaceMember | memberId | Replaces a specific member of the cluster
given by it's ID |
+| replaceMember | memberId | Replaces a specific member of the cluster
given its ID |
| resize | desiredSize | Resizes the cluster to a `desiredSize`
|
| resizeByDelta | delta | Resizes the cluster by a `delta`
|
diff --git a/guide/blueprints/configuring-vms.md
b/guide/blueprints/configuring-vms.md
index f856c86..43a9d89 100644
--- a/guide/blueprints/configuring-vms.md
+++ b/guide/blueprints/configuring-vms.md
@@ -7,13 +7,13 @@ Another simple blueprint will just create a VM which you can
use, without any so
!CODEFILE "example_yaml/simple-vm.yaml"
-*We've omitted the `location` section here and in many of the examples below;
+*We've omitted the `location` section here and in many of the examples
elsewhere;
add the appropriate choice when you paste your YAML. Note that the
`provisioning.properties` will be
ignored if deploying to `localhost` or `byon` fixed-IP machines.*
This will create a VM with the specified parameters in your choice of cloud.
In the GUI (and in the REST API), the entity is called "VM",
-and the hostname and IP address(es) are reported as
[sensors]({{book.path.docs}}/concepts/entities.md).
+and the hostname and IP address(es) are reported as
[sensors]({{book.path.docs}}/concepts/configuration-sensor-effectors.md).
There are many more `provisioning.properties` supported here,
including:
diff --git a/guide/blueprints/custom-entities.md
b/guide/blueprints/custom-entities.md
index e5ee183..dfd3d94 100644
--- a/guide/blueprints/custom-entities.md
+++ b/guide/blueprints/custom-entities.md
@@ -182,13 +182,13 @@ and if you haven't yet experimented with `resize` on the
cluster you might want
### Attaching Policies
Besides detecting this failure, Brooklyn policies can be added to the YAML to
take appropriate
-action. A simple recovery here might just to automatically restart the process:
+action. A simple recovery here might be just to restart the process
automatically:
!CODEFILE "example_yaml/vanilla-bash-netcat-restarter.yaml"
Autonomic management in Brooklyn often follows the principle that complex
behaviours emerge
from composing simple policies.
-The blueprint above uses one policy to triggering a failure sensor when the
service is down,
+The blueprint above uses one policy to trigger a failure sensor when the
service is down,
and another responds to such failures by restarting the service.
This makes it easy to configure various aspects, such as to delay to see if
the service itself recovers
(which here we've set to 15 seconds) or to bail out on multiple failures
within a time window (which again we are not doing).
diff --git a/guide/blueprints/test/index.md b/guide/blueprints/test/index.md
index 4f63d40..23a7768 100644
--- a/guide/blueprints/test/index.md
+++ b/guide/blueprints/test/index.md
@@ -23,7 +23,7 @@ Validation test entities include:
number of different formats: a string in the form of `ip:port` or URI
format; or a
`com.google.common.net.HostAndPort` instance; or a `java.net.URI` instance;
or a `java.net.URL` instance.
-TargetableTestComponents can be chained together, with the target being
inherited by the components children. For example, a ParallelTestCase could be
created that has a TestHttpCall as a child. As long as the TestHttpCall itself
does not have a target, it will use the target of it's parent,
ParallelTestCase. Using this technique, we can build up complex test scenarios.
+TargetableTestComponents can be chained together, with the target being
inherited by the components children. For example, a ParallelTestCase could be
created that has a TestHttpCall as a child. As long as the TestHttpCall itself
does not have a target, it will use the target of its parent, ParallelTestCase.
Using this technique, we can build up complex test scenarios.
The following sections provide details on each test entity along with examples
of their use.
diff --git a/guide/blueprints/yaml-reference.md
b/guide/blueprints/yaml-reference.md
index 21201df..50caa21 100644
--- a/guide/blueprints/yaml-reference.md
+++ b/guide/blueprints/yaml-reference.md
@@ -217,7 +217,7 @@ concise DSL defined here:
* `parent`: returns the parent entity (ignores the `ID`)
* `this`: returns this entity (ignores the `ID`)
* `$brooklyn:root()` will return the topmost entity (the application)
-* `$broopklyn:scopeRoot()` will return the root entity in the current plan
scope.
+* `$brooklyn:scopeRoot()` will return the root entity in the current plan
scope.
For catalog items it's the topmost entity in the plan, for application plans
it is the same as
`$brooklyn:root()`.
* `$brooklyn:formatString("pattern e.g. %s %s", "field 1", "field 2")` returns
a future which creates the formatted string
@@ -249,7 +249,7 @@ elements for more information:
which use `bash` commands to install and the PID to stop and restart
* **Chef** in `ChefSoftwareProcess`: makes it easy to use Chef cookbooks to
build entities,
either with recipes following conventions or with configuration in the
`ServiceSpecification`
- to use artibitrary recipes
+ to use arbitrary recipes
* `DynamicCluster`: provides resizable clusters given a
`dynamiccluster.memberspec` set with `$brooklyn.entitySpec(Map)` as described
above
* `DynamicFabric`: provides a set of homogeneous instances started in
different locations,
with an effector to `addLocation`, i.e. add a new instance in a given
location, at runtime
diff --git a/guide/concepts/configuration-sensor-effectors.md
b/guide/concepts/configuration-sensor-effectors.md
index 9bfc414..b0d9f9d 100644
--- a/guide/concepts/configuration-sensor-effectors.md
+++ b/guide/concepts/configuration-sensor-effectors.md
@@ -31,7 +31,7 @@ Sensors can be updated by the entity or associated tasks, and
sensors from an en
Effectors can be invoked by an entity's parent remotely, and the invoker is
able to track the execution of that effector. Effectors can be invoked by other
entities, but use this functionality with care to prevent too many managers!
-An entity consists of a Java interface (used when interacting with the entity)
and a Java class. For resilience. it is recommended to store
+An entity consists of a Java interface (used when interacting with the entity)
and a Java class. For resilience, it is recommended to store
the entity's state in attributes (see `getAttribute(AttributeKey)`). If
internal fields are used then the data will be lost on brooklyn
restart, and may cause problems if the entity is to be moved to a different
brooklyn management node.
diff --git a/guide/ops/configuration/index.md b/guide/ops/configuration/index.md
index 3815218..d6f6443 100644
--- a/guide/ops/configuration/index.md
+++ b/guide/ops/configuration/index.md
@@ -20,7 +20,7 @@ and manipulated by the `config:` commands, see the [Karaf
documentation](https:/
To configure the Brooklyn runtime create an `etc/brooklyn.cfg` file. If you
have previously used `brooklyn.properties` it follows the same
file format. Values can be viewed and managed dynamically via the OSGI
configuration admin commands in Karaf,
e.g. `config:property-set`. The global `~/.brooklyn/brooklyn.properties` is
still supported and has higher
-priority for duplicate keys, but it's values can't be manipulated with the
Karaf commands, so its use is
+priority for duplicate keys, but its values can't be manipulated with the
Karaf commands, so its use is
discouraged.
You can use the standard `~/.brooklyn/brooklyn.properties` file to configure
Brooklyn. Alternatively
diff --git a/guide/start/managing.md b/guide/start/managing.md
index eb5072c..a9438b5 100644
--- a/guide/start/managing.md
+++ b/guide/start/managing.md
@@ -1,7 +1,7 @@
-So far we have gone through Apache Brooklyn's ability to *deploy* an
application blueprint to a location, but this just
+So far we have gone through Apache Brooklyn's ability to *deploy* an
application blueprint to a location, but this is just
the beginning. Next we will outline how to *manage* the application that has
been deployed.
## Applications
@@ -188,7 +188,7 @@ stop Stop the process/service
represented by an ent
undeploy Undeploys the given context/artifact
targetName
```
-To view the details for a specific effector, append it's name to the command:
+To view the details for a specific effector, append its name to the command:
```
$ br application Tomcat entity tomcatServer effector deploy
diff --git a/guide/start/policies.md b/guide/start/policies.md
index fa98d3c..1ba1b15 100644
--- a/guide/start/policies.md
+++ b/guide/start/policies.md
@@ -277,7 +277,7 @@ The `DynamicCluster` can dynamically increase or decrease
the number of members.
cluster can either be carried out manually via effectors or automatically by
attaching an
`AutoScalerPolicy`.
-It is configured with a `dynamiccluster.memberspec`, which defines the type
and configurtion of members
+It is configured with a `dynamiccluster.memberspec`, which defines the type
and configuration of members
in the cluster. In our example, each is a Tomcat server with a WAR deployed at
the root URL.
Deploy the app:
