brooklyn-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rich...@apache.org
Subject [09/36] incubator-brooklyn git commit: Cherry-pick merge of PR #389 into 0.7.0-M2-incubating-docs branch
Date Fri, 09 Jan 2015 15:38:51 GMT
http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/201818b0/docs/use/guide/defining-applications/basic-concepts.md
----------------------------------------------------------------------
diff --git a/docs/use/guide/defining-applications/basic-concepts.md b/docs/use/guide/defining-applications/basic-concepts.md
deleted file mode 100644
index 9cf2a27..0000000
--- a/docs/use/guide/defining-applications/basic-concepts.md
+++ /dev/null
@@ -1,95 +0,0 @@
----
-title: Basic Concepts
-layout: page
-toc: ../guide_toc.json
-categories: [use, guide, defining-applications]
----
-
-This introduces brooklyn and describes how it simplifies the deployment and management of big applications. It is
-intended for people who are using brooklyn-supported application components (such as web/app servers, data stores)
-to be able to use brooklyn to easily start their application in multiple locations with off-the-shelf management
-policies.
-
-Entities
---------
-
-The central concept in a Brooklyn deployment is that of an ***entity***. 
-An entity represents a resource under management, either *base* entities (individual machines or software processes) 
-or logical collections of these entities.
-
-Fundamental to the processing model is the capability of entities to be the *parent* of other entities (the mechanism by which collections are formed), 
-with every entity having a single parent entity, up to the privileged top-level ***application*** entity.
-
-Entities are code, so they can be extended, overridden, and modified. Entities can have events, operations, and processing logic associated with them, and it is through this mechanism that the active management is delivered.
-
-The main responsibilities of an entity are:
-
-- Provisioning the entity in the given location or locations
-- Holding configuration and state (attributes) for the entity
-- Reporting monitoring data (sensors) about the status of the entity
-- Exposing operations (effectors) that can be performed on the entity
-- Hosting management policies and tasks related to the entity
-
-
-Application, Parent and Membership
--------------------------------------
-
-All entities have a ***parent*** entity, which creates and manages it, with one important exception: *applications*.
-Application entities are the top-level entities created and managed externally, manually or programmatically.
-
-Applications are typically defined in Brooklyn as an ***application descriptor***. 
-This is a Java class specifying the entities which make up the application,
-by extending the class ``AbstractApplication``, and specifying how these entities should be configured and managed.
-
-All entities, including applications, can be the parent of other entities. 
-This means that the "child" is typically started, configured, and managed by the parent.
-For example, an application may be the parent of a web cluster; that cluster in turn is the parent of web server processes.
-In the management console, this is represented hierarchically in a tree view.
-
-A parallel concept is that of ***membership***: in addition to one fixed parent,
-and entity may be a ***member*** of any number of special entities called ***groups***.
-Membership of a group can be used for whatever purpose is required; 
-for example, it can be used to manage a collection of entities together for one purpose 
-(e.g. wide-area load-balancing between locations) even though they may have been
-created by different parents (e.g. a multi-tier stack within a location).
-
-
-Configuration, Sensors and Effectors
-------------------------------------
-
-### Configuration
-
-All entities contain a map of config information. This can contain arbitrary values, typically keyed under static ``ConfigKey`` fields on the ``Entity`` sub-class. These values are inherited, so setting a configuration value at the
-application level will make it available in all entities underneath unless it is overridden.
-
-Configuration is propagated when an application "goes live" (i.e. it becomes "managed", either explicitly or when its ``start()`` method is invoked), so config values must be set before this occurs. 
-
-Configuration values can be specified in a configuration file (``~/.brooklyn/brooklyn.properties``)
-to apply universally, and/or programmatically to a specific entity and its descendants 
-by calling `.configure(KEY, VALUE)` in the entity spec when creating it.
-There is also an ``entity.setConfig(KEY, VALUE)`` method.
-
-Additionally, many common configuration parameters are available as "flags" which can be supplied as Strings when constructing
-then entity, in the form
-``EntitySpec.createË™(MyEntity.class).configure("config1", "value1").configure("config2", "value2")``. 
-
-Documentation of the flags available for individual entities can normally be found in the javadocs. 
-The ``@SetFromFlag`` annotations on ``ConfigKey`` static field definitions
-in the entity's interface is the recommended mechanism for exposing configuration options.
-
-
-### Sensors and Effectors
-
-***Sensors*** (activity information and notifications) and ***effectors*** (operations that can be invoked on the entity) are defined by entities as static fields on the ``Entity`` subclass.
-
-Sensors can be updated by the entity or associated tasks, and sensors from an entity can be subscribed to by its parent or other entities to track changes in an entity's activity.
-
-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 
-the entity's state in attributes (see `getAttribute(AttributeKey)``). If internal fields can be 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.
-
-Next: [Advanced Concepts]({{site.url}}/use/guide/defining-applications/advanced-concepts.html).
-See also: [Management > Sensors and Effectors]({{site.url}}/use/guide/management/index.html#sensors-and-effectors).
-

http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/201818b0/docs/use/guide/defining-applications/brooklyn-flow-websequencediagrams.com-w400.png
----------------------------------------------------------------------
diff --git a/docs/use/guide/defining-applications/brooklyn-flow-websequencediagrams.com-w400.png b/docs/use/guide/defining-applications/brooklyn-flow-websequencediagrams.com-w400.png
deleted file mode 100644
index c2b48ba..0000000
Binary files a/docs/use/guide/defining-applications/brooklyn-flow-websequencediagrams.com-w400.png and /dev/null differ

http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/201818b0/docs/use/guide/defining-applications/brooklyn-flow-websequencediagrams.com.png
----------------------------------------------------------------------
diff --git a/docs/use/guide/defining-applications/brooklyn-flow-websequencediagrams.com.png b/docs/use/guide/defining-applications/brooklyn-flow-websequencediagrams.com.png
deleted file mode 100644
index 78eb5c8..0000000
Binary files a/docs/use/guide/defining-applications/brooklyn-flow-websequencediagrams.com.png and /dev/null differ

http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/201818b0/docs/use/guide/defining-applications/chef-blueprints.md
----------------------------------------------------------------------
diff --git a/docs/use/guide/defining-applications/chef-blueprints.md b/docs/use/guide/defining-applications/chef-blueprints.md
deleted file mode 100644
index eeacadc..0000000
--- a/docs/use/guide/defining-applications/chef-blueprints.md
+++ /dev/null
@@ -1,277 +0,0 @@
----
-title: Using Chef in YAML Blueprints
-layout: page
-toc: ../guide_toc.json
-categories: [use, guide, defining-applications]
----
-
-This guide describes how Brooklyn entities can be easily created from Chef cookbooks.
-As of this writing (May 2014) some of the integration points are under active development,
-and comments are welcome.
-A plan for the full integration is online [here](https://docs.google.com/a/cloudsoftcorp.com/document/d/18ZwzmncbJgJeQjnSvMapTWg6N526cvGMz5jaqdkxMf8).  
-
-This guide assumes you are familiar with the basics of [creating YAML blueprints](creating-yaml.html).
-
-
-## What you need to know about Chef
-
-Chef works in two different modes, *server* and *solo*. *Server* is where the Chef client talks to a central server
-to retrieve information about its roles, policies and cookbooks (where a cookbook defines how to install and
-configure a particular piece of software). With *solo*, the client works in isolation, therefore its configuration
-and cookbooks must be supplied by another means.
-
-Chef *client* is the Chef agent. This is a Ruby application which is installed on each and every managed host. When
-invoked in server mode, it will contact the Chef server to check for updates to cookbooks and policy; it then "runs"
-the recipes in its run lists, to converge the machine to a known state. In solo mode, it reads the locally-maintained
-cookbooks and policies. The client may be run as a daemon that checks the server regularly, or it could merely be
-run manually when required.
-
-The *policy* is a set of rules on the Chef server. A client starts with a set of *attributes*, which could be as
-simple as its name and a recipe runlist, or which may involve a more complex set of attributes about how it is to be
-configured. The client then augments this with auto-detected metadata - a tool called `ohai` is run that collects
-detailed information about the host. Next, the policy on the server modifies these attributes - overriding some,
-setting defaults for others - to produce a final set of attributes. It is these which are the input to the recipes.
-Finally, the attributes are uploaded to the server where they are stored as metadata for the node, where they can be
-inspected and modified by the system operator.
-
-Also of interest is `knife`, which is the workstation toolkit for Chef. Typically this would be installed on the
-operation engineer's workstation, where it would be used to interact with the Chef server and clients. Of particular
-interest to us is the *bootstrap* operation, which is used for setting up new Chef clients - given a virtual machine,
-it will install the Chef client on it, configure it with enough information to find the Chef server and performs its
-first run, and then kicks off the Chef client for the first time.
-
-There is often a preconception about how a Chef client is bootstrapped; mistakenly, there is the belief that the
-`knife` tool configures the Chef server with information about the client, and the client finds out about itself from
-the server. This is not the case - the bootstrap operation does not involve `knife` talking to the server. Instead,
-`knife` packages up all of the required information and sends it to the client - the client will then introduce
-itself to the server, passing on its configuration.
-
-This diagram summarises the interaction between Brooklyn, the new node, and the various Chef tools. Note that there
-is no interaction between the AMP Server and the Chef Server.
-
-[![Chef Flow Diagram](Chef.png "Chef Flow Diagram" )](Chef.png)
-
-### How Brooklyn interacts with Chef
-
-Brooklyn understands both the *server* and *solo* modes of operation. Server mode utilises the `knife` toolkit, and
-therefore `knife` must be installed onto the AMP server and configured appropriately. Solo mode does not have any
-special requirements; when running in solo mode, Brooklyn will install and configure the Chef client over SSH, just
-like it does most other kinds of entities.
-
-
-## Creating Blueprints from Chef
-
-In a nutshell, a new Chef-based entity can be defined as a service by specifying
-`chef:cookbook_name` as the `service_type`, along with a collection of optional configuration.
-An illustrative example is below:
-
-{% highlight yaml %}
-{% readj example_yaml/mysql-chef-1.yaml %}
-{% endhighlight %}
-
-*This works without any installation: try it now, copying-and-pasting to the Brooklyn console.
-(Don't forget to add your preferred `location: some-cloud` to the spec.)*  
-
-We'll now walk through the important constituent parts,
-and then proceed to describing things which can be done to simplify the deployment.
-
-
-### Cookbook Primary Name
-
-The first thing to note is the type definition:
-
-    - type: chef:mysql
-
-This indicates that the Chef entity should be used (`brooklyn.entity.chef.ChefEntity`) 
-to interpret and pass the configuration,
-and that it should be parameterised with a `brooklyn.chef.cookbook.primary.name` of `mysql`.
-This is the cookbook namespace used by default for determining what to install and run.
-
-
-### Importing Cookbooks
-
-Next we specify which cookbooks are required and where they can be pulled from:
-
-      cookbook_urls:
-        mysql: https://github.com/opscode-cookbooks/mysql/archive/v4.0.12.tar.gz
-        openssl: https://github.com/opscode-cookbooks/openssl/archive/v1.1.0.tar.gz
-        build-essential: https://github.com/opscode-cookbooks/build-essential/archive/v1.4.4.tar.gz
-
-Here, specific versions are being downloaded from the canonical github repository.
-Any URL can be used, so long as it is resolvable on either the target machine or the
-Brooklyn server; this includes `file:` and `classpath:` URLs.
-
-The archive can be ZIP or TAR or TGZ.
-
-The structure of the archive must be that a single folder is off the root,
-and in that folder contains the usual Chef recipe and auxiliary files.
-For example, the archive might contain `mysql-master/recipes/server.rb`.
-Archives such as those above from github match this format.  
-The name of that folder does not matter, as often they contain version information.
-When deployed, these will be renamed to match the short name (the key in the `cookbooks_url` map,
-for instance `mysql` or `openssl`).
-
-If Chef server is configured (see below), this section can be omitted.
-
-
-### Launch Run List and Attributes
-
-The next part is to specify the Chef run list and attributes to store when launching the entity: 
-
-      launch_run_list:
-      - mysql::server
-      
-      launch_attributes:
-        mysql:
-          server_root_password: p4ssw0rd
-          server_repl_password: p4ssw0rd
-          server_debian_password: p4ssw0rd
-
-For the `launch_run_list`, you can use either the YAML `- recipe` syntax or the JSON `[ "recipe" ]` syntax.
-
-The `launch_attributes` key takes a map which will be stored against the `node` object in Chef.
-Thus in this example, the parameter `node['mysql']['server_root_password']` required by the mysql blueprint
-is set as specified.
-
-You can of course set many other attributes in this manner, in addition to those that are required!  
-
-
-### Simple Monitoring
-
-The final section determines how Brooklyn confirms that the service is up.
-Sophisticated solutions may install monitoring agents as part of the `launch_run_list`,
-with Brooklyn configured to read monitoring information to confirm the launch was successful.
-However for convenience, two common mechanisms are available out of the box:
-
-      #service_name: mysqld
-      pid_file: /var/run/mysqld/mysqld.pid
-
-If `service_name` is supplied, Brooklyn will check the return code of the `status` command
-run against that service, ensuring it is 0.  (Note that this is not universally reliable,
-although it is the same mechanism which Chef typically uses to test status when determining
-whether to start a service. Some services, e.g. postgres, will return 0 even if the service
-is not running.)
-
-If a `pid_file` is supplied, Brooklyn will check whether a process with the PID specified in that
-file is running. This has been selected for mysql because it appears to be more portable:
-the service name varies among OS's:  it is `mysqld` on CentOS but `mysql` on Ubuntu!
-
-
-## Making it Simpler: Writing Chef for Blueprints
-
-The example we've just seen shows how existing Chef cookbooks can be
-used as the basis for entities.  If you're *writing* the Chef recipes, 
-there are a few simple techniques we've established with the Chef community
-which make blueprints literally as simple as:
-
-    - type: chef:mysql
-      brooklyn.config:
-        mysql_password: p4ssw0rd
-        pid_file: /var/run/mysqld/mysqld.pid
-
-
-### Some Basic Conventions
-
-* **A `start` recipe**:
-  The first step is to provide a `start` recipe in `recipes/start.rb`;
-  if no `launch_run_list` is supplied, this is what will be invoked to launch the entity.
-  It can be as simple as a one-line file:
-
-      include_recipe 'mysql::server'
-
-* **Using `brooklyn.config`**:
-  All the `brooklyn.config` is passed to Chef as node attributes in the `node['brooklyn']['config']` namespace.
-  Thus if the required attributes in the mysql recipe are set to take a value set in
-  `node['brooklyn']['config']['mysql_password']`, you can dispense with the `launch_attributes` section.
-
-
-## Using Chef Server
-
-The examples so far have not required Chef Server, so they will work without any external
-Chef dependencies (besides the built-in install from `https://www.opscode.com/chef/install.sh`
-and the explicitly referenced cookbooks).  If you use Chef Server, however, you'll want your
-managed nodes to be integrated with it.  This is easy to set up, with a few options:
-
-If you have `knife` set up in your shell environment, the Brooklyn Chef support will use it
-by default. If the recipes are installed in your Chef server, you can go ahead and remove
-the `cookbooks_url` section!
-
-Use of `solo` or `knife` can be forced by setting the `chef_mode` flag (`brooklyn.chef.mode` config key)
-to either of those values.  (It defaults to `autodetect`, which will use `knife` if it is on the path and satisfies
-sanity checks).
-
-If you want to specify a different configuration, there are a number of config keys you can use:
-
-* `brooklyn.chef.knife.executableFile`: this should be point to the knife binary to use
-* `brooklyn.chef.knife.configFile`: this should point to the knife configuration to use
-* `brooklyn.chef.knife.setupCommands`: an optional set of commands to run prior to invoking knife,
-  for example to run `rvm` to get the right ruby version on the Brooklyn server
-
-If you're interested in seeing the Chef REST API be supported directly (without knife),
-please let us know.  We'd like to see this too, and we'll help you along the way!
- 
-
-## Tips and Tricks
-
-To help you on your way writing Chef blueprints, here are a handful of pointers
-particularly useful in this context:
-
-* Configuration keys can be inherited from the top-level and accessed using `$brooklyn:component('id').config('key_name')`.
-  An example of this is shown in the `mysql-chef.yaml` sample recipe contained in the Brooklyn code base
-  and [here](example_yaml/mysql-chef-2.yaml) for convenience.
-  Here, `p4ssw0rd` is specified only once and then used for all the attributes required by the stock mysql cookbook.  
-
-* Github tarball downloads! You'll have noticed these in the example already, but they are so useful we thought
-  we'd call them out again. Except when you're developing, we recommend using specific tagged versions rather than master.
-
-* The usual machine `provisioning.properties` are supported with Chef blueprints, 
-  so you can set things like `minRam` and `osFamily`
-
-* To see more configuration options, and understand the ones presented here in more detail, see the javadoc or
-  the code for the class `ChefConfig` in the Brooklyn code base.
-
-
-## Advanced Chef Integration
-
-### Adding Sensors and Effectors
-
-Custom sensors and effectors can be added using an `entity.initializer` section in the YAML blueprint.
-
-One common pattern is to have sensors which extract information from Ohai.
-Another common pattern is to install a monitoring agent as part of the run list,
-configured to talk to a monitoring store, and then to add a sensor feed which reads data from that store.
-
-On the effector side, you can add SSH-based effectors in the usual way.
-You can also describe additional chef converge targets following the pattern set down in
-`ChefLifecycleEffectorTasks`, making use of conveniences in `ChefSoloTasks` and `ChefServerTasks`,
-or provide effectors which invoke network API's of the systems under management
-(for example to supply the common `executeScript` effector as on the standard `MySqlNode`). 
-   
-
-### Next Steps: Simpifying sensors and effectors, transferring files, and configuring ports
-
-The Brooklyn-Chef integration is work in progress, with a few open issues we'd still like to add.
-Much of the thinking for this is set forth in the [Google document](https://docs.google.com/a/cloudsoftcorp.com/document/d/18ZwzmncbJgJeQjnSvMapTWg6N526cvGMz5jaqdkxMf8)
-indicated earlier.  If you'd like to work with us to implement these, please let us know.
-
-
-## Reference
-
-A general schema for the supported YAML is below: 
-
-```
-- type: chef:cookbook_name
-  cookbook_urls:
-    cookbook_name: url://for/cookbook.tgz
-    dependency1: url://for/dependency1.tgz
-  launch_run_list: [ "cookbook_name::start" ]
-  launch_attributes: # map of arguments to set in the chef node
-  service_name: cookbook_service
-  pid_file: /var/run/cookbook.pid
-```
-
-If you are interested in exploring the Java code for creating blueprints,
-start with the `TypedToyMySqlEntiyChef` class, which essentially does what this tutorial has shown;
-and then move on to the `DynamicToyMySqlEntiyChef` which starts to look at more sophisticated constructs.
-(Familiarity with BASH and basic Java blueprints may be useful at that stage.)
-

http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/201818b0/docs/use/guide/defining-applications/common-usage.md
----------------------------------------------------------------------
diff --git a/docs/use/guide/defining-applications/common-usage.md b/docs/use/guide/defining-applications/common-usage.md
deleted file mode 100644
index 9009c03..0000000
--- a/docs/use/guide/defining-applications/common-usage.md
+++ /dev/null
@@ -1,145 +0,0 @@
----
-title: Common Usage
-layout: page
-toc: ../guide_toc.json
-categories: [use, guide, defining-applications]
----
-
-### Entity Class Hierarchy
-
-By convention in Brooklyn the following words have a particular meaning, both as types (which extend ``Group``, which extends ``Entity``) and when used as words in other entities (such as ``TomcatFabric``):
-
-- *Cluster* - a homogeneous collection of entities
-- *Fabric* - a multi-location collection of entities, with one per location; often used with a cluster per location
-- *Stack* - heterogeneous (mixed types of children)
-- *Application* - user's entry point
-
-<!---
-TODO
--->
-
-- *entity spec* defines an entity, so that one or more such entities can be created; often used by clusters/groups to define how to instantiate new children.
-- *entity factories* are often used by clusters/groups to define how to instantiate new children.
-- *traits* (mixins) providing certain capabilities, such as Resizable and Balanceable
-- *Resizable* entities can re-sized dynamically, to increase/decrease the number of child entities.
-- *Movable* entities can be migrated between *balanceable containers*.
-- *Balanceable containers* can contain *movable* entities, where each contained entity is normally associated with
-    a piece of work within that container.
-
-### Off-the-Shelf Entities
-
-brooklyn includes a selection of entities already available for use in applications,
-including appropriate sensors and effectors, and in some cases include Cluster and Fabric variants.
-(These are also useful as templates for writing new entities.)
- 
-These include:
-
-- **Web**: Tomcat, JBoss, Jetty (external), Play (external); nginx; GeoScaling
-- **Data**: MySQL, Redis, MongoDB, Infinispan, GemFire (external)
-- **Containers**: Karaf
-- **Messaging**: ActiveMQ, Qpid, Rabbit MQ
-- **PaaS**: Cloud Foundry, Stackato; OpenShift
-
-
-### <a id="locations"></a> Off-the-Shelf Locations
-
-<a id="locations"></a>
-
-Brooklyn supports deploying to any machine which admits SSH access, as well as to
-a huge variety of external and on-premise clouds.  You can also connect to services,
-or use whatever technique for deployment suits you best (such as Xebia Overthere, in development!).
-
-Configuration is typically set in `~/.brooklyn/brooklyn.properties` using keys such as the following:
-
-{% highlight bash %}
-# use this key for localhost (this is the default, although if you have a passphrase you must set it)
-brooklyn.location.localhost.privateKeyFile=~/.ssh/id_rsa
-
-brooklyn.location.localhost.privateKeyPassphrase=s3cr3tPASSPHRASE
-   
-# use a special key when connecting to public clouds, and a particularly special one for AWS
-brooklyn.location.jclouds.privateKeyFile=~/.ssh/public_clouds/id_rsa
-brooklyn.location.jclouds.aws-ec2.privateKeyFile=~/.ssh/public_clouds/aws_id_rsa
-
-# AWS credentials (when deploying to location jclouds:aws-ec2)
-brooklyn.location.jclouds.aws-ec2.identity=ABCDEFGHIJKLMNOPQRST  
-brooklyn.location.jclouds.aws-ec2.credential=s3cr3tsq1rr3ls3cr3tsq1rr3ls3cr3tsq1rr3l
-
-# credentials for 'geoscaling' service
-brooklyn.geoscaling.username=cloudsoft  
-brooklyn.geoscaling.password=xxx
-{% endhighlight %}
-
-These can also be set as environment variables (in the shell) or system properties (java command line).
-(There are also ``BROOKLYN_JCLOUDS_PRIVATE_KEY_FILE`` variants accepted.)
-
-For any jclouds provider you will typically need to set ``identity`` and ``credential``
-in the ``brooklyn.location.jclouds.provider`` namespace.
-
-To deploy to sets of machines with known IP's, assuming you have the credentials,
-use the syntax ``byon:(hosts="user@10.9.1.1,user@10.9.1.2,user@10.9.1.3")``
-(this requires your default private key to have access; 
-see the ``prod1`` example below for specifying other credentials). 
-
-A wide range of other fields is available, because in the real world sometimes things do get complicated.
-The following is supported from the configuration file (with whatever customization you might want available in code): 
-
-- If there is a passphrase on the key file being used, you must supply it to Brooklyn for it to work, of course!
-  ``privateKeyPassphrase`` does the trick (as in ``brooklyn.location.jclouds.privateKeyPassphrase``, or other places
-  where ``privateKeyFile`` is valid).  If you don't like keys, you can just use a plain old ``password``.
-
-- Hardware requirements such as ``minRam`` and ``minCores`` can be supplied, or a ``hardwareId``  (jclouds only)
-
-- Specific Secury Groups can be specified using `securityGroups`, if you want to reuse set of existing ones (jclouds only)
-
-- Specific KeyPair can be specified using `keyPair`, if you want to reuse an existing keypair (jclouds only).
-
-- Specific VM images can be specified using ``imageId`` or ``imageNameRegex`` (jclouds only)
-
-- User metadata can be attached, using the syntax ``userMetadata=key=value,key2="value 2"`` (jclouds only)
-
-- A ``user`` can be specified, with the property that -- in a jclouds world -- the user will be *created* on the machine,
-  with admin rights, authorizing the relevant public key (corresponding to the private key, or as described below). 
-  Login for the root account will be disabled, as will login by password if a public key is supplied. 
-  (This is skipped if ``user`` is the ``root`` or other initial login user.)
-  
-- You can specify the user account to use to login to jclouds initially with the ``loginUser`` property.
-  Typically this is auto-detected by jclouds
-  (often ``root``, or ``ubuntu`` or ``ec2-user`` for known Ubuntu or Amazon Linux images), 
-  but the strategy isn't foolproof, particularly in some private cloud setups. (jclouds only). In some cases, you may need to specify a `loginUser.privateKeyFile` if the image you are using doesn't allow ssh password login.
-
-- Public keys can be specified using ``publicKeyFile``, 
-  although these can usually be omitted if they follow the common pattern of being
-  the private key file with the suffix ``.pub`` appended.
-  (It is useful in the case of ``loginUser.publicKeyFile``, where you shouldn't need,
-  or might not even have, the private key of the ``root`` user in order to log in.)
-
-- You can specify the number of attempts Brooklyn should make to create
-  machines with ``machineCreateAttempts`` (jclouds only). This is useful for
-  working around the rare occasions in which cloud providers give machines that
-  are dead on arrival.
-
-You can also define named locations for commonly used groups of properties, 
-with the syntax ``brooklyn.location.named.your-group-name.``
-followed by the relevant properties.
-These can be accessed at runtime using the syntax ``named:your-group-name`` as the deployment location.
-
-Some more advanced examples showing the syntax and properties above are as follows:
-
-{% highlight bash %}
-# Production pool of machines for my application (deploy to named:prod1)
-brooklyn.location.named.prod1=byon:(hosts="10.9.1.1,10.9.1.2,produser2@10.9.2.{10,11,20-29}")
-brooklyn.location.named.prod1.user=produser1
-brooklyn.location.named.prod1.privateKeyFile=~/.ssh/produser_id_rsa
-brooklyn.location.named.prod1.privateKeyPassphrase=s3cr3tCOMPANYpassphrase
-
-# AWS using my company's credentials and image standard, then labelling images so others know they're mine
-brooklyn.location.named.company-jungle=jclouds:aws-ec2:us-west-1
-brooklyn.location.named.company-jungle.identity=BCDEFGHIJKLMNOPQRSTU  
-brooklyn.location.named.company-jungle.privateKeyFile=~/.ssh/public_clouds/company_aws_id_rsa
-brooklyn.location.named.company-jungle.imageId=ami-12345
-brooklyn.location.named.company-jungle.minRam=2048
-brooklyn.location.named.company-jungle.userMetadata=application=my-jungle-app,owner="Bob Johnson"
-brooklyn.location.named.company-jungle.machineCreateAttempts=2
-{% endhighlight %}
-

http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/201818b0/docs/use/guide/defining-applications/creating-yaml.md
----------------------------------------------------------------------
diff --git a/docs/use/guide/defining-applications/creating-yaml.md b/docs/use/guide/defining-applications/creating-yaml.md
deleted file mode 100644
index 1ccd2bd..0000000
--- a/docs/use/guide/defining-applications/creating-yaml.md
+++ /dev/null
@@ -1,417 +0,0 @@
----
-title: Writing YAML Blueprints
-layout: page
-toc: ../guide_toc.json
-categories: [use, guide, defining-applications]
----
-
-## A First Blueprint
-
-The easiest way to write a blueprint is as a YAML file.
-This follows the  <a href="https://www.oasis-open.org/committees/camp/">OASIS CAMP</a> plan specification, 
-with some extensions described below.
-(A [YAML reference](yaml-reference.html) has more information,
-and if the YAML doesn't yet do what you want,
-it's easy to add new extensions using your favorite JVM language.)
-
-### The Basic Structure
-
-Here's a very simple YAML blueprint plan, to explain the structure:
-
-{% highlight yaml %}
-{% readj example_yaml/simple-appserver.yaml %}
-{% endhighlight %}
-
-* The `name` is just for the benefit of us humans.
-
-* The `location` specifies where this should be deployed.
-  If you've [set up passwordless localhost SSH access]({{ site.url }}/use/guide/locations/) 
-  you can use `localhost` as above, but if not, just wait ten seconds for the next example.
-  
-* The `services` block takes a list of the typed services we want to deploy.
-  This is the meat of the blueprint plan, as you'll see below.
-
-Finally, that clipboard in the corner lets you easily copy-and-paste into the web-console:
-simply [download and launch]({{ site.url }}/use/guide/quickstart/) Brooklyn,
-then in the "Add Application" dialog at the web console
-(usually [http://127.0.0.1:8081/](http://127.0.0.1:8081/). 
-There are several other ways to deploy, including `curl` and via the command-line,
-and you can configure https and security, and much more, as described [here](deploying-yaml.html).
-
-[![Web Console](web-console-yaml-700.png "YAML via Web Console")](web-console-yaml.png)
-
-
-### Setting Locations
-
-Brooklyn supports a very wide range of target locations -- localhost is mainly a convenience for testing.
-With deep integration to [Apache jclouds](http://jclouds.org), most well-known clouds and cloud platforms are supported.
-The following example is for Amazon EC2:
-
-{% highlight yaml %}
-{% readj example_yaml/simple-appserver-with-location.yaml %}
-{% endhighlight %}
-
-(You'll need to replace the `identity` and `credential` with the 
-"Access Key ID" and "Secret Access Key" for your account,
-as configured in the [AWS Console](https://console.aws.amazon.com/iam/home?#security_credential).)
-
-Other popular public clouds include `softlayer`, `google-compute-engine`, and `rackspace-cloudservers-us`.
-Private cloud systems including `openstack-nova` and `cloudstack` are also supported,
-although for these you'll supply an `endpoint: https://9.9.9.9:9999/v2.0/` 
-(or `client/api/` in the case of CloudStack) instead of the `region`.
-
-You can also specify pre-existing servers to use -- "bring-your-own-nodes".
-These can be a global pool or specific to a service.
-Both styles are shown here (though normally only one will be selected,
-<!-- TODO see #1377, currently it is *parent* location which is preferred typically --> 
-depending on the blueprint):
-
-{% highlight yaml %}
-{% readj example_yaml/simple-appserver-with-location-byon.yaml %}
-{% endhighlight %}
-
-You'll also note in this example that we've used JSON-style notation in the second `location` block.
-YAML supports this, and sometimes that makes more readable plans.
-(Although in this case a simple `location: localhost` is equivalent and even more succinct, but this is a tutorial.)
-
-For more information see the Locations section of the [YAML reference](yaml-reference.html) 
-and in the [User's Guide]({{ site.url }}/use/guide/locations/).
-Another good reference is the [template brooklyn.properties](/use/guide/quickstart/brooklyn.properties),
-which if you install in `~/.brooklyn/brooklyn.properties` and edit with your credentials,  
-allows you to refer to clouds simply as `location: jclouds:aws-ec2:eu-west-1` or
-set up "named locations" you can use as `location: named:my_cloudstack`.
-
-
-## Configuring VMs
-
-Another simple blueprint will just create a VM which you can use, without any software installed upon it:
-
-{% highlight yaml %}
-{% readj example_yaml/simple-vm.yaml %}
-{% endhighlight %}
-
-
-*We've omitted the `location` section here and in many of the examples below;
-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]({{ site.url }}/use/guide/defining-applications/basic-concepts.html).
-There are many more `provisioning.properties` supported here,
-including:
-
-* a `user` to create (if not specified it creates the same username as `brooklyn` is running under) 
-* a `password` for him or a `publicKeyFile` and `privateKeyFile` (defaulting to keys in `~/.ssh/id_rsa{.pub,}` and no password,
-  so if you have keys set up you can immediately ssh in!)
-* `machineCreateAttempts` (for dodgy clouds, and they nearly all fail occasionally!) 
-* and things like `imageId` and `userMetadata` and disk and networking options (e.g. `autoAssignFloatingIp` for private clouds)
-
-For more information, see the javadoc on `JcloudsLocationConfig`.
-
-
-### Clusters, Specs, and Composition
-
-What if you want multiple machines?
-
-One way is just to repeat the `- type: brooklyn.entity.basic.EmptySoftwareProcess` block,
-but there's another way which will keep your powder [DRY](http://en.wikipedia.org/wiki/Don't_repeat_yourself):
-
-{% highlight yaml %}
-{% readj example_yaml/cluster-vm.yaml %}
-{% endhighlight %}
-
-Here we've composed the previous blueprint introducing some new important concepts, the `DynamicCluster`
-the `$brooklyn` DSL, and the "entity-spec".  Let's unpack these. 
-
-The `DynamicCluster` creates a set of homogeneous instances.
-At design-time, you specify an initial size and the specification for the entity it should create.
-At runtime you can restart and stop these instances as a group (on the `DynamicCluster`) or refer to them
-individually. You can resize the cluster, attach enrichers which aggregate sensors across the cluster, 
-and attach policies which, for example, replace failed members or resize the cluster dynamically.
-
-The specification is defined in the `memberSpec` key.  As you can see it looks very much like the
-previous blueprint, with one extra line.  Entries in the blueprint which start with `$brooklyn:`
-refer to the Brooklyn DSL and allow a small amount of logic to be embedded
-(if there's a lot of logic, it's recommended to write a blueprint YAML plugin or write the blueprint itself
-as a plugin, in Java or a JVM-supported language).  
-
-In this case we want to indicate that the parameter to `memberSpec` is an entity specification
-(`EntitySpec` in the underlying type system); the `entitySpec` DSL command will do this for us.
-The example above thus gives us 5 VMs identical to the one we created in the previous section.
-
-
-## A Bigger Blueprint
-
-We've seen the configuration of machines and how to build up clusters.
-Now let's return to our app-server example and explore how more interesting
-services can be configured, composed, and combined.
-
-Also note there are some good overview materials [here]({{site.url}}//use/guide/defining-applications/basic-concepts.html)
-covering clusters, sensors, effectors and more, 
-if you're the kind of person who likes to learn more about concepts before seeing them in action.
-
-
-### Service Configuration
-
-We'll begin by using more key-value pairs to configure the JBoss server to run a real app:
-
-{% highlight yaml %}
-{% readj example_yaml/appserver-configured.yaml %}
-{% endhighlight %}
-
-(As before, you'll need to add the `location` info; `localhost` will work for these and subsequent examples.)
-
-When this is deployed, you can see management information in the Brooklyn Web Console,
-including a link to the deployed application (downloaded to the target machine from the `hello-world` URL),
-running on port 8080.
-
-**Top tip**:  If port 8080 might be in use, you can specify `8080+` to take the first available port >= 8080;
-the actual port will be reported as a sensor by Brooklyn.
-
-It's also worth indicating an alternate, more formal syntax.
-Not all configuration on entities is supported at the top level of the service specification
-(only those which are defined as "flags" in the underlying blueprint,
-e.g. the `@SetFromFlag("war")` in the `WebAppServiceConstants` parent of `JBoss7Server`).
-All configuration has a formal qualified name, and this can be supplied even where flags or config keys are not
-explicitly defined, by placing it into a `brooklyn.config` section:
-
-{% highlight yaml %}
-{% readj example_yaml/appserver-configured-in-config.yaml %}
-{% endhighlight %}
-
-
-
-### Multiple Services and Dependency Injection
-
-If you explored the `hello-world-sql` application we just deployed, 
-you'll have noticed it tries to access a database.
-And it fails, because we have not set one up.  Let's do that now:
-
-{% highlight yaml %}
-{% readj example_yaml/appserver-w-db.yaml %}
-{% endhighlight %}
-
-Here there are a few things going on:
-
-* We've added a second service, which will be the database;
-  you'll note the database has been configured to run a custom setup script
-* We've injected the URL of the second service into the appserver as a Java system property
-  (so our app knows where to find the database) 
-
-**Caution: Be careful if you write your YAML in an editor which attempts to put "smart-quotes" in.
-All quote characters must be plain ASCII, not fancy left-double-quotes and right-double-quotes!**
-
-There are as many ways to do dependency injection as there are developers,
-it sometimes seems; our aim in Brooklyn is not to say this has to be done one way,
-but to support the various mechanisms people might need to do, for whatever reasons.
-(We each have our opinions about what works well, of course;
-the one thing we do want to call out is that being able to dynamically update
-the injection is useful in a modern agile application -- so we are definitively **not**
-recommending this Java system property approach ... but it is an easy one to demo!)
-
-The way the dependency injection works is again by using the `$brooklyn:` DSL,
-this time referring to the `component("db")` (looked up by the `id` field on our DB component),
-and then to a sensor emitted by that component.
-All the database entities emit a `database.url` sensor when they are up and running;
-the `attributeWhenReady` DSL method will store a pointer to that sensor (a Java Future under the covers)
-in the Java system properties map which the JBoss entity reads at launch time, blocking if needed.
-
-This means that the deployment occurs in parallel, and if the database comes up first,
-there is no blocking; but if the JBoss entity completes its installation and 
-downloading the WAR, it will wait for the database before it launches.
-At that point the URL is injected, first passing it through `formatString`
-to include the credentials for the database (which are defined in the database creation script).
-
-
-
-### An Aside: Substitutability
-
-Don't like JBoss?  Is there something about Maria?
-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.
-
-Here's an example deploying the same application but with different flavors of the components:
-
-{% highlight yaml %}
-{% readj example_yaml/appserver-w-db-other-flavor.yaml %}
-{% endhighlight %}
-
-We've also brought in the `provisioning.properties` from the VM example earlier
-so our database has 8GB RAM.
-Any of those properties, including `imageId` and `user`, can be defined on a per-entity basis.
-
-
-### Clusters and Policies
-
-Now let's bring the concept of the "cluster" back in.
-We could wrap our appserver in the same `DynamicCluster` we used earlier,
-although then we'd need to define and configure the load balancer.
-But another blueprint, the `ControlledDynamicWebAppCluster`, does this for us.
-It takes the same `memberSpec`, so we can build a fully functional elastic 3-tier
-deployment of our `hello-world-sql` application as follows:
-
-{% highlight yaml %}
-{% readj example_yaml/appserver-clustered-w-db.yaml %}
-{% endhighlight %}
-
-This sets up Nginx as the controller by default, but that can be configured
-using the `controllerSpec` key. In fact, JBoss is the default appserver,
-and because configuration in Brooklyn is inherited by default,
-the same blueprint can be expressed more concisely as:
-
-{% highlight yaml %}
-{% readj example_yaml/appserver-clustered-w-db-concise.yaml %}
-{% endhighlight %}
- 
-The other nicety supplied by the `ControlledDynamicWebAppCluster` blueprint is that
-it aggregates sensors from the appserver, so we have access to things like
-`webapp.reqs.perSec.windowed.perNode`.
-These are convenient for plugging in to policies!
-We can set up our blueprint to do autoscaling based on requests per second
-(keeping it in the range 10..100, with a maximum of 5 appserver nodes)
-as follows: 
-
-{% highlight yaml %}
-{% readj example_yaml/appserver-w-policy.yaml %}
-{% endhighlight %}
-
-Use your favorite load-generation tool (`jmeter` is one good example) to send a huge
-volume of requests against the server and see the policies kick in to resize it.
-
-
-## New Custom Entities
-
-So far we've covered how to configure and compose entities.
-There's a large library of blueprints available, but
-there are also times when you'll want to write your own.
-
-For complex use cases, you can write JVM, but for many common situations,
-some of the highly-configurable blueprints make it easy to write in YAML,
-including `bash` and Chef.
- 
-
-### Vanilla Software using `bash`
-
-The following blueprint shows how a simple script can be embedded in the YAML
-(the `|` character is special YAML which makes it easier to insert multi-line text):
-
-{% highlight yaml %}
-{% readj example_yaml/vanilla-bash-netcat.yaml %}
-{% endhighlight %}
-
-This starts a simple `nc` listener on port 4321 which will respond `hello` to the first
-session which connects to it. Test it by running `telnet localhost 4321`.  
-
-This is just a simple script, but it shows how any script can be easily embedded here,
-including a script to download and run other artifacts.
-Many artifacts are already packaged such that they can be downloaded and launched 
-with a simple script, and `VanillaSoftwareProcess` can also be used for them. 
-We can specify a `download.url` which downloads artifacts (unpacking TAR, TGZ, and ZIP archives)
-before running `launch.command` relative to where that file is installed (or unpacked),
-with `./start.sh` being the default `launch.command`.
-
-So if we create a file `/tmp/netcat-server.tgz` containing just `start.sh` in the root
-which consists of the two lines in the previous example,
-we can instead write our example as: 
-
-{% highlight yaml %}
-{% readj example_yaml/vanilla-bash-netcat-file.yaml %}
-{% endhighlight %}
-
-The one requirement of the script is that it store the process ID (PID) in the file
-pointed to by `$PID_FILE`, hence the second line of the script.
-This is because Brooklyn wants to monitor the services under management. 
-(There are other options; you can set `checkRunning.command` and `stop.command` instead,
-as documented on the Javadoc of the `VanillaSoftwareProcess` class,
-and those scripts will be used instead of checking and stopping the process whose PID is in `$PID_FILE`.)
-
-And indeed, once you've run one `telnet` to the server, you'll see that the 
-service has gone "on fire" in Brooklyn -- because the `nc` process has stopped. 
-Besides detecting this failure, Brooklyn policies can be added to the YAML to take appropriate 
-action. A simple recovery here might just be to restart the process:
-
-{% highlight yaml %}
-{% readj example_yaml/vanilla-bash-netcat-restarter.yaml %}
-{% endhighlight %}
-
-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,
-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).
-Running with this blueprint, you'll see that the service shows as on fire for 15s after a `telnet`,
-before the policy restarts it. 
-
-For an even more interesting way to test it, look at the blueprint defining
-[a netcat server and client](example_yaml/vanilla-bash-netcat-w-client.yaml).
-This uses `initializers` to define an effector to `sayHiNetcat` on the `Simple Pinger` client,
-using `env` variables to inject the `netcat-server` location and 
-`parameters` to pass in per-effector data:
-
-      env:
-        TARGET_HOSTNAME: $brooklyn:component("netcat-server").attributeWhenReady("host.name")
-      brooklyn.initializers:
-      - type: brooklyn.entity.software.ssh.SshCommandEffector
-        brooklyn.config:
-          name: sayHiNetcat
-          description: Echo a small hello string to the netcat entity
-          command: |
-            echo $message | nc $TARGET_HOSTNAME 4321
-          parameters:
-            message:
-              description: The string to pass to netcat
-              defaultValue: hi netcat
-
-This blueprint also uses initializers to define sensors on the `netcat-server` entity
-so that the `$message` we passed above gets logged and reported back:
-
-      launch.command: |
-        echo hello | nc -l 4321 >> server-input &
-        echo $! > $PID_FILE
-      brooklyn.initializers:
-      - type: brooklyn.entity.software.ssh.SshCommandSensor
-        brooklyn.config:
-          name: output.last
-          command: tail -1 server-input
-
-This is still a simple example, but worth going through carefully.
-It shows many of the building blocks used in real-world blueprints,
-and how they can often be easily described and combined in Brooklyn YAML blueprints.
-Next, if you need to drive off-piste, or you want to write tests against these blueprints,
-have a look at, for example, `VanillaBashNetcatYamlTest.java` in the Brooklyn codebase,
-or follow the other references below.
-
-<!--
-TODO building up children entities
-
--->
-
-<!--
-
-### Using Chef Recipes
-
-TODO
-
--->
-
-
-### More Information
-
-Plenty of examples of blueprints exist in the Brooklyn codebase,
-so a good starting point is to [`git clone`]({{ site.url }}/dev/code/index.html) it
-and search for `*.yaml` files therein.
-
-Brooklyn lived as a Java framework for many years before we felt confident
-to make a declarative front-end, so you can do pretty much anything you want to
-by dropping to the JVM. Information on that is available:
-* in the [user guide]({{site.url}}/use/guide/entities/index.html),
-* through a [Maven archetype]({{site.url}}/use/guide/defining-applications/archetype.html),
-* in the [codebase](https://github.com/brooklyncentral/brooklyn),
-* and in plenty of [examples]({{site.url}}/use/examples/index.html).
-
-You can also come talk to us, on IRC (#brooklyncentral on Freenode) or
-any of the usual [hailing frequencies]({{site.url}}/meta/contact.html),
-as these documents are a work in progress.

http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/201818b0/docs/use/guide/defining-applications/deploying-yaml.md
----------------------------------------------------------------------
diff --git a/docs/use/guide/defining-applications/deploying-yaml.md b/docs/use/guide/defining-applications/deploying-yaml.md
deleted file mode 100644
index 265f496..0000000
--- a/docs/use/guide/defining-applications/deploying-yaml.md
+++ /dev/null
@@ -1,37 +0,0 @@
----
-title: Deploying YAML Blueprints
-layout: page
-toc: ../guide_toc.json
-categories: [use, guide, defining-applications]
----
-
-Once you've [written a YAML blueprint](creating-yaml.md), there are several ways to deploy it.
-These insructions assume you have [installed]({{ site.url }}/use/guide/quickstart/) Brooklyn.
-You can then:
-
-- Supply the YAML blueprint file on the CLI when launching the server:
-
-{% highlight bash %}
-$ brooklyn launch --app ./blueprint.yaml
-{% endhighlight %}
-
-
-Or, assuming you've launched a server already 
-(usually on [http://127.0.0.1/](http://127.0.0.1/) unless you've 
-configured security in [`brooklyn.properties`](/use/guide/quickstart/brooklyn.properties)),
-you can:
-
-- Curl it to the Brooklyn REST API:
-
-{% highlight bash %}
-$ curl -T ./blueprint.yaml -X POST http://localhost:8081/v1/applications
-{% endhighlight %}
-
-
-- In the web-console, select the "YAML" tab in the "Add Application" wizard:
-
-[![Web Console](web-console-yaml-700.png "YAML via Web Console")](web-console-yaml.png)
-
-
-- The web-console also has an interactive "REST API" page,
-  where you can paste the YAML for uploading into the `POST` to `/v1/applications`.

http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/201818b0/docs/use/guide/defining-applications/example_files/tomcat_multi-location.java
----------------------------------------------------------------------
diff --git a/docs/use/guide/defining-applications/example_files/tomcat_multi-location.java b/docs/use/guide/defining-applications/example_files/tomcat_multi-location.java
deleted file mode 100644
index cb92766..0000000
--- a/docs/use/guide/defining-applications/example_files/tomcat_multi-location.java
+++ /dev/null
@@ -1,15 +0,0 @@
-// TODO Untested code; see brooklyn-example for better maintained examples!
-public class TomcatFabricApp extends AbstractApplication {
-    @Override
-    public void init() {
-        addChild(EntitySpec.create(DynamicFabric.class)
-                .configure("displayName", "WebFabric")
-                .configure("displayNamePrefix", "")
-                .configure("displayNameSuffix", " web cluster")
-                .configure("memberSpec", EntitySpec.create(ControlledDynamicWebAppCluster.class)
-                        .configure("initialSize", 2)
-                        .configure("memberSpec", : EntitySpec.create(TomcatServer.class)
-                                .configure("httpPort", "8080+")
-                                .configure("war", "/path/to/booking-mvc.war"))));
-    }
-}

http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/201818b0/docs/use/guide/defining-applications/example_files/tomcat_nginx.java
----------------------------------------------------------------------
diff --git a/docs/use/guide/defining-applications/example_files/tomcat_nginx.java b/docs/use/guide/defining-applications/example_files/tomcat_nginx.java
deleted file mode 100644
index 20db33d..0000000
--- a/docs/use/guide/defining-applications/example_files/tomcat_nginx.java
+++ /dev/null
@@ -1,17 +0,0 @@
-// TODO Untested code; see brooklyn-example for better maintained examples!
-public class TomcatClusterWithNginxApp extends AbstractApplication {
-    @Override
-    public void init() {
-        addChild(EntitySpec.create(NginxController.class)
-                .configure("domain", "brooklyn.geopaas.org")
-                .configure("port", "8000+")
-                .configure("portNumberSensor", Attributes.HTTP_PORT));
-        
-        addChild(EntitySpec.create(ControlledDynamicWebAppCluster.class)
-                .configure("controller", nginxController)
-                .configure("memberSpec", : EntitySpec.create(TomcatServer.class)
-                        .configure("httpPort", "8080+")
-                        .configure("war", "/path/to/booking-mvc.war"))
-                .configure("initialSize", 2));
-    }
-}

http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/201818b0/docs/use/guide/defining-applications/example_files/tomcat_simple.java
----------------------------------------------------------------------
diff --git a/docs/use/guide/defining-applications/example_files/tomcat_simple.java b/docs/use/guide/defining-applications/example_files/tomcat_simple.java
deleted file mode 100644
index 480a333..0000000
--- a/docs/use/guide/defining-applications/example_files/tomcat_simple.java
+++ /dev/null
@@ -1,9 +0,0 @@
-// TODO Untested code; see brooklyn-example for better maintained examples!
-public class TomcatServerApp extends AbstractApplication {
-    @Override
-    public void init() {
-        addChild(EntitySpec.create(TomcatServer.class)
-                .configure("httpPort", "8080+")
-                .configure("war", "/path/to/booking-mvc.war")));
-    }
-}

http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/201818b0/docs/use/guide/defining-applications/example_yaml/appserver-clustered-w-db-concise.yaml
----------------------------------------------------------------------
diff --git a/docs/use/guide/defining-applications/example_yaml/appserver-clustered-w-db-concise.yaml b/docs/use/guide/defining-applications/example_yaml/appserver-clustered-w-db-concise.yaml
deleted file mode 100644
index 062c09f..0000000
--- a/docs/use/guide/defining-applications/example_yaml/appserver-clustered-w-db-concise.yaml
+++ /dev/null
@@ -1,15 +0,0 @@
-name: appserver-clustered-w-db-concise
-services:
-- type: brooklyn.entity.webapp.ControlledDynamicWebAppCluster
-  initialSize: 2
-  brooklyn.config:
-    wars.root: http://search.maven.org/remotecontent?filepath=io/brooklyn/example/brooklyn-example-hello-world-sql-webapp/0.6.0/brooklyn-example-hello-world-sql-webapp-0.6.0.war
-    http.port: 8080+
-    java.sysprops: 
-      brooklyn.example.db.url: $brooklyn:formatString("jdbc:%s%s?user=%s\\&password=%s",
-           component("db").attributeWhenReady("datastore.url"), "visitors", "brooklyn", "br00k11n")
-- type: brooklyn.entity.database.mysql.MySqlNode
-  id: db
-  name: DB HelloWorld Visitors
-  brooklyn.config:
-    datastore.creation.script.url: https://github.com/brooklyncentral/brooklyn/raw/master/usage/launcher/src/test/resources/visitors-creation-script.sql

http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/201818b0/docs/use/guide/defining-applications/example_yaml/appserver-clustered-w-db.yaml
----------------------------------------------------------------------
diff --git a/docs/use/guide/defining-applications/example_yaml/appserver-clustered-w-db.yaml b/docs/use/guide/defining-applications/example_yaml/appserver-clustered-w-db.yaml
deleted file mode 100644
index a7b3c57..0000000
--- a/docs/use/guide/defining-applications/example_yaml/appserver-clustered-w-db.yaml
+++ /dev/null
@@ -1,18 +0,0 @@
-name: appserver-clustered-w-db
-services:
-- type: brooklyn.entity.webapp.ControlledDynamicWebAppCluster
-  initialSize: 2
-  memberSpec:
-    $brooklyn:entitySpec:
-      type: brooklyn.entity.webapp.jboss.JBoss7Server
-      brooklyn.config:
-        wars.root: http://search.maven.org/remotecontent?filepath=io/brooklyn/example/brooklyn-example-hello-world-sql-webapp/0.6.0/brooklyn-example-hello-world-sql-webapp-0.6.0.war
-        http.port: 8080+
-        java.sysprops: 
-          brooklyn.example.db.url: $brooklyn:formatString("jdbc:%s%s?user=%s\\&password=%s",
-              component("db").attributeWhenReady("datastore.url"), "visitors", "brooklyn", "br00k11n")
-- type: brooklyn.entity.database.mysql.MySqlNode
-  id: db
-  name: DB HelloWorld Visitors
-  brooklyn.config:
-    datastore.creation.script.url: https://github.com/brooklyncentral/brooklyn/raw/master/usage/launcher/src/test/resources/visitors-creation-script.sql

http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/201818b0/docs/use/guide/defining-applications/example_yaml/appserver-configured-in-config.yaml
----------------------------------------------------------------------
diff --git a/docs/use/guide/defining-applications/example_yaml/appserver-configured-in-config.yaml b/docs/use/guide/defining-applications/example_yaml/appserver-configured-in-config.yaml
deleted file mode 100644
index 50c1873..0000000
--- a/docs/use/guide/defining-applications/example_yaml/appserver-configured-in-config.yaml
+++ /dev/null
@@ -1,6 +0,0 @@
-name: appserver-configured-in-config
-services:
-- type: brooklyn.entity.webapp.jboss.JBoss7Server
-  brooklyn.config:
-    wars.root: http://search.maven.org/remotecontent?filepath=io/brooklyn/example/brooklyn-example-hello-world-sql-webapp/0.6.0/brooklyn-example-hello-world-sql-webapp-0.6.0.war
-    http.port: 8080

http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/201818b0/docs/use/guide/defining-applications/example_yaml/appserver-configured.yaml
----------------------------------------------------------------------
diff --git a/docs/use/guide/defining-applications/example_yaml/appserver-configured.yaml b/docs/use/guide/defining-applications/example_yaml/appserver-configured.yaml
deleted file mode 100644
index 04ec858..0000000
--- a/docs/use/guide/defining-applications/example_yaml/appserver-configured.yaml
+++ /dev/null
@@ -1,5 +0,0 @@
-name: appserver-configured
-services:
-- type: brooklyn.entity.webapp.jboss.JBoss7Server
-  war: http://search.maven.org/remotecontent?filepath=io/brooklyn/example/brooklyn-example-hello-world-sql-webapp/0.6.0/brooklyn-example-hello-world-sql-webapp-0.6.0.war
-  httpPort: 8080

http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/201818b0/docs/use/guide/defining-applications/example_yaml/appserver-w-db-other-flavor.yaml
----------------------------------------------------------------------
diff --git a/docs/use/guide/defining-applications/example_yaml/appserver-w-db-other-flavor.yaml b/docs/use/guide/defining-applications/example_yaml/appserver-w-db-other-flavor.yaml
deleted file mode 100644
index 784f7fd..0000000
--- a/docs/use/guide/defining-applications/example_yaml/appserver-w-db-other-flavor.yaml
+++ /dev/null
@@ -1,17 +0,0 @@
-name: appserver-w-db-other-flavor
-services:
-- type: brooklyn.entity.webapp.tomcat.TomcatServer
-  name: AppServer HelloWorld 
-  brooklyn.config:
-    wars.root: http://search.maven.org/remotecontent?filepath=io/brooklyn/example/brooklyn-example-hello-world-sql-webapp/0.6.0/brooklyn-example-hello-world-sql-webapp-0.6.0.war
-    http.port: 8080+
-    java.sysprops: 
-      brooklyn.example.db.url: $brooklyn:formatString("jdbc:%s%s?user=%s\\&password=%s",
-         component("db").attributeWhenReady("datastore.url"), "visitors", "brooklyn", "br00k11n")
-- type: brooklyn.entity.database.mariadb.MariaDbNode
-  id: db
-  name: DB HelloWorld Visitors
-  brooklyn.config:
-    datastore.creation.script.url: https://github.com/brooklyncentral/brooklyn/raw/master/usage/launcher/src/test/resources/visitors-creation-script.sql
-    provisioning.properties:
-      minRam: 8192

http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/201818b0/docs/use/guide/defining-applications/example_yaml/appserver-w-db.yaml
----------------------------------------------------------------------
diff --git a/docs/use/guide/defining-applications/example_yaml/appserver-w-db.yaml b/docs/use/guide/defining-applications/example_yaml/appserver-w-db.yaml
deleted file mode 100644
index 5a16c0d..0000000
--- a/docs/use/guide/defining-applications/example_yaml/appserver-w-db.yaml
+++ /dev/null
@@ -1,15 +0,0 @@
-name: appserver-w-db
-services:
-- type: brooklyn.entity.webapp.jboss.JBoss7Server
-  name: AppServer HelloWorld 
-  brooklyn.config:
-    wars.root: http://search.maven.org/remotecontent?filepath=io/brooklyn/example/brooklyn-example-hello-world-sql-webapp/0.6.0/brooklyn-example-hello-world-sql-webapp-0.6.0.war
-    http.port: 8080+
-    java.sysprops: 
-      brooklyn.example.db.url: $brooklyn:formatString("jdbc:%s%s?user=%s\\&password=%s",
-         component("db").attributeWhenReady("datastore.url"), "visitors", "brooklyn", "br00k11n")
-- type: brooklyn.entity.database.mysql.MySqlNode
-  id: db
-  name: DB HelloWorld Visitors
-  brooklyn.config:
-    datastore.creation.script.url: https://github.com/brooklyncentral/brooklyn/raw/master/usage/launcher/src/test/resources/visitors-creation-script.sql

http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/201818b0/docs/use/guide/defining-applications/example_yaml/appserver-w-policy.yaml
----------------------------------------------------------------------
diff --git a/docs/use/guide/defining-applications/example_yaml/appserver-w-policy.yaml b/docs/use/guide/defining-applications/example_yaml/appserver-w-policy.yaml
deleted file mode 100644
index 757157e..0000000
--- a/docs/use/guide/defining-applications/example_yaml/appserver-w-policy.yaml
+++ /dev/null
@@ -1,26 +0,0 @@
-name: appserver-w-policy
-services:
-- type: brooklyn.entity.webapp.ControlledDynamicWebAppCluster
-  initialSize: 1
-  memberSpec:
-    $brooklyn:entitySpec:
-      type: brooklyn.entity.webapp.jboss.JBoss7Server
-      brooklyn.config:
-        wars.root: http://search.maven.org/remotecontent?filepath=io/brooklyn/example/brooklyn-example-hello-world-sql-webapp/0.6.0/brooklyn-example-hello-world-sql-webapp-0.6.0.war
-        http.port: 8080+
-        java.sysprops: 
-          brooklyn.example.db.url: $brooklyn:formatString("jdbc:%s%s?user=%s\\&password=%s",
-              component("db").attributeWhenReady("datastore.url"), "visitors", "brooklyn", "br00k11n")
-  brooklyn.policies:
-  - policyType: brooklyn.policy.autoscaling.AutoScalerPolicy
-    brooklyn.config:
-      metric: $brooklyn:sensor("brooklyn.entity.webapp.DynamicWebAppCluster", "webapp.reqs.perSec.windowed.perNode")
-      metricLowerBound: 10
-      metricUpperBound: 100
-      minPoolSize: 1
-      maxPoolSize: 5
-- type: brooklyn.entity.database.mysql.MySqlNode
-  id: db
-  name: DB HelloWorld Visitors
-  brooklyn.config:
-    datastore.creation.script.url: https://github.com/brooklyncentral/brooklyn/raw/master/usage/launcher/src/test/resources/visitors-creation-script.sql

http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/201818b0/docs/use/guide/defining-applications/example_yaml/cluster-vm.yaml
----------------------------------------------------------------------
diff --git a/docs/use/guide/defining-applications/example_yaml/cluster-vm.yaml b/docs/use/guide/defining-applications/example_yaml/cluster-vm.yaml
deleted file mode 100644
index a0a50da..0000000
--- a/docs/use/guide/defining-applications/example_yaml/cluster-vm.yaml
+++ /dev/null
@@ -1,12 +0,0 @@
-name: cluster-vm
-services:
-- type: brooklyn.entity.group.DynamicCluster
-  initialSize: 5
-  memberSpec:
-    $brooklyn:entitySpec:
-      type: brooklyn.entity.basic.EmptySoftwareProcess
-      name: VM
-      provisioning.properties:
-        minRam: 8g
-        minCores: 4
-        minDisk: 100g

http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/201818b0/docs/use/guide/defining-applications/example_yaml/mysql-chef-1.yaml
----------------------------------------------------------------------
diff --git a/docs/use/guide/defining-applications/example_yaml/mysql-chef-1.yaml b/docs/use/guide/defining-applications/example_yaml/mysql-chef-1.yaml
deleted file mode 100644
index bdac530..0000000
--- a/docs/use/guide/defining-applications/example_yaml/mysql-chef-1.yaml
+++ /dev/null
@@ -1,24 +0,0 @@
-name: chef-mysql-sample
-services:
-- type: chef:mysql
-  
-  cookbook_urls:
-    # only needed for chef solo; URL can be local to brooklyn, or github, etc...
-    mysql: https://github.com/opscode-cookbooks/mysql/archive/v4.0.12.tar.gz
-    openssl: https://github.com/opscode-cookbooks/openssl/archive/v1.1.0.tar.gz
-    build-essential: https://github.com/opscode-cookbooks/build-essential/archive/v1.4.4.tar.gz
-  
-  launch_run_list: [ "mysql::server" ]
-  launch_attributes:
-    mysql:
-      # these attrs are required by the mysql cookbook under node['mysql']
-      server_root_password: p4ssw0rd
-      server_repl_password: p4ssw0rd
-      server_debian_password: p4ssw0rd
-      # many others are attrs are supported by the cookbook and can be passed here...
-      
-  # how to determine if the process is running and how to kill it
-  # (supported options are `service_name` and `pid_file`; normally you should just pick one.
-  # here we use the pid_file because the service_name varies, mysql on centos, mysqld on ubuntu!)
-  #service_name: mysqld
-  pid_file: /var/run/mysqld/mysqld.pid

http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/201818b0/docs/use/guide/defining-applications/example_yaml/mysql-chef-2.yaml
----------------------------------------------------------------------
diff --git a/docs/use/guide/defining-applications/example_yaml/mysql-chef-2.yaml b/docs/use/guide/defining-applications/example_yaml/mysql-chef-2.yaml
deleted file mode 100644
index ced2dbe..0000000
--- a/docs/use/guide/defining-applications/example_yaml/mysql-chef-2.yaml
+++ /dev/null
@@ -1,28 +0,0 @@
-name: chef-mysql-sample
-services:
-- type: chef:mysql
-  id: db
-  
-  cookbook_urls:
-    # only needed for chef solo; URL can be local to brooklyn, or github, etc...
-    mysql: https://github.com/opscode-cookbooks/mysql/archive/v4.0.12.tar.gz
-    openssl: https://github.com/opscode-cookbooks/openssl/archive/v1.1.0.tar.gz
-    build-essential: https://github.com/opscode-cookbooks/build-essential/archive/v1.4.4.tar.gz
-  
-  launch_run_list: [ "mysql::server" ]
-  launch_attributes:
-    mysql:
-      # these attrs are required by the mysql cookbook under node['mysql']
-      server_root_password: $brooklyn:component("db").config("mysql.password")
-      server_repl_password: $brooklyn:component("db").config("mysql.password")
-      server_debian_password: $brooklyn:component("db").config("mysql.password")
-      # many others are attrs are supported by the cookbook and can be passed here...
-      
-  # how to determine if the process is running and how to kill it
-  # (supported options are `service_name` and `pid_file`; normally you should just pick one.
-  # here we use the pid_file because the service_name varies, mysql on centos, mysqld on ubuntu!)
-  #service_name: mysqld
-  pid_file: /var/run/mysqld/mysqld.pid
-    
-brooklyn.config:
-  mysql.password: p4ssw0rd

http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/201818b0/docs/use/guide/defining-applications/example_yaml/simple-appserver-with-location-byon.yaml
----------------------------------------------------------------------
diff --git a/docs/use/guide/defining-applications/example_yaml/simple-appserver-with-location-byon.yaml b/docs/use/guide/defining-applications/example_yaml/simple-appserver-with-location-byon.yaml
deleted file mode 100644
index 7ba5b0c..0000000
--- a/docs/use/guide/defining-applications/example_yaml/simple-appserver-with-location-byon.yaml
+++ /dev/null
@@ -1,12 +0,0 @@
-name: simple-appserver-with-location-byon
-location:
-  byon:
-    user: brooklyn
-    privateKeyFile: ~/.ssh/brooklyn.pem
-    hosts:
-    - 192.168.0.18
-    - 192.168.0.19
-services:
-- type: brooklyn.entity.webapp.jboss.JBoss7Server
-  location:
-    byon: { hosts: [ 127.0.0.1 ] }

http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/201818b0/docs/use/guide/defining-applications/example_yaml/simple-appserver-with-location.yaml
----------------------------------------------------------------------
diff --git a/docs/use/guide/defining-applications/example_yaml/simple-appserver-with-location.yaml b/docs/use/guide/defining-applications/example_yaml/simple-appserver-with-location.yaml
deleted file mode 100644
index c241ab2..0000000
--- a/docs/use/guide/defining-applications/example_yaml/simple-appserver-with-location.yaml
+++ /dev/null
@@ -1,8 +0,0 @@
-name: simple-appserver-with-location
-location:
-  jclouds:aws-ec2:
-    region: us-east-1
-    identity: AKA_YOUR_ACCESS_KEY_ID
-    credential: <access-key-hex-digits>
-services:
-- type: brooklyn.entity.webapp.jboss.JBoss7Server

http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/201818b0/docs/use/guide/defining-applications/example_yaml/simple-appserver.yaml
----------------------------------------------------------------------
diff --git a/docs/use/guide/defining-applications/example_yaml/simple-appserver.yaml b/docs/use/guide/defining-applications/example_yaml/simple-appserver.yaml
deleted file mode 100644
index 3850b26..0000000
--- a/docs/use/guide/defining-applications/example_yaml/simple-appserver.yaml
+++ /dev/null
@@ -1,4 +0,0 @@
-name: simple-appserver
-location: localhost
-services:
-- type: brooklyn.entity.webapp.jboss.JBoss7Server

http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/201818b0/docs/use/guide/defining-applications/example_yaml/simple-vm.yaml
----------------------------------------------------------------------
diff --git a/docs/use/guide/defining-applications/example_yaml/simple-vm.yaml b/docs/use/guide/defining-applications/example_yaml/simple-vm.yaml
deleted file mode 100644
index 149a1b9..0000000
--- a/docs/use/guide/defining-applications/example_yaml/simple-vm.yaml
+++ /dev/null
@@ -1,8 +0,0 @@
-name: simple-vm
-services:
-- type: brooklyn.entity.basic.EmptySoftwareProcess
-  name: VM
-  provisioning.properties:
-    minRam: 8192mb
-    minCores: 4
-    minDisk: 100gb

http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/201818b0/docs/use/guide/defining-applications/example_yaml/vanilla-bash-netcat-file.yaml
----------------------------------------------------------------------
diff --git a/docs/use/guide/defining-applications/example_yaml/vanilla-bash-netcat-file.yaml b/docs/use/guide/defining-applications/example_yaml/vanilla-bash-netcat-file.yaml
deleted file mode 100644
index 7950b8c..0000000
--- a/docs/use/guide/defining-applications/example_yaml/vanilla-bash-netcat-file.yaml
+++ /dev/null
@@ -1,6 +0,0 @@
-name: Simple Netcat Example From File
-location: localhost
-services:
-- type: brooklyn.entity.basic.VanillaSoftwareProcess
-  name: Simple Netcat Server
-  download.url: file:///tmp/netcat-server.tgz

http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/201818b0/docs/use/guide/defining-applications/example_yaml/vanilla-bash-netcat-restarter.yaml
----------------------------------------------------------------------
diff --git a/docs/use/guide/defining-applications/example_yaml/vanilla-bash-netcat-restarter.yaml b/docs/use/guide/defining-applications/example_yaml/vanilla-bash-netcat-restarter.yaml
deleted file mode 100644
index 1fd70c3..0000000
--- a/docs/use/guide/defining-applications/example_yaml/vanilla-bash-netcat-restarter.yaml
+++ /dev/null
@@ -1,20 +0,0 @@
-name: Simple Netcat Example with Restarter Policy
-location: localhost
-services:
-- type: brooklyn.entity.basic.VanillaSoftwareProcess
-  id: netcat-server
-  name: Simple Netcat Server
-  launch.command: |
-    echo hello | nc -l 4321 &
-    echo $! > $PID_FILE
-  brooklyn.enrichers:
-  - type: brooklyn.policy.ha.ServiceFailureDetector
-    brooklyn.config:
-      # wait 15s after service fails before propagating failure
-      serviceFailedStabilizationDelay: 15s
-  brooklyn.policies:
-  - type: brooklyn.policy.ha.ServiceRestarter
-    brooklyn.config:
-      # repeated failures in a time window can cause the restarter to abort,
-      # propagating the failure; a time window of 0 will mean it always restarts!
-      failOnRecurringFailuresInThisDuration: 0

http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/201818b0/docs/use/guide/defining-applications/example_yaml/vanilla-bash-netcat-w-client.yaml
----------------------------------------------------------------------
diff --git a/docs/use/guide/defining-applications/example_yaml/vanilla-bash-netcat-w-client.yaml b/docs/use/guide/defining-applications/example_yaml/vanilla-bash-netcat-w-client.yaml
deleted file mode 100644
index 50051db..0000000
--- a/docs/use/guide/defining-applications/example_yaml/vanilla-bash-netcat-w-client.yaml
+++ /dev/null
@@ -1,72 +0,0 @@
-name: Simple Netcat with Client
-
-location: localhost
-
-services:
-
-# the netcat server instance, running in listener mode (-l)
-- type: brooklyn.entity.basic.VanillaSoftwareProcess
-  id: netcat-server
-  name: Simple Netcat Server
-  launch.command: |
-    echo hello | nc -l 4321 >> server-input &
-    echo $! > $PID_FILE
-
-  brooklyn.policies:
-  # restarter and 
-  - policyType: brooklyn.policy.ha.ServiceFailureDetector
-    brooklyn.config:
-      # wait 15s after service fails before propagating failure
-      serviceFailedStabilizationDelay: 15s
-  - policyType: brooklyn.policy.ha.ServiceRestarter
-    brooklyn.config:
-      # repeated failures in a time window can cause the restarter to abort,
-      # propagating the failure; a time window of 0 will mean it always restarts!
-      failOnRecurringFailuresInThisDuration: 0
-      
-  brooklyn.initializers:
-  # two sensors, recording the data sent to this netcat server:
-  
-  - type: brooklyn.entity.software.ssh.SshCommandSensor
-    brooklyn.config:
-      name: output.last
-      command: tail -1 server-input
-      
-  - type: brooklyn.entity.software.ssh.SshCommandSensor
-    brooklyn.config:
-      name: output.all
-      command: cat server-input
-
-# a client to hit netcat
-- type: brooklyn.entity.basic.VanillaSoftwareProcess
-  name: Simple Pinger
-  
-  # set the hostname of the netcat instance as an env var for the scripts 
-  env:
-    TARGET_HOSTNAME: $brooklyn:component("netcat-server").attributeWhenReady("host.name")
-    
-  # start/check/stop are no-op
-  launch.command: ""
-  checkRunning.command: ""
-  stop.command: ""
-  
-  brooklyn.initializers:
-  # but there is a sample effector which runs nc in client mode
-  
-  - type: brooklyn.entity.software.ssh.SshCommandEffector
-    brooklyn.config:
-      name: sayHiNetcat
-      description: Echo a small hello string to the netcat entity
-      command: |
-        echo $message | nc $TARGET_HOSTNAME 4321
-      parameters:
-        message:
-          description: The string to pass to netcat
-          defaultValue: hi netcat
-
-# and add an enricher at the root so all sensors from netcat-server are visible on the root
-brooklyn.enrichers:
-- enricherType: brooklyn.enricher.basic.Propagator
-  brooklyn.config:
-    enricher.producer: $brooklyn:component("netcat-server")
-    enricher.propagating.propagatingAll: true

http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/201818b0/docs/use/guide/defining-applications/example_yaml/vanilla-bash-netcat.yaml
----------------------------------------------------------------------
diff --git a/docs/use/guide/defining-applications/example_yaml/vanilla-bash-netcat.yaml b/docs/use/guide/defining-applications/example_yaml/vanilla-bash-netcat.yaml
deleted file mode 100644
index d4cb37b..0000000
--- a/docs/use/guide/defining-applications/example_yaml/vanilla-bash-netcat.yaml
+++ /dev/null
@@ -1,18 +0,0 @@
-name: Simple Netcat Server Example
-location: localhost
-services:
-- type: brooklyn.entity.basic.VanillaSoftwareProcess
-  name: Simple Netcat Server
-  launch.command: |
-    echo hello | nc -l 4321 &
-    echo $! > $PID_FILE
-
-  # The following overrides demonstrate the use of a custom shell environment as well as
-  # check-running and stop commands. These are optional; default behavior will "do the
-  # right thing" with the pid file automatically.
-
-  env:                  { CHECK_MARKER: "checkRunning", STOP_MARKER: "stop" }
-  checkRunning.command: echo $CHECK_MARKER >> DATE && test -f "$PID_FILE" && ps -p `cat $PID_FILE` >/dev/null
-  stop.command:         echo $STOP_MARKER  >> DATE && test -f "$PID_FILE" && { kill -9 `cat $PID_FILE`; rm /tmp/vanilla.pid; }
-
-# can also define download.url, in which case the launch command defaults to ./start.sh in that (archive) file

http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/201818b0/docs/use/guide/defining-applications/examples.md
----------------------------------------------------------------------
diff --git a/docs/use/guide/defining-applications/examples.md b/docs/use/guide/defining-applications/examples.md
deleted file mode 100644
index b61f119..0000000
--- a/docs/use/guide/defining-applications/examples.md
+++ /dev/null
@@ -1,120 +0,0 @@
----
-title: Examples
-layout: page
-toc: ../guide_toc.json
-categories: [use, guide, defining-applications]
----
-
-** TODO: this examples page is deprecated;
-code is out-of-date, and better examples are described on the web site.
-need to figure out if this page should be kept at all
-(indeed if the "guide" is even still relevant)**
-
-
-### Integrating with a Maven project
-
-If you have a Maven-based project, integrate this XML fragment with your pom.xml:
-
-<!-- TODO this should import from the downloads page -->
-
-{% highlight xml %}
-<dependencies>
-	<dependency>
-		<groupId>io.brooklyn</groupId>
-		<artifactId>brooklyn-all</artifactId>
-		<version>0.7.0-M2-incubating</version>  <!-- BROOKLYN_VERSION -->
-	</dependency>
-</dependencies>
- 
-<repository>
-    <id>cloudsoft-releases</id>
-    <url>http://developers.cloudsoftcorp.com/download/maven2/</url>
-</repository>
-<repository>
-    <id>libs-snapshot-local</id>
-    <url>http://ccweb.cloudsoftcorp.com/maven/libs-snapshot-local/</url>
-    <snapshots>
-        <enabled>true</enabled>
-        <updatePolicy>never</updatePolicy>
-        <checksumPolicy>fail</checksumPolicy>
-    </snapshots>
-</repository>
-{% endhighlight %}
-
-
-### Starting a Tomcat Server
-
-The code below starts a Tomcat server on the local machine.
-
-The ``main`` method defines the application, and passes it to the ``BrooklynLauncher`` to be managed. 
-It is then started in a localhost location (other locations are shown in the next section).
-
-The Tomcat's configuration indicates that the given WAR should be deployed to the Tomcat server when it is started.
-
-{% highlight java %}
-{% readj example_files/tomcat_simple.java %}
-{% endhighlight %}
-
-The ``wars`` config is also supported (with config keys ``ROOT_WAR`` and ``NAMED_WARS`` the long-hand syntax);
-they accept EARs and other common archives, and can be described as files or as URLs (as Strings), 
-with URLs supporting an optional ``classpath://org/acme/resources/xxx.war`` syntax.
-
-
-### Starting Tomcat in Amazon EC2
-
-To start a tomcat node or cluster in Amazon EC2, the application is identical to that for localhost. 
-The only difference is the location supplied.
-
-The Brooklyn CLI can be used to launch the application in your choice of location, such as:
-
-{% highlight bash %}
-brooklyn launch --app TomcatServerApp --location localhost
-brooklyn launch --app TomcatServerApp --location aws-ec2:eu-west-1
-{% endhighlight %}
-
- 
-### Starting a Tomcat Cluster with Nginx
-
-The code below starts a Tomcat cluster along with an Nginx instance, where each Tomcat server in the cluster is registered with the Nginx instance.
-
-{% highlight java %}
-{% readj example_files/tomcat_nginx.java %}
-{% endhighlight %}
-
-This creates a cluster that of Tomcat servers, along with an Nginx instance. The ``NginxController`` instance
-is notified whenever a member of the cluster joins or leaves; the entity is configured to look at the ``HTTP_PORT``
-attribute of that instance so that the Nginx configuration can be updated with the ip:port of the cluster member.
-
-<!---
-TODO things may need tidying (paragraphs, and/or eliminating any extra setConfig calls, though looks like these have gone)
--->
-
-
-Starting a Multi-location Tomcat Fabric
----------------------------------------
-
-<!---
-TODO this example should use several cloud providers, including Openshift, and use GeoDNS, 
-and maybe a data store and/or messaging service; it is the last "most advanced" example
--->
-
-<!---
-FIXME Discuss above comment with Aled/Alex as it is contentious
--->
-
-The ``ControlledDynamicWebAppCluster`` entity used above can also be used with a DynamicFabric to start
-a web-cluster in each location.
-
-{% highlight java %}
-{% readj example_files/tomcat_multi-location.java %}
-{% endhighlight %}
-
-
-Examples Source
----------------
-
-Source code for (more up-to-date!) examples is available for download from GitHub. To retrieve the source, execute the following command:
-
-    git clone git@github.com:brooklyncentral/brooklyn-examples.git
-
-You can also [browse the code](https://github.com/brooklyncentral/brooklyn-examples) on the web.

http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/201818b0/docs/use/guide/defining-applications/service-state.md
----------------------------------------------------------------------
diff --git a/docs/use/guide/defining-applications/service-state.md b/docs/use/guide/defining-applications/service-state.md
deleted file mode 100644
index b142fb1..0000000
--- a/docs/use/guide/defining-applications/service-state.md
+++ /dev/null
@@ -1,73 +0,0 @@
----
-title: Service State
-layout: page
-toc: ../guide_toc.json
-categories: [use, guide, defining-applications]
----
-
-Any entity can use the standard "service-up" and "service-state" 
-sensors to inform other entities and the GUI about its status.
-
-In normal operation, entities should publish at least one "service not-up indicator",
-using the `ServiceNotUpLogic.updateNotUpIndicator` method.  Each such indicator should have
-a unique name or input sensor.  `Attributes.SERVICE_UP` will then be updated automatically
-when there are no not-up indicators.
-
-When there are transient problems that can be detected, to trigger `ON_FIRE` status
-entity code can similarly set `ServiceProblemsLogic.updateProblemsIndicator` with a unique namespace,
-and subsequently clear it when the problem goes away.
-These problems are reflected at runtime in the `SERVICE_PROBLEMS` sensor,
-allowing multiple problems to be tracked independently.
-
-When an entity is changing the expected state, e.g. starting or stopping,
-the expected state can be set using `ServiceStateLogic.setExpectedState`;
-this expected lifecycle state is considered together with `SERVICE_UP` and `SERVICE_PROBLEMS`
-to compute the actual state.  By default the logic in `ComputeServiceState` is applied.
-
-For common entities, good out-of-the-box logic is applied, as follows:
-
-* For `SoftwareProcess` entities, lifecycle service state is updated by the framework
-  and a service not-up indicator is linked to the driver `isRunning()` check.
-  
-* For common parents, including `AbstractApplication` and `AbstractGroup` subclasses (including clusters, fabrics, etc),
-  the default enrichers analyse children and members to set a not-up indicator
-  (requiring at least one child or member who is up) and a problem indicator
-  (if any children or members are on-fire).
-  In some cases other quorum checks are preferable; this can be set e.g. by overriding 
-  the `UP_QUORUM_CHECK` or the `RUNNING_QUORUM_CHECK`, as follows:
-  
-      public static final ConfigKey<QuorumCheck> UP_QUORUM_CHECK = ConfigKeys.newConfigKeyWithDefault(AbstractGroup.UP_QUORUM_CHECK, 
-          "Require all children and members to be up for this node to be up",
-          QuorumChecks.all());
-
-  Alternatively the `initEnrichers()` method can be overridden to specify a custom-configured
-  enricher or set custom config key values (as done e.g. in `DynamicClusterImpl` so that
-  zero children is permitted provided when the initial size is configured to be 0).
-
-
-For sample code to set and more information on these methods' behaviours,
-see javadoc in `ServiceStateLogic`,
-overrides of `AbstractEntity.initEnrichers()`
-and tests in `ServiceStateLogicTests`.
-
-<!-- TODO include more documentation, sample code (ideally extracted on the fly from test cases so we know it works!) -->
-
-
-## Notes on Advanced Use
-
-The enricher to derive `SERVICE_UP` and `SERVICE_STATE_ACTUAL` from the maps and expected state values discussed above
-is added by the `AbstractEntity.initEnrichers()` method.
-This method can be overridden -- or excluded altogether by by overriding `init()` --
-and can add enrichers created using the `ServiceStateLogic.newEnricherFromChildren()` method
-suitably customized using methods on the returned spec object, for instance to look only at members
-or specify a quorum function (from `QuorumChecks`). 
-If different logic is required for computing `SERVICE_UP` and `SERVICE_STATE_ACTUAL`,
-use `ServiceStateLogic.newEnricherFromChildrenState()` and `ServiceStateLogic.newEnricherFromChildrenUp()`,
-noting that the first of these will replace the enricher added by the default `initEnrichers()`,
-whereas the second one runs with a different namespace (unique tag).
-For more information consult the javadoc on those classes.
-
-Entities can set `SERVICE_UP` and `SERVICE_STATE_ACTUAL` directly.
-Provided these entities never use the `SERVICE_NOT_UP_INDICATORS` and `SERVICE_PROBLEMS` map,
-the default enrichers will not override these values.
-

http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/201818b0/docs/use/guide/defining-applications/toc.json
----------------------------------------------------------------------
diff --git a/docs/use/guide/defining-applications/toc.json b/docs/use/guide/defining-applications/toc.json
deleted file mode 100644
index 08940a8..0000000
--- a/docs/use/guide/defining-applications/toc.json
+++ /dev/null
@@ -1,19 +0,0 @@
-[{ "title": "Basic Concepts",
-  "file":  "{{ site.url }}/use/guide/defining-applications/basic-concepts.html" }, 
-{ "title": "Advanced Concepts",
-  "file":  "{{ site.url }}/use/guide/defining-applications/advanced-concepts.html" }, 
-{ "title": "Common Usage",
-  "file":  "{{ site.url }}/use/guide/defining-applications/common-usage.html" },
-{ "title": "YAML Blueprints",
-  "file":  "{{ site.url }}/use/guide/defining-applications/creating-yaml.html" },
-{ "title": "Chef Blueprints",
-  "file":  "{{ site.url }}/use/guide/defining-applications/chef-blueprints.html" },
-{ "title": "Deploying YAML",
-  "file":  "{{ site.url }}/use/guide/defining-applications/deploying-yaml.html" },
-{ "title": "YAML Reference",
-  "file":  "{{ site.url }}/use/guide/defining-applications/yaml-reference.html" },
-{ "title": "Service State",
-  "file":  "{{ site.url }}/use/guide/defining-applications/service-state.html" },
-{ "title": "Maven Archetype",
-  "file":  "{{ site.url }}/use/guide/defining-applications/archetype.html" }
-]

http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/201818b0/docs/use/guide/defining-applications/web-console-yaml-700.png
----------------------------------------------------------------------
diff --git a/docs/use/guide/defining-applications/web-console-yaml-700.png b/docs/use/guide/defining-applications/web-console-yaml-700.png
deleted file mode 100644
index d6a2249..0000000
Binary files a/docs/use/guide/defining-applications/web-console-yaml-700.png and /dev/null differ


Mime
View raw message