You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@brooklyn.apache.org by he...@apache.org on 2016/02/08 18:38:26 UTC

[1/5] brooklyn-docs git commit: Documentation for initial support for SaltStack.

Repository: brooklyn-docs
Updated Branches:
  refs/heads/master 72ea69ced -> a399f21de


    Documentation for initial support for SaltStack.

    See https://issues.apache.org/jira/browse/BROOKLYN-217.

    This commit merges code from incubator-brooklyn, following the move to the new repos
    after graduation. As such, it unfortunately loses the commit history, but the code
    is based on the work done by Hadrian Zbarcea.  See the Jira link above for history
    and discussion.


Project: http://git-wip-us.apache.org/repos/asf/brooklyn-docs/repo
Commit: http://git-wip-us.apache.org/repos/asf/brooklyn-docs/commit/c1f5915d
Tree: http://git-wip-us.apache.org/repos/asf/brooklyn-docs/tree/c1f5915d
Diff: http://git-wip-us.apache.org/repos/asf/brooklyn-docs/diff/c1f5915d

Branch: refs/heads/master
Commit: c1f5915db3bb1a044c7f9cae1b806e96051e95b2
Parents: b8a5ca5
Author: Geoff Macartney <ge...@cloudsoftcorp.com>
Authored: Wed Feb 3 16:23:15 2016 +0000
Committer: Geoff Macartney <ge...@cloudsoftcorp.com>
Committed: Wed Feb 3 16:23:15 2016 +0000

----------------------------------------------------------------------
 guide/yaml/index.md                         |   1 +
 guide/yaml/salt/about-salt.md               |  38 ++++++
 guide/yaml/salt/creating-salt-blueprints.md | 162 +++++++++++++++++++++++
 guide/yaml/salt/index.md                    |  16 +++
 4 files changed, 217 insertions(+)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/c1f5915d/guide/yaml/index.md
----------------------------------------------------------------------
diff --git a/guide/yaml/index.md b/guide/yaml/index.md
index 792d9a0..5651bef 100644
--- a/guide/yaml/index.md
+++ b/guide/yaml/index.md
@@ -12,6 +12,7 @@ children:
 - custom-entities.md
 - winrm/
 - chef/
+- salt/
 - test/
 - advanced-example.md
 - { path: yaml-reference.md, title: YAML Blueprint Reference }

http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/c1f5915d/guide/yaml/salt/about-salt.md
----------------------------------------------------------------------
diff --git a/guide/yaml/salt/about-salt.md b/guide/yaml/salt/about-salt.md
new file mode 100644
index 0000000..78f4d47
--- /dev/null
+++ b/guide/yaml/salt/about-salt.md
@@ -0,0 +1,38 @@
+---
+title: About Salt
+title_in_menu: About Salt
+layout: website-normal
+---
+
+## What you need to know about Salt
+
+Salt is designed to work in either what it calls a 'master/minion' or a 'masterless' topology.
+ 
+In the former, the master server acts as a managing controller for any number of client nodes, called 'minions'. 
+A salt daemon running on the minion connects back to the master server for its operation, and manages the software on 
+the minion according to a specification of 'states' defined in Salt configuration files.  In the latter, there is no 
+master, and the salt daemon on the minion operates based on the Salt files on the minion node.  This is the mode 
+currently supported by Brooklyn.
+
+A 'State' in Salt is a specification of a configuration of some aspect of a system, such as what packages are installed,
+what system services are running, what files exist, etc.  Such states are described in "SLS" files (for SaLt State 
+file). These files are typically written as templates using the "Jinja" templating engine.  The actual SLS files for the
+minion are then created by processing the templates using configuration data provided via Salt's "Pillar" system.
+
+Salt comes with built-in support for many software systems, and has a repository of pre-written Salt states known as 
+'formulas' on GitHub, at [https://github.com/saltstack-formulas](https://github.com/saltstack-formulas).
+
+### How Brooklyn interacts with Salt
+
+Brooklyn provides a Salt entity type. An entity of this type can be specified in a blueprint in order to provision the 
+node through Salt. The Salt entity will download Salt and install it on the node. The entity type supports the 
+configuration of Salt formulas and Pillar data to download, and the configuration of what Salt states to apply. 
+These are managed using Salt in 'masterless' mode, as described on the
+[Saltstack site](https://docs.saltstack.com/en/latest/topics/tutorials/quickstart.html#salt-masterless-quickstart),
+using the 'salt-call' functionality of Salt.
+
+The Salt 'highstate' (the collection of states applied to the system) is exposed as a sensor on the entity.  An effector
+ is provided on the entity that supports general purpose Salt instructions.
+
+
+

http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/c1f5915d/guide/yaml/salt/creating-salt-blueprints.md
----------------------------------------------------------------------
diff --git a/guide/yaml/salt/creating-salt-blueprints.md b/guide/yaml/salt/creating-salt-blueprints.md
new file mode 100644
index 0000000..90329fa
--- /dev/null
+++ b/guide/yaml/salt/creating-salt-blueprints.md
@@ -0,0 +1,162 @@
+---
+title: Creating Blueprints with Salt
+title_in_menu: Creating Blueprints with Salt
+layout: website-normal
+---
+
+To write a blueprint to use Salt with Brooklyn it will help to have a degree of familiarity with Salt itself. In the 
+sections below, when the Brooklyn configuration is described, the underlying Salt operation is also noted briefly, for 
+clarity for readers who know Salt.
+
+To manage a node with Salt, create a blueprint containing a service of type "org.apache.brooklyn.cm.salt.SaltEntity". 
+For example:
+
+    name: salt-web
+    location: mylocation
+    services:
+    - id: minion1
+      type: org.apache.brooklyn.cm.salt.SaltEntity
+      name: myent
+      start_states:
+        - apache
+      formulas:
+        - https://github.com/saltstack-formulas/apache-formula/archive/master.tar.gz
+    
+This example specifies that Brooklyn should use Salt to download the `apache-formula` from the Saltstack repository on
+Github. The apache formula contains the Apache web server with a simple "it worked" style index page. To start the 
+entity, Brooklyn will use Salt to apply the `apache` state, which will bring up the web server.
+
+A typical usage of the Salt entity might be to include a formula from the Saltstack repository, such as `apache` above,
+and another formula created by the blueprint author, with additional states, such as web site content for the apache 
+server.
+
+### Start States
+
+The `start_states` configuration key defines the top level list of states that will be applied using Salt.  These values
+are added to the Salt `top.sls` file and applied using `state.apply`.  This configuration key is mandatory.
+
+### Stop States
+
+The `stop_states` configuration key is used to specify states that should be applied when the 'stop' effector
+is invoked on the entity.  For example, the Saltstack `mysql` [formula](https://github.com/saltstack-formulas/mysql-formula)
+supplies a state `mysql.disabled` that will shut down the database server.
+
+If the Saltstack formula does not supply a suitable stop state, the blueprint author can create a suitable state and
+include it in an additional formula to be supplied in the `formulas` section. 
+
+The `stop_states` configuration key is optional; if it is not provided, Brooklyn assumes that each state `S` in the 
+`start_state`s should have a matching `S.stop` state.  If not all such states exist, the stop effector will fail; stop
+states are required for Brooklyn to use Salt.
+
+### Restart States
+
+For completeness, Brooklyn also provides a `restart_states` configuration key. These states are applied by the restart
+effector, and blueprint authors may choose to provide custom states to implement restart if that is applicable for their
+application. 
+
+This key is again optional.  If Brooklyn detects that the states `S` in `start_states` have matching `S.restart` states
+then these will be applied by the restart effector.  (If only some of `S` have matching `S.restart` states, Brooklyn
+takes the precaution of failing, on the assumption that the configuration is missing.)   If no such `.restart` states
+exist, Brooklyn will invoke the `stop` and then `start` effectors (so restart states are not required for Brooklyn to
+use Salt).
+
+### Formulas
+
+The `formulas` key provides the URLs for archives containing the Salt formulas that defined the required states. These
+archives are downloaded to the `/srv/formula` directory on the minion and added to the state filesystem roots 
+configuration in Salt's minion config, so that their states are available for a `state.apply`.
+
+### Pillar Configuration
+
+A typical Salt deployment will include both states (provided via Salt formulas) and configuration data, provided through 
+Salt's "Pillar" component.  Brooklyn provides configuration keys for the Salt entity to specify where to get the Pillar
+configuration data.  For example:
+
+    name: salt-mysql
+    location: mylocation
+    services:
+    - id: mydb
+      type: org.apache.brooklyn.cm.salt.SaltEntity
+      name: saltdb
+    
+      start_states:
+        - mysql
+      stop_states: 
+        - mysql.disabled
+    
+      formulas:
+        - https://github.com/saltstack-formulas/mysql-formula/archive/master.tar.gz
+        - http://myhost:8080/my-mysql-formula.tar.gz
+    
+      pillars: 
+        - mysql
+      pillarUrls:
+        - http://myhost:8080/my-mysql-pillar.tar.gz
+
+
+This blueprint contains the MySQL database, and includes a formula available from "myhost" which includes the schema
+information for the DB. The MySQL formula from Saltstack has extensive configurability through Salt Pillars. In the 
+blueprint above, Brooklyn is instructed to apply the pillars defined in the `pillars` configuration key.  (This will 
+add these values to the Salt Pillars `top.sls` file.)  The pillar data must be downloaded; for this, the `pillarUrls` key
+provides the address of an archive containing the Pillar data.  The contents of the archive will be extracted and put
+in the `/srv/pillar` directory on the minion, in order to be available to Salt when applying the pillar. For example,
+the archive above can simply have the structure
+
+    pillar
+    |
+    +- mysql
+       |
+       +- init.sls
+
+The init.sls contains the pillar configuration values, such as 
+
+    # Manage databases
+    database:
+      - orders
+    schema:
+      orders:
+        load: True
+        source: salt://mysql/files/orders.schema
+
+Meanwhile the `my-mysql-formula.tar.gz` formula archive contains the schema:
+
+    my-mysql-formula
+    |
+    +- mysql
+       |
+       +- files
+          |
+          +- orders.schema
+
+Note that the blueprint above defines an `id` for the Salt entity.  This id, if provided, is set as the minion id in
+the Salt configuration file.  This is useful particularly for Pillar configuration, as, if there are more than one 
+Salt managed nodes in the application, they can share a common Pillar file, with appropriate subdivisions of pillar 
+data based on minion id.
+
+### Highstate Sensors
+
+The Salt entity exposes the Salt "highstate" on the node via Brooklyn sensors.  Firstly a single sensor `salt.states` 
+contains a list of all the top level Salt state ID declarations in the highstate.  For example, for the mysql case 
+above, this might look like:
+
+    ["mysql_additional_config", "mysql_config", "mysql_db_0", "mysql_db_0_load", "mysql_db_0_schema", "mysql_debconf",
+     "mysql_debconf_utils", "mysql_python", "mysql_user_frank_localhost", "mysql_user_frank_localhost_0", 
+     "mysql_user_nopassuser_localhost", "mysqld"]
+
+Then, for each ID and each Salt state function in that ID, a Brooklyn sensor is created, containing a map of the data
+from the highstate.  For example, the `salt.state.mysqld.service.running` sensor would have a value like:
+
+
+    {"name":"mysql", "enable":true, "watch":[{"pkg":"mysqld"}, {"file":"mysql_config"}], "order":10005}
+
+
+
+### saltCall Effector
+
+The Salt entity includes a general purpose Salt effector, `saltCall`, which permits execution of Salt commands via
+`salt-call --local`.  It contains a single parameter, `spec`, which specifies the command to invoke.  For example, 
+invoking the effector with a `spec` value of `network.interfaces --out=yaml` would return a YAML formatted map of the 
+network interfaces on the minion.
+
+
+

http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/c1f5915d/guide/yaml/salt/index.md
----------------------------------------------------------------------
diff --git a/guide/yaml/salt/index.md b/guide/yaml/salt/index.md
new file mode 100644
index 0000000..2992b52
--- /dev/null
+++ b/guide/yaml/salt/index.md
@@ -0,0 +1,16 @@
+---
+title: Salt in YAML Blueprints
+layout: website-normal
+children:
+- about-salt.md
+- creating-salt-blueprints.md
+---
+
+This guide describes how Brooklyn entities can be created using the Salt infrastructure management tool
+ ([saltstack.com](saltstack.com)).
+At present Brooklyn provides basic support for Salt, operating in a 'masterless' mode. 
+Comments on this support and suggestions for further development are welcome.
+
+This guide assumes you are familiar with the basics of [creating YAML blueprints](../).
+
+{% include list-children.html %}

[2/5] brooklyn-docs git commit: Update docs in line with https://github.com/apache/brooklyn-library/pull/1

Posted by he...@apache.org.
Update docs in line with https://github.com/apache/brooklyn-library/pull/1


Project: http://git-wip-us.apache.org/repos/asf/brooklyn-docs/repo
Commit: http://git-wip-us.apache.org/repos/asf/brooklyn-docs/commit/36a19838
Tree: http://git-wip-us.apache.org/repos/asf/brooklyn-docs/tree/36a19838
Diff: http://git-wip-us.apache.org/repos/asf/brooklyn-docs/diff/36a19838

Branch: refs/heads/master
Commit: 36a19838ef4b655299fbce199affb0a966fba7a1
Parents: c1f5915
Author: Geoff Macartney <ge...@cloudsoftcorp.com>
Authored: Fri Feb 5 11:50:09 2016 +0000
Committer: Geoff Macartney <ge...@cloudsoftcorp.com>
Committed: Fri Feb 5 11:50:09 2016 +0000

----------------------------------------------------------------------
 guide/yaml/salt/creating-salt-blueprints.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/36a19838/guide/yaml/salt/creating-salt-blueprints.md
----------------------------------------------------------------------
diff --git a/guide/yaml/salt/creating-salt-blueprints.md b/guide/yaml/salt/creating-salt-blueprints.md
index 90329fa..5faaa77 100644
--- a/guide/yaml/salt/creating-salt-blueprints.md
+++ b/guide/yaml/salt/creating-salt-blueprints.md
@@ -15,7 +15,7 @@ For example:
     location: mylocation
     services:
     - id: minion1
-      type: org.apache.brooklyn.cm.salt.SaltEntity
+      type: org.apache.brooklyn.entity.cm.salt.SaltEntity
       name: myent
       start_states:
         - apache
@@ -76,7 +76,7 @@ configuration data.  For example:
     location: mylocation
     services:
     - id: mydb
-      type: org.apache.brooklyn.cm.salt.SaltEntity
+      type: org.apache.brooklyn.entity.cm.salt.SaltEntity
       name: saltdb
     
       start_states:

[5/5] brooklyn-docs git commit: minor tidies of salt documentation

Posted by he...@apache.org.
minor tidies of salt documentation


Project: http://git-wip-us.apache.org/repos/asf/brooklyn-docs/repo
Commit: http://git-wip-us.apache.org/repos/asf/brooklyn-docs/commit/a399f21d
Tree: http://git-wip-us.apache.org/repos/asf/brooklyn-docs/tree/a399f21d
Diff: http://git-wip-us.apache.org/repos/asf/brooklyn-docs/diff/a399f21d

Branch: refs/heads/master
Commit: a399f21de1d79ddf82610eddc6373653979a7bcb
Parents: c8a69a8
Author: Alex Heneveld <al...@cloudsoftcorp.com>
Authored: Mon Feb 8 17:38:02 2016 +0000
Committer: Alex Heneveld <al...@cloudsoftcorp.com>
Committed: Mon Feb 8 17:38:02 2016 +0000

----------------------------------------------------------------------
 guide/yaml/salt/creating-salt-blueprints.md | 77 ++++++++++++------------
 1 file changed, 39 insertions(+), 38 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/a399f21d/guide/yaml/salt/creating-salt-blueprints.md
----------------------------------------------------------------------
diff --git a/guide/yaml/salt/creating-salt-blueprints.md b/guide/yaml/salt/creating-salt-blueprints.md
index 5faaa77..d73ce1d 100644
--- a/guide/yaml/salt/creating-salt-blueprints.md
+++ b/guide/yaml/salt/creating-salt-blueprints.md
@@ -8,19 +8,19 @@ To write a blueprint to use Salt with Brooklyn it will help to have a degree of
 sections below, when the Brooklyn configuration is described, the underlying Salt operation is also noted briefly, for 
 clarity for readers who know Salt.
 
-To manage a node with Salt, create a blueprint containing a service of type "org.apache.brooklyn.cm.salt.SaltEntity". 
+To manage a node with Salt, create a blueprint containing a service of type `org.apache.brooklyn.cm.salt.SaltEntity`
+and define and minimum the `formulas` and `start_states` 
 For example:
 
-    name: salt-web
-    location: mylocation
+    name: Salt Example setting up Apache httpd
+    location: my-cloud
     services:
-    - id: minion1
+    - id: httpd-from-salt
       type: org.apache.brooklyn.entity.cm.salt.SaltEntity
-      name: myent
-      start_states:
-        - apache
       formulas:
-        - https://github.com/saltstack-formulas/apache-formula/archive/master.tar.gz
+      - https://github.com/saltstack-formulas/apache-formula/archive/master.tar.gz
+      start_states:
+      - apache
     
 This example specifies that Brooklyn should use Salt to download the `apache-formula` from the Saltstack repository on
 Github. The apache formula contains the Apache web server with a simple "it worked" style index page. To start the 
@@ -44,9 +44,12 @@ supplies a state `mysql.disabled` that will shut down the database server.
 If the Saltstack formula does not supply a suitable stop state, the blueprint author can create a suitable state and
 include it in an additional formula to be supplied in the `formulas` section. 
 
-The `stop_states` configuration key is optional; if it is not provided, Brooklyn assumes that each state `S` in the 
-`start_state`s should have a matching `S.stop` state.  If not all such states exist, the stop effector will fail; stop
-states are required for Brooklyn to use Salt.
+The `stop_states` configuration key is optional; 
+if it is not provided, Brooklyn assumes that each state `S` in the `start_states` will have a matching `S.stop` state.  
+If any `S` does not have such a state, the stop effector will fail stopping processes.
+Note that on a machine created for this entity, Brooklyn's default behaviour may be to proceed to destroy the VM,
+so stop states are not always needed unless there is a cleaner shutdown process or you are using long-running servers.
+
 
 ### Restart States
 
@@ -54,11 +57,14 @@ For completeness, Brooklyn also provides a `restart_states` configuration key. T
 effector, and blueprint authors may choose to provide custom states to implement restart if that is applicable for their
 application. 
 
-This key is again optional.  If Brooklyn detects that the states `S` in `start_states` have matching `S.restart` states
-then these will be applied by the restart effector.  (If only some of `S` have matching `S.restart` states, Brooklyn
-takes the precaution of failing, on the assumption that the configuration is missing.)   If no such `.restart` states
-exist, Brooklyn will invoke the `stop` and then `start` effectors (so restart states are not required for Brooklyn to
-use Salt).
+This key is again optional.
+If not supplied, Brooklyn will go through each of the states `S` in `start_states` 
+looking for a matching `S.restart` state defined in the formulas.
+If all exist, these will be applied by the restart effector. 
+If none exist, Brooklyn will invoke the `stop` and then `start` effectors -- 
+so `restart` states are not required for Brooklyn to use Salt.
+(If some but not all have matching `restart` states, 
+Brooklyn will fail the restart, on the assumption that the configuration is incomplete.)   
 
 ### Formulas
 
@@ -72,29 +78,28 @@ A typical Salt deployment will include both states (provided via Salt formulas)
 Salt's "Pillar" component.  Brooklyn provides configuration keys for the Salt entity to specify where to get the Pillar
 configuration data.  For example:
 
-    name: salt-mysql
-    location: mylocation
+    name: Salt Example setting up MySQL with a Pillar
+    location: my-cloud
     services:
-    - id: mydb
+    - id: mysql-from-salt-with-my-pillar
       type: org.apache.brooklyn.entity.cm.salt.SaltEntity
-      name: saltdb
+    
+      formulas:
+      - https://github.com/saltstack-formulas/mysql-formula/archive/master.tar.gz
+      - http://myhost:8080/my-mysql-formula.tar.gz
     
       start_states:
-        - mysql
+      - mysql
       stop_states: 
-        - mysql.disabled
-    
-      formulas:
-        - https://github.com/saltstack-formulas/mysql-formula/archive/master.tar.gz
-        - http://myhost:8080/my-mysql-formula.tar.gz
+      - mysql.disabled
     
       pillars: 
-        - mysql
+      - mysql
       pillarUrls:
-        - http://myhost:8080/my-mysql-pillar.tar.gz
+      - http://myhost:8080/my-mysql-pillar.tar.gz
 
 
-This blueprint contains the MySQL database, and includes a formula available from "myhost" which includes the schema
+This blueprint contains the MySQL database, and includes a formula available from `myhost` which includes the schema
 information for the DB. The MySQL formula from Saltstack has extensive configurability through Salt Pillars. In the 
 blueprint above, Brooklyn is instructed to apply the pillars defined in the `pillars` configuration key.  (This will 
 add these values to the Salt Pillars `top.sls` file.)  The pillar data must be downloaded; for this, the `pillarUrls` key
@@ -102,9 +107,9 @@ provides the address of an archive containing the Pillar data.  The contents of
 in the `/srv/pillar` directory on the minion, in order to be available to Salt when applying the pillar. For example,
 the archive above can simply have the structure
 
-    pillar
+    pillar/
     |
-    +- mysql
+    +- mysql/
        |
        +- init.sls
 
@@ -120,11 +125,11 @@ The init.sls contains the pillar configuration values, such as
 
 Meanwhile the `my-mysql-formula.tar.gz` formula archive contains the schema:
 
-    my-mysql-formula
+    my-mysql-formula/
     |
-    +- mysql
+    +- mysql/
        |
-       +- files
+       +- files/
           |
           +- orders.schema
 
@@ -146,11 +151,9 @@ above, this might look like:
 Then, for each ID and each Salt state function in that ID, a Brooklyn sensor is created, containing a map of the data
 from the highstate.  For example, the `salt.state.mysqld.service.running` sensor would have a value like:
 
-
     {"name":"mysql", "enable":true, "watch":[{"pkg":"mysqld"}, {"file":"mysql_config"}], "order":10005}
 
 
-
 ### saltCall Effector
 
 The Salt entity includes a general purpose Salt effector, `saltCall`, which permits execution of Salt commands via
@@ -158,5 +161,3 @@ The Salt entity includes a general purpose Salt effector, `saltCall`, which perm
 invoking the effector with a `spec` value of `network.interfaces --out=yaml` would return a YAML formatted map of the 
 network interfaces on the minion.
 
-
-

[3/5] brooklyn-docs git commit: This closes #9

Posted by he...@apache.org.
This closes #9


Project: http://git-wip-us.apache.org/repos/asf/brooklyn-docs/repo
Commit: http://git-wip-us.apache.org/repos/asf/brooklyn-docs/commit/71f3f444
Tree: http://git-wip-us.apache.org/repos/asf/brooklyn-docs/tree/71f3f444
Diff: http://git-wip-us.apache.org/repos/asf/brooklyn-docs/diff/71f3f444

Branch: refs/heads/master
Commit: 71f3f444572e533b17e77dd6748aef7ad56ee915
Parents: 72ea69c 36a1983
Author: Alex Heneveld <al...@cloudsoftcorp.com>
Authored: Mon Feb 8 17:02:23 2016 +0000
Committer: Alex Heneveld <al...@cloudsoftcorp.com>
Committed: Mon Feb 8 17:02:23 2016 +0000

----------------------------------------------------------------------
 guide/yaml/index.md                         |   1 +
 guide/yaml/salt/about-salt.md               |  38 ++++++
 guide/yaml/salt/creating-salt-blueprints.md | 162 +++++++++++++++++++++++
 guide/yaml/salt/index.md                    |  16 +++
 4 files changed, 217 insertions(+)
----------------------------------------------------------------------

[4/5] brooklyn-docs git commit: fix typo

Posted by he...@apache.org.
fix typo


Project: http://git-wip-us.apache.org/repos/asf/brooklyn-docs/repo
Commit: http://git-wip-us.apache.org/repos/asf/brooklyn-docs/commit/c8a69a83
Tree: http://git-wip-us.apache.org/repos/asf/brooklyn-docs/tree/c8a69a83
Diff: http://git-wip-us.apache.org/repos/asf/brooklyn-docs/diff/c8a69a83

Branch: refs/heads/master
Commit: c8a69a839043facb6a2c298f25d4c8c9b024f65a
Parents: 71f3f44
Author: Alex Heneveld <al...@cloudsoftcorp.com>
Authored: Mon Feb 8 17:03:02 2016 +0000
Committer: Alex Heneveld <al...@cloudsoftcorp.com>
Committed: Mon Feb 8 17:03:02 2016 +0000

----------------------------------------------------------------------
 guide/yaml/advanced-example.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/c8a69a83/guide/yaml/advanced-example.md
----------------------------------------------------------------------
diff --git a/guide/yaml/advanced-example.md b/guide/yaml/advanced-example.md
index 326feb7..b66a3fb 100644
--- a/guide/yaml/advanced-example.md
+++ b/guide/yaml/advanced-example.md
@@ -1,5 +1,5 @@
 ---
-title: YAML BLueprint Advanced Example
+title: YAML Blueprint Advanced Example
 layout: website-normal
 ---