[brooklyn-docs] branch master updated: Make a few more editorial fixups

[du...@apache.org]

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 8ea4802  Make a few more editorial fixups
     new 11112d3  Merge pull request #290 from infrastation/master
8ea4802 is described below

commit 8ea4802e706e1a9f6ff4bb1cfb5bade03d8e7973
Author: Denis Ovsienko <de...@ovsienko.info>
AuthorDate: Thu Aug 8 13:49:42 2019 +0100

    Make a few more editorial fixups
    
    Spell GB, hierarchy, MariaDB and RAM. Fix some lettercase.
---
 guide/blueprints/entity-configuration.md | 8 ++++----
 guide/blueprints/multiple-services.md    | 2 +-
 guide/blueprints/winrm/index.md          | 2 +-
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/guide/blueprints/entity-configuration.md b/guide/blueprints/entity-configuration.md
index c70be3a..c1b55c1 100644
--- a/guide/blueprints/entity-configuration.md
+++ b/guide/blueprints/entity-configuration.md
@@ -85,7 +85,7 @@ management hierarchy. This applies to entities and locations. In a future releas
 extended to also apply to policies and enrichers.
 
 When a blueprint author defines a config key, they can explicitly specify the rules for inheritance 
-(both for super/sub-types, and for the runtime management hiearchy). This gives great flexibilty,
+(both for super/sub-types, and for the runtime management hierarchy). This gives great flexibilty,
 but should be used with care so as not to surprise users of the blueprint.
 
 The default behaviour is outlined below, along with examples and details of how to explilcitly 
@@ -120,7 +120,7 @@ is inherited unchanged.
 It will write out: `Sub-type launch command: Goodbye`.
 
 
-#### Inheriting Configuration from a Parent in the Runtime Management Hieararchy
+#### Inheriting Configuration from a Parent in the Runtime Management Hierarchy
 
 Configuration passed to an entity is inherited by all child entities, unless explicitly overridden.
 
@@ -241,7 +241,7 @@ itself.
 When deploying to a jclouds location, one can specify `templateOptions` (of type map). Rather than
 overriding, these will be merged with any templateOptions defined on the location.
 
-In the example below, the VM will be provisioned with minimum 2G ram and minimum 2 cores. It will 
+In the example below, the VM will be provisioned with minimum 2GB RAM and minimum 2 cores. It will 
 also use the merged template options value of 
 `{placementGroup: myPlacementGroup, securityGroupIds: sg-000c3a6a}`:
 
@@ -339,7 +339,7 @@ services:
 #### Never Inherited
 
 For some configuration values, the most logical behaviour is for the value to never be inherited
-in the runtime management hiearchy.
+in the runtime management hierarchy.
 
 Some common config keys that will never inherited include:
 
diff --git a/guide/blueprints/multiple-services.md b/guide/blueprints/multiple-services.md
index eeb1624..d2a987e 100644
--- a/guide/blueprints/multiple-services.md
+++ b/guide/blueprints/multiple-services.md
@@ -68,7 +68,7 @@ to include the credentials for the database (which are defined in the database c
 
 ### An Aside: Substitutability
 
-Don't like JBoss?  Is there something about Maria?
+Don't like JBoss?  Is there something about MariaDB?
 One of the modular principles we follow in Brooklyn is substitutability:
 in many cases, the config keys, sensors, and effectors are defined
 in superclasses and are portable across multiple implementations.
diff --git a/guide/blueprints/winrm/index.md b/guide/blueprints/winrm/index.md
index 5451bf1..7fac77b 100644
--- a/guide/blueprints/winrm/index.md
+++ b/guide/blueprints/winrm/index.md
@@ -229,7 +229,7 @@ config like `pre.install.reboot.required` and `install.reboot.required`. If requ
 installation commands can be split between the pre-install, install and post-install phases
 in order to do a reboot at the appropriate point of the VM setup.
 
-We Strongly recommend to **write blueprints in a way that they do NOT restart automatically Windows** and
+We strongly recommend to **write blueprints in a way that they do NOT restart automatically Windows** and
 use one of the `pre.install.reboot.required` or `install.reboot.required` parameters to perform restart.
 
 ### Install Location