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/01 18:45:46 UTC
[38/51] [abbrv] [partial] brooklyn-docs git commit: move subdir from
incubator up a level as it is promoted to its own repo (first non-incubator
commit!)
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/blueprinting-tips.md
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/yaml/blueprinting-tips.md b/brooklyn-docs/guide/yaml/blueprinting-tips.md
deleted file mode 100644
index 6f02746..0000000
--- a/brooklyn-docs/guide/yaml/blueprinting-tips.md
+++ /dev/null
@@ -1,105 +0,0 @@
----
-title: Blueprinting Tips
-layout: website-normal
----
-
-## YAML Recommended
-
-The recommended way to write a blueprint is as a YAML file. This is true both for building
-an application out of existing blueprints, and for building new integrations.
-
-The use of Java is reserved for those use-cases where the provisioning or configuration logic
-is very complicated.
-
-
-## Faster Dev-Test
-
-Writing a blueprint is most efficient and simple when testing is fast, and when testing is
-done incrementally as features of the blueprint are written.
-
-The slowest stages of deploying a blueprint are usually VM provisioning and downloading/installing
-of artifacts (e.g. RPMs, zip files, etc).
-
-Options for speeding up provisioning include those below.
-
-### Deploying to the "localhost" location
-
-This is fast and simple, but has some obvious downsides:
-
-* Artifacts are installed directly on your desktop/server.
-
-* The artifacts installed during previous runs can interfere with subsequent runs.
-
-* Some entities require `sudo` rights, which must be granted to the user running Brooklyn.
-
-
-### Deploying to Bring Your Own Nodes (BYON)
-
-A BYON location can be defined, which avoids the time required to provision VMs. This is fast,
-but has the downside that artifacts installed during a previous run can interfere with subsequent
-runs.
-
-A variant of this is to use Vagrant (e.g. with VirtualBox) to create VMs on your local machine,
-and to use these as the target for a BYON location.
-
-
-### Deploying to Clocker
-
-Docker containers provide a convenient way to test blueprints (and also to run blueprints in
-production!).
-
-The [Clocker project](www.clocker.io) allows the simple setup of Docker Engine(s), and for Docker
-containers to be used instead of VMs. For testing, this allows each run to start from a fresh
-container (i.e. no install artifacts from previous runs), while taking advantage of the speed
-of starting containers.
-
-
-### Caching Install Artifacts
-
-To avoid re-downloading install artifacts on every run, these can be saved to `~/.brooklyn/repository/`.
-The file structure is a sub-directory with the entity's simple name, then a sub-directory with the
-version number, and then the files to be downloaded. For example,
-`~/.brooklyn/repository/TomcatServer/7.0.56/apache-tomcat-7.0.56.tar.gz`.
-
-If using BYON or localhost, the install artifacts will by default be installed to a directory like
-`/tmp/brooklyn-myname/installs/`. If install completed successfully, then the install stage will
-be subsequently skipped. To re-test the install phase, delete the install directory (e.g. delete
-`/tmp/brooklyn-myname/installs/TomcatServer_7.0.56/`).
-
-Where installation used something like `apt-get install` or `yum install`, then re-testing the
-install phase will require uninstalling these artifacts manually.
-
-
-## Custom Entity Development
-
-If writing a custom integration, the following recommendations may be useful:
-
-* For the software to be installed, use its Installation and Admin guides to ensure best practices
- are being followed. Use blogs and advice from experts, when available.
-
-* Where there is a choice of installation approaches, use the approach that is most appropriate for
- production use-cases (even if this is harder to test on locahost). For example,
- prefer the use of RPMs versus unpacking zip files, and prefer the use of services versus invoking
- a `bin/start` script.
-
-* Ensure every step is scriptable (e.g. manual install does not involve using a text editor to
- modify configuration files, or clicking on things in a web-console).
-
-* Write scripts (or Chef recipes, or Puppet manifests, etc), and test these by executing manually.
- Only once these work in isolation, add them to the entity blueprint.
-
-* Externalise the configuration where appropriate. For example, if there is a configuration file
- then include a config key for the URL of the configuration file to use. Consider using FreeMarker
- templating for such configuration files.
-
-* Focus on a single OS distro/version first, and clearly document these assumptions.
-
-* Breakdown the integration into separate components, where possible (and thus develop/test them separately).
- For example, if deploying a MongoDB cluster then first focus on single-node MongoDB, and then make that
- configurable and composable for a cluster.
-
-* Use the test framework to write test cases, so that others can run these to confirm that the
- entity works in their environment.
-
-* Where appropriate, share the new entity with the Brooklyn community so that it can be reviewed,
- tested and improved by others in the community!
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/chef/about-chef.md
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/yaml/chef/about-chef.md b/brooklyn-docs/guide/yaml/chef/about-chef.md
deleted file mode 100644
index db3ec3c..0000000
--- a/brooklyn-docs/guide/yaml/chef/about-chef.md
+++ /dev/null
@@ -1,50 +0,0 @@
----
-title: About Chef
-title_in_menu: About Chef
-layout: website-normal
----
-
-## 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-call-flow.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.
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/chef/advanced-chef-integration.md
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/yaml/chef/advanced-chef-integration.md b/brooklyn-docs/guide/yaml/chef/advanced-chef-integration.md
deleted file mode 100644
index 0d65286..0000000
--- a/brooklyn-docs/guide/yaml/chef/advanced-chef-integration.md
+++ /dev/null
@@ -1,48 +0,0 @@
----
-title: Advanced Chef Integration
-title_in_menu: Advanced Chef Integration
-layout: website-normal
----
-
-### 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:
-
-{% highlight yaml %}
-- 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
-{% endhighlight %}
-
-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/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/chef/chef-call-flow.png
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/yaml/chef/chef-call-flow.png b/brooklyn-docs/guide/yaml/chef/chef-call-flow.png
deleted file mode 100644
index d899de2..0000000
Binary files a/brooklyn-docs/guide/yaml/chef/chef-call-flow.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/chef/creating-blueprints.md
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/yaml/chef/creating-blueprints.md b/brooklyn-docs/guide/yaml/chef/creating-blueprints.md
deleted file mode 100644
index 8d30131..0000000
--- a/brooklyn-docs/guide/yaml/chef/creating-blueprints.md
+++ /dev/null
@@ -1,105 +0,0 @@
----
-title: Creating Blueprints from Chef
-title_in_menu: Creating Blueprints from Chef
-layout: website-normal
----
-
-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.)*
-
-Notice, if you target `google-compute-engine` location, you may need to specify `bind_address: 0.0.0.0` for the `mysql` cookbook, as described [here](https://github.com/chef-cookbooks/mysql/blob/46dccac22d282a05ee6a401e10ae8f5f8114fd66/README.md#parameters).
-
-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 (`org.apache.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!
-
-
-
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/chef/example_yaml/mysql-chef-1.yaml
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/yaml/chef/example_yaml/mysql-chef-1.yaml b/brooklyn-docs/guide/yaml/chef/example_yaml/mysql-chef-1.yaml
deleted file mode 100644
index bdac530..0000000
--- a/brooklyn-docs/guide/yaml/chef/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/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/chef/example_yaml/mysql-chef-2.yaml
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/yaml/chef/example_yaml/mysql-chef-2.yaml b/brooklyn-docs/guide/yaml/chef/example_yaml/mysql-chef-2.yaml
deleted file mode 100644
index ced2dbe..0000000
--- a/brooklyn-docs/guide/yaml/chef/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/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/chef/index.md
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/yaml/chef/index.md b/brooklyn-docs/guide/yaml/chef/index.md
deleted file mode 100644
index f0fa3d0..0000000
--- a/brooklyn-docs/guide/yaml/chef/index.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-title: Chef in YAML Blueprints
-layout: website-normal
-children:
-- about-chef.md
-- creating-blueprints.md
-- writing-chef.md
-- advanced-chef-integration.md
----
-
-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](../).
-
-{% include list-children.html %}
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/chef/writing-chef.md
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/yaml/chef/writing-chef.md b/brooklyn-docs/guide/yaml/chef/writing-chef.md
deleted file mode 100644
index 0593837..0000000
--- a/brooklyn-docs/guide/yaml/chef/writing-chef.md
+++ /dev/null
@@ -1,79 +0,0 @@
----
-title: Writing Chef for Blueprints
-title_in_menu: Writing Chef for Blueprints
-layout: website-normal
----
-
-## Making it Simpler
-
-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.
-
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/clusters-and-policies.md
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/yaml/clusters-and-policies.md b/brooklyn-docs/guide/yaml/clusters-and-policies.md
deleted file mode 100644
index fc65179..0000000
--- a/brooklyn-docs/guide/yaml/clusters-and-policies.md
+++ /dev/null
@@ -1,42 +0,0 @@
----
-title: Clusters and Policies
-layout: website-normal
-toc: ../guide_toc.json
-categories: [use, guide, defining-applications]
----
-
-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.
-
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/clusters.md
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/yaml/clusters.md b/brooklyn-docs/guide/yaml/clusters.md
deleted file mode 100644
index 78b1df9..0000000
--- a/brooklyn-docs/guide/yaml/clusters.md
+++ /dev/null
@@ -1,34 +0,0 @@
----
-title: Clusters, Specs, and Composition
-layout: website-normal
-toc: ../guide_toc.json
-categories: [use, guide, defining-applications]
----
-
-What if you want multiple machines?
-
-One way is just to repeat the `- type: org.apache.brooklyn.entity.software.base.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.
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/configuring-vms.md
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/yaml/configuring-vms.md b/brooklyn-docs/guide/yaml/configuring-vms.md
deleted file mode 100644
index 97fb9d0..0000000
--- a/brooklyn-docs/guide/yaml/configuring-vms.md
+++ /dev/null
@@ -1,31 +0,0 @@
----
-title: Configuring VMs
-layout: website-normal
-toc: ../guide_toc.json
-categories: [use, guide, defining-applications]
----
-
-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.path.guide }}/concepts/entities.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 [Operations: Locations](../ops/locations/).
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/creating-yaml.md
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/yaml/creating-yaml.md b/brooklyn-docs/guide/yaml/creating-yaml.md
deleted file mode 100644
index ffb1e36..0000000
--- a/brooklyn-docs/guide/yaml/creating-yaml.md
+++ /dev/null
@@ -1,78 +0,0 @@
----
-title: The Basic Structure
-layout: website-normal
-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](../ops/locations/#localhost)
- 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, the clipboard in the top-right corner of the example plan box above (hover your cursor over the box) lets you easily copy-and-paste into the web-console:
-simply [download and launch]({{ site.path.guide }}/start/running.html) Brooklyn,
-then in the "Create Application" dialog at the web console
-(usually [http://127.0.0.1:8081/](http://127.0.0.1:8081/), paste the copied YAML into the "Yaml" tab of the dialog and press "Finish".
-There are several other ways to deploy, including `curl` and via the command-line,
-and you can configure users, https, persistence, and more,
-as described [in the ops guide](../ops/).
-
-[](web-console-yaml.png)
-
-
-
-<!--
-TODO building up children entities
-
--->
-
-
-
-### More Information
-
-Topics to explore next on the topic of YAML blueprints are:
-
-{% include list-children.html %}
-
-Plenty of examples of blueprints exist in the Brooklyn codebase,
-so another starting point is to [`git clone`]({{ site.path.guide }}/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. For more information on Java:
-
-* start with a [Maven archetype]({{site.path.guide}}/java/archetype.html)
-* see all [Brooklyn Java guide]({{site.path.guide}}/java/) topics
-* look at test cases in the [codebase](https://github.com/apache/incubator-brooklyn)
-
-<!--
-TODO
-* review some [examples]({{site.path.guide}}/use/examples/index.html)
--->
-
-You can also come talk to us, on IRC (#brooklyncentral on Freenode) or
-any of the usual [hailing frequencies]({{site.path.website}}/community/),
-as these documents are a work in progress.
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/custom-entities.md
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/yaml/custom-entities.md b/brooklyn-docs/guide/yaml/custom-entities.md
deleted file mode 100644
index 9698aa8..0000000
--- a/brooklyn-docs/guide/yaml/custom-entities.md
+++ /dev/null
@@ -1,238 +0,0 @@
----
-title: Custom Entities
-layout: website-normal
-toc: ../guide_toc.json
-categories: [use, guide, defining-applications]
----
-
-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`
-or opening `http://localhost:4321` in a browser.
-
-Note that it only allows you connect once, and after that it fails.
-This is deliberate! We'll repair this later in this example.
-Until then however, in the *Applications* view you can click the server,
-go to the `Effectors` tab, and click `restart` to bring if back to life.
-
-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.
-
-
-#### Downloading Files
-
-We can specify a `download.url` which downloads an artifact
-(and automatically unpacking TAR, TGZ, and ZIP archives)
-before running `launch.command` relative to where that file is installed (or unpacked),
-with the default `launch.command` being `./start.sh`.
-
-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 %}
-
-
-#### Port Inferencing
-
-If you're deploying to a cloud machine, a firewall might block the port 4321.
-We can tell Brooklyn to open this port explicitly by specifying `inboundPorts: [ 4321 ]`;
-however a more idiomatic way is to specify a config ending with `.port`,
-such as:
-
-{% highlight yaml %}
-{% readj example_yaml/vanilla-bash-netcat-port.yaml %}
-{% endhighlight %}
-
-The regex for ports to be opened can be configured using
-the config `inboundPorts.configRegex` (which has `.*\.port` as the default value).
-
-Config keys of type `org.apache.brooklyn.api.location.PortRange` (aka `port`)
-have special behaviour: when configuring, you can use range notation `8000-8100` or `8000+` to tell Brooklyn
-to find **one** port matching; this is useful when ports might be in use.
-In addition, any such config key will be opened,
-irrespective of whether it matches the `inboundPorts.configRegex`.
-To prevent any inferencing of ports to open, you can set the config `inboundPorts.autoInfer` to `false`.
-
-Note that in the example above, `netcat.port` must be specified in a `brooklyn.config` block.
-This block can be used to hold any config (including for example the `launch.command`),
-but for convenience Brooklyn allows config keys declared on the underlying type
-to be specified up one level, alongside the type.
-However config keys which are *not* declared on the type *must* be declared in the `brooklyn.config` block.
-
-
-#### Declaring New Config Keys
-
-We can define config keys to be presented to the user
-using the `brooklyn.parameters` block:
-
-{% highlight yaml %}
-{% readj example_yaml/vanilla-bash-netcat-port-parameter.yaml %}
-{% endhighlight %}
-
-The example above will allow a user to specify a message to send back
-and the port where netcat will listen.
-The metadata on these parameters is available at runtime in the UI
-and through the API, and is used when populating a catalog.
-
-The example also shows how these values can be passed as environment variables to the launch command.
-The `$brooklyn:config(...)` function returns the config value supplied or default.
-For the type `port`, an attribute sensor is also created to report the *actual* port used after port inference,
-and so the `$brooklyn:attributeWhenReady(...)` function is used.
-(If `$brooklyn:config("netcat.port")` had been used, `4321+` would be passed as `NETCAT_PORT`.)
-
-This gives us quite a bit more power in writing our blueprint:
-
-* Multiple instances of the server can be launched simultaneously on the same host,
- as the `4321+` syntax enables Brooklyn to assign them different ports
-* If this type is added to the catalog, a user can configure the message and the port;
- we'll show this in the next section
-
-
-#### Using the Catalog and Clustering
-
-The *Catalog* tab allows you to add blueprints which you can refer to in other blueprints.
-In that tab, click *+* then *YAML*, and enter the following:
-
-{% highlight yaml %}
-{% readj example_yaml/vanilla-bash-netcat-catalog.bom %}
-{% endhighlight %}
-
-This is the same example as in the previous section, wrapped according to the catalog YAML requirements,
-with one new block added defining an enricher. An enricher creates a new sensor from other values;
-in this case it will create a `main.uri` sensor by populating a `printf`-style string `"http://%s:%s"`
-with the sensor values.
-
-With this added to the catalog, we can reference the type `netcat-example` when we deploy an application.
-Return to the *Home* or *Applications* tab, click *+*, and submit this YAML blueprint:
-
-{% highlight yaml %}
-{% readj example_yaml/vanilla-bash-netcat-reference.yaml %}
-{% endhighlight %}
-
-This extends the previous blueprint which we registered in the catalog,
-meaning that we don't need to include it each time.
-Here, we've elected to supply our own message, but we'll use the default port.
-More importantly, we can package it for others to consume -- or take items others have built.
-
-We can go further and use this to deploy a cluster,
-this time giving a custom port as well as a custom message:
-
-{% highlight yaml %}
-{% readj example_yaml/vanilla-bash-netcat-cluster.yaml %}
-{% endhighlight %}
-
-In either of the above examples, if you explore the tree in the *Applications* view
-and look at the *Summary* tab of any of the server instances, you'll now see the URL where netcat is running.
-But remember, netcat will stop after one run, so you'll only be able to use each link once
-before you have to restart it. You can also run `restart` on the cluster,
-and if you haven't yet experimented with `resize` on the cluster you might want to do that.
-
-
-#### Determining Successful Launch
-
-One requirement of the launch 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.
-You'll observe this if you connect to one of the netcat services,
-as the process exits afterwards and Brooklyn sets the entity to an `ON_FIRE` state.
-(You can also test this with a `killall nc` before connecting
-or issueing a `stop` command on the server -- but not on the example,
-as stopping an application root causes it to be removed altogether!)
-
-There are other options for determining launch: you can set `checkRunning.command` and `stop.command` instead,
-as documented on the javadoc and config keys of the {% include java_link.html class_name="VanillaSoftwareProcess" package_path="org/apache/brooklyn/entity/software/base" project_subpath="software/base" %} class,
-and those scripts will be used instead of checking and stopping the process whose PID is in `$PID_FILE`.
-
-{% highlight yaml %}
-{% readj example_yaml/vanilla-bash-netcat-more-commands.yaml %}
-{% endhighlight %}
-
-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 stops after one run.
-
-
-#### Attaching Policies
-
-Besides detecting this failure, Brooklyn policies can be added to the YAML to take appropriate
-action. A simple recovery here might just to automatically restart the process:
-
-{% 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.
-
-
-### Sensors and Effectors
-
-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: org.apache.brooklyn.core.effector.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: org.apache.brooklyn.core.sensor.ssh.SshCommandSensor
- brooklyn.config:
- name: output.last
- period: 1s
- command: tail -1 server-input
-
-
-#### Summary
-
-These examples are relatively simple example, but they
-illustrate 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.
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/example_yaml/appserver-clustered-w-db-concise.yaml
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/yaml/example_yaml/appserver-clustered-w-db-concise.yaml b/brooklyn-docs/guide/yaml/example_yaml/appserver-clustered-w-db-concise.yaml
deleted file mode 100644
index 0fd8759..0000000
--- a/brooklyn-docs/guide/yaml/example_yaml/appserver-clustered-w-db-concise.yaml
+++ /dev/null
@@ -1,15 +0,0 @@
-name: appserver-clustered-w-db-concise
-services:
-- type: org.apache.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: org.apache.brooklyn.entity.database.mysql.MySqlNode
- id: db
- name: DB HelloWorld Visitors
- brooklyn.config:
- datastore.creation.script.url: https://github.com/apache/incubator-brooklyn/raw/master/usage/launcher/src/test/resources/visitors-creation-script.sql
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/example_yaml/appserver-clustered-w-db.yaml
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/yaml/example_yaml/appserver-clustered-w-db.yaml b/brooklyn-docs/guide/yaml/example_yaml/appserver-clustered-w-db.yaml
deleted file mode 100644
index 8bbb14f..0000000
--- a/brooklyn-docs/guide/yaml/example_yaml/appserver-clustered-w-db.yaml
+++ /dev/null
@@ -1,18 +0,0 @@
-name: appserver-clustered-w-db
-services:
-- type: org.apache.brooklyn.entity.webapp.ControlledDynamicWebAppCluster
- initialSize: 2
- memberSpec:
- $brooklyn:entitySpec:
- type: org.apache.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: org.apache.brooklyn.entity.database.mysql.MySqlNode
- id: db
- name: DB HelloWorld Visitors
- brooklyn.config:
- datastore.creation.script.url: https://github.com/apache/incubator-brooklyn/raw/master/usage/launcher/src/test/resources/visitors-creation-script.sql
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/example_yaml/appserver-configured-in-config.yaml
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/yaml/example_yaml/appserver-configured-in-config.yaml b/brooklyn-docs/guide/yaml/example_yaml/appserver-configured-in-config.yaml
deleted file mode 100644
index f817dd7..0000000
--- a/brooklyn-docs/guide/yaml/example_yaml/appserver-configured-in-config.yaml
+++ /dev/null
@@ -1,6 +0,0 @@
-name: appserver-configured-in-config
-services:
-- type: org.apache.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/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/example_yaml/appserver-configured.yaml
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/yaml/example_yaml/appserver-configured.yaml b/brooklyn-docs/guide/yaml/example_yaml/appserver-configured.yaml
deleted file mode 100644
index 58416ca..0000000
--- a/brooklyn-docs/guide/yaml/example_yaml/appserver-configured.yaml
+++ /dev/null
@@ -1,5 +0,0 @@
-name: appserver-configured
-services:
-- type: org.apache.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/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/example_yaml/appserver-w-db-other-flavor.yaml
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/yaml/example_yaml/appserver-w-db-other-flavor.yaml b/brooklyn-docs/guide/yaml/example_yaml/appserver-w-db-other-flavor.yaml
deleted file mode 100644
index ac1106e..0000000
--- a/brooklyn-docs/guide/yaml/example_yaml/appserver-w-db-other-flavor.yaml
+++ /dev/null
@@ -1,17 +0,0 @@
-name: appserver-w-db-other-flavor
-services:
-- type: org.apache.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: org.apache.brooklyn.entity.database.mariadb.MariaDbNode
- id: db
- name: DB HelloWorld Visitors
- brooklyn.config:
- datastore.creation.script.url: https://github.com/apache/incubator-brooklyn/raw/master/usage/launcher/src/test/resources/visitors-creation-script.sql
- provisioning.properties:
- minRam: 8192
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/example_yaml/appserver-w-db.yaml
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/yaml/example_yaml/appserver-w-db.yaml b/brooklyn-docs/guide/yaml/example_yaml/appserver-w-db.yaml
deleted file mode 100644
index 0e9d959..0000000
--- a/brooklyn-docs/guide/yaml/example_yaml/appserver-w-db.yaml
+++ /dev/null
@@ -1,15 +0,0 @@
-name: appserver-w-db
-services:
-- type: org.apache.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: org.apache.brooklyn.entity.database.mysql.MySqlNode
- id: db
- name: DB HelloWorld Visitors
- brooklyn.config:
- datastore.creation.script.url: https://github.com/apache/incubator-brooklyn/raw/master/usage/launcher/src/test/resources/visitors-creation-script.sql
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/example_yaml/appserver-w-policy.yaml
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/yaml/example_yaml/appserver-w-policy.yaml b/brooklyn-docs/guide/yaml/example_yaml/appserver-w-policy.yaml
deleted file mode 100644
index 52bc3b8..0000000
--- a/brooklyn-docs/guide/yaml/example_yaml/appserver-w-policy.yaml
+++ /dev/null
@@ -1,26 +0,0 @@
-name: appserver-w-policy
-services:
-- type: org.apache.brooklyn.entity.webapp.ControlledDynamicWebAppCluster
- initialSize: 1
- memberSpec:
- $brooklyn:entitySpec:
- type: org.apache.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: org.apache.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: org.apache.brooklyn.entity.database.mysql.MySqlNode
- id: db
- name: DB HelloWorld Visitors
- brooklyn.config:
- datastore.creation.script.url: https://github.com/apache/incubator-brooklyn/raw/master/usage/launcher/src/test/resources/visitors-creation-script.sql
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/example_yaml/brooklyn-elasticsearch-catalog.bom
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/yaml/example_yaml/brooklyn-elasticsearch-catalog.bom b/brooklyn-docs/guide/yaml/example_yaml/brooklyn-elasticsearch-catalog.bom
deleted file mode 100644
index bbed240..0000000
--- a/brooklyn-docs/guide/yaml/example_yaml/brooklyn-elasticsearch-catalog.bom
+++ /dev/null
@@ -1,124 +0,0 @@
-brooklyn.catalog:
- id: elasticsearch
- version: 1.0
- iconUrl: https://avatars0.githubusercontent.com/u/6764390?v=3&s=400
- name: Elasticsearch
- license: Apache-2.0
- issues_url: https://github.com/Graeme-Miller/brooklyn-elasticsearch/issues
- item:
- type: brooklyn.entity.group.DynamicCluster
- initialSize: 2
- name: Elasticsearch Cluster
- id: elasticsearch-cluster
- description: A cluster of Elasticsearch nodes
-
- brooklyn.config:
- install.version: 1.7.1
- elasticsearch.http.port: 9220
- elasticsearch.tcp.port: 9330
-
- brooklyn.enrichers:
- - type: org.apache.brooklyn.enricher.stock.Aggregator
- brooklyn.config:
- enricher.sourceSensor: $brooklyn:sensor("url.tcp")
- enricher.targetSensor: $brooklyn:sensor("urls.tcp.list")
- enricher.aggregating.fromMembers: true
- - type: org.apache.brooklyn.enricher.stock.Joiner
- brooklyn.config:
- enricher.sourceSensor: $brooklyn:sensor("urls.tcp.list")
- enricher.targetSensor: $brooklyn:sensor("urls.tcp.string")
- uniqueTag: urls.quoted.string
- - type: org.apache.brooklyn.enricher.stock.Transformer
- brooklyn.config:
- enricher.sourceSensor: $brooklyn:sensor("urls.tcp.string")
- enricher.targetSensor: $brooklyn:sensor("urls.tcp.withBrackets")
- enricher.targetValue: $brooklyn:formatString("[%s]", $brooklyn:attributeWhenReady("urls.tcp.string"))
- - type: org.apache.brooklyn.enricher.stock.Aggregator
- brooklyn.config:
- enricher.sourceSensor: $brooklyn:sensor("url.http")
- enricher.targetSensor: $brooklyn:sensor("urls.http.list")
- enricher.aggregating.fromMembers: true
- - type: org.apache.brooklyn.enricher.stock.Joiner
- brooklyn.config:
- enricher.sourceSensor: $brooklyn:sensor("urls.http.list")
- enricher.targetSensor: $brooklyn:sensor("urls.http.string")
- uniqueTag: urls.http.quoted.string
- - type: org.apache.brooklyn.enricher.stock.Transformer
- brooklyn.config:
- enricher.sourceSensor: $brooklyn:sensor("urls.http.string")
- enricher.targetSensor: $brooklyn:sensor("urls.http.withBrackets")
- enricher.targetValue: $brooklyn:formatString("[%s]", $brooklyn:attributeWhenReady("urls.http.string"))
- - type: org.apache.brooklyn.enricher.stock.Aggregator
- brooklyn.config:
- enricher.sourceSensor: $brooklyn:sensor("host.address")
- enricher.targetSensor: $brooklyn:sensor("host.address.first")
- enricher.aggregating.fromMembers: true
- enricher.transformation:
- $brooklyn:object:
- type: "org.apache.brooklyn.util.collections.CollectionFunctionals$FirstElementFunction"
-
- memberSpec:
- $brooklyn:entitySpec:
- - type: brooklyn.entity.basic.VanillaSoftwareProcess
- name: Elasticsearch Node
-
- provisioning.properties:
- osFamily: ubuntu
- inboundPorts:
- - $brooklyn:config("elasticsearch.http.port")
- - $brooklyn:config("elasticsearch.tcp.port")
-
- install.command: |
- $brooklyn:formatString("
- sudo apt-get update
- sudo apt-get install -y openjdk-7-jdk wget
-
- wget -qO - https://packages.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add -
- echo \"deb http://packages.elastic.co/elasticsearch/1.7/debian stable main\" | sudo tee -a /etc/apt/sources.list.d/elasticsearch-1.7.list
- echo \"deb http://packages.elastic.co/elasticsearch/1.6/debian stable main\" | sudo tee -a /etc/apt/sources.list.d/elasticsearch-1.6.list
- echo \"deb http://packages.elastic.co/elasticsearch/1.5/debian stable main\" | sudo tee -a /etc/apt/sources.list.d/elasticsearch-1.5.list
- echo \"deb http://packages.elastic.co/elasticsearch/1.4/debian stable main\" | sudo tee -a /etc/apt/sources.list.d/elasticsearch-1.4.list
- echo \"deb http://packages.elastic.co/elasticsearch/1.3/debian stable main\" | sudo tee -a /etc/apt/sources.list.d/elasticsearch-1.3.list
- echo \"deb http://packages.elastic.co/elasticsearch/1.2/debian stable main\" | sudo tee -a /etc/apt/sources.list.d/elasticsearch-1.2.list
- echo \"deb http://packages.elastic.co/elasticsearch/1.1/debian stable main\" | sudo tee -a /etc/apt/sources.list.d/elasticsearch-1.1.list
- echo \"deb http://packages.elastic.co/elasticsearch/1.0/debian stable main\" | sudo tee -a /etc/apt/sources.list.d/elasticsearch-1.0.list
- sudo apt-get update && sudo apt-get -y install elasticsearch=%s
- ",
- $brooklyn:config("install.version")
- )
-
- customize.command: |
- $brooklyn:formatString("
- sudo rm -fr sudo tee /etc/elasticsearch/elasticsearch.yml;
- echo discovery.zen.ping.multicast.enabled: false | sudo tee -a /etc/elasticsearch/elasticsearch.yml;
- echo discovery.zen.ping.unicast.enabled: true | sudo tee -a /etc/elasticsearch/elasticsearch.yml;
- echo 'discovery.zen.ping.unicast.hosts: %s' | sudo tee -a /etc/elasticsearch/elasticsearch.yml;
- echo http.port: %s | sudo tee -a /etc/elasticsearch/elasticsearch.yml;
- echo transport.tcp.port: %s | sudo tee -a /etc/elasticsearch/elasticsearch.yml;
- ",
- $brooklyn:component("parent", "").attributeWhenReady("urls.tcp.withBrackets"),
- $brooklyn:config("elasticsearch.http.port"),
- $brooklyn:config("elasticsearch.tcp.port")
- )
-
-
- launch.command: sudo service elasticsearch start
-
- stop.command: sudo service elasticsearch stop
-
- checkRunning.command: |
- $brooklyn:formatString("counter=`wget -T 15 -q -O- %s:%s | grep -c \"status. : 200\"`; if [ $counter -eq 0 ]; then exit 1; fi",
- $brooklyn:attributeWhenReady("host.address"),
- $brooklyn:config("elasticsearch.http.port"))
-
- brooklyn.enrichers:
- - type: org.apache.brooklyn.enricher.stock.Transformer
- brooklyn.config:
- enricher.sourceSensor: $brooklyn:sensor("host.address")
- enricher.targetSensor: $brooklyn:sensor("url.tcp")
- enricher.targetValue: $brooklyn:formatString("%s:%s", $brooklyn:attributeWhenReady("host.address"), $brooklyn:config("elasticsearch.tcp.port"))
- - type: org.apache.brooklyn.enricher.stock.Transformer
- brooklyn.config:
- enricher.sourceSensor: $brooklyn:sensor("host.address")
- enricher.targetSensor: $brooklyn:sensor("url.http")
- enricher.targetValue: $brooklyn:formatString("%s:%s", $brooklyn:attributeWhenReady("host.address"), $brooklyn:config("elasticsearch.http.port"))
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/example_yaml/brooklyn-elk-catalog.bom
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/yaml/example_yaml/brooklyn-elk-catalog.bom b/brooklyn-docs/guide/yaml/example_yaml/brooklyn-elk-catalog.bom
deleted file mode 100644
index 6fc11f4..0000000
--- a/brooklyn-docs/guide/yaml/example_yaml/brooklyn-elk-catalog.bom
+++ /dev/null
@@ -1,35 +0,0 @@
-brooklyn.catalog:
- version: 1.0
- iconUrl: https://avatars0.githubusercontent.com/u/6764390?v=3&s=400
- license: Apache-2.0
- issues_url: https://github.com/Graeme-Miller/brooklyn-elk/issues
- itemType: template
- item:
- type: org.apache.brooklyn.entity.stock.BasicApplication
- name: ELK Stack
- id: ELK-Stack
- description: |
- Simple ELK stack deployment: provisions Elasticsearch, Kibana and Logtash as a child of Apache Tomcat 8
- services:
- - type: elasticsearch
- id: es
- name: Elasticsearch Cluster
- brooklyn.config:
- install.version: 1.4.4
- - type: kibana-standalone
- id: kibana
- name: Kibana Server
- customize.latch: $brooklyn:component("es").attributeWhenReady("service.isUp")
- brooklyn.config:
- kibana.elasticsearch.ip: $brooklyn:component("es").attributeWhenReady("host.address.first")
- kibana.elasticsearch.port: $brooklyn:component("es").config("elasticsearch.http.port")
- - type: org.apache.brooklyn.entity.webapp.tomcat.Tomcat8Server
- id: tomcat
- customize.latch: $brooklyn:component("es").attributeWhenReady("service.isUp")
- brooklyn.config:
- children.startable.mode: background_late
- brooklyn.children:
- - type: logstash-child
- name: Logstash Child
- brooklyn.config:
- logstash.elasticsearch.host: $brooklyn:component("es").attributeWhenReady("urls.http.withBrackets")
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/example_yaml/brooklyn-kibana-catalog.bom
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/yaml/example_yaml/brooklyn-kibana-catalog.bom b/brooklyn-docs/guide/yaml/example_yaml/brooklyn-kibana-catalog.bom
deleted file mode 100644
index ee006d2..0000000
--- a/brooklyn-docs/guide/yaml/example_yaml/brooklyn-kibana-catalog.bom
+++ /dev/null
@@ -1,52 +0,0 @@
-brooklyn.catalog:
- version: 0.0.2
- iconUrl: http://blog.arungupta.me/wp-content/uploads/2015/07/kibana-logo.png
- items:
- - id: kibana-standalone
- name: "Kibana server"
- description: "Single Kibana server"
- description: |
- Kibana server. Callers should configure 'kibana.elasticsearch.ip'
- item:
- type: org.apache.brooklyn.entity.software.base.VanillaSoftwareProcess
- provisioning.properties:
- osFamily: ubuntu
-
- brooklyn.config:
- install.version: "4.1.1"
- kibana.elasticsearch.ip: 127.0.0.1 # must be supplied by caller!
- kibana.elasticsearch.port: 9200 # must be supplied by caller!
- kibana.port: 5601
-
- shell.env:
- KIBANA_VERSION: $brooklyn:config("install.version")
- ELASTICSEARCH_IP: $brooklyn:config("kibana.elasticsearch.ip")
- ELASTICSEARCH_PORT: $brooklyn:config("kibana.elasticsearch.port")
- KIBANA_PORT: $brooklyn:config("kibana.port")
-
- install.command: |
- # Install required dependencies
- sudo apt-get update
- sudo DEBIAN_FRONTEND=noninteractive apt-get install -y --allow-unauthenticated tzdata openjdk-7-jdk wget
-
- # download kibana
- sudo mkdir -p /opt/kibana/
- cd /opt/kibana
- sudo chmod -R 777 /opt/kibana
- wget -qO - https://download.elastic.co/kibana/kibana/kibana-${KIBANA_VERSION}-linux-x64.tar.gz | tar xz
-
- # customize config file for kibana
- sed -i 's|http://localhost:9200|http://'"${ELASTICSEARCH_IP}"':'"${ELASTICSEARCH_PORT}"'|g' /opt/kibana/kibana-${KIBANA_VERSION}-linux-x64/config/kibana.yml
- sed -i 's|5601|'"${KIBANA_PORT}"'|g' /opt/kibana/kibana-${KIBANA_VERSION}-linux-x64/config/kibana.yml
- sed -i 's|# log_file: ./kibana.log|log_file: ./kibana.log|g' /opt/kibana/kibana-${KIBANA_VERSION}-linux-x64/config/kibana.yml
-
- launch.command: |
- nohup /opt/kibana/kibana-${KIBANA_VERSION}-linux-x64/bin/kibana &
- echo $! > $PID_FILE
-
- brooklyn.enrichers:
- - type: org.apache.brooklyn.enricher.stock.Transformer
- brooklyn.config:
- enricher.sourceSensor: $brooklyn:sensor("host.address")
- enricher.targetSensor: $brooklyn:sensor("main.uri")
- enricher.targetValue: $brooklyn:formatString("http://%s:%s", $brooklyn:attributeWhenReady("host.address"), $brooklyn:config("kibana.port"))
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/example_yaml/brooklyn-logstash-catalog.bom
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/yaml/example_yaml/brooklyn-logstash-catalog.bom b/brooklyn-docs/guide/yaml/example_yaml/brooklyn-logstash-catalog.bom
deleted file mode 100644
index 7c431f5..0000000
--- a/brooklyn-docs/guide/yaml/example_yaml/brooklyn-logstash-catalog.bom
+++ /dev/null
@@ -1,59 +0,0 @@
-brooklyn.catalog:
- version: 1.5.5
- iconUrl: http://logstash.net/images/logstash.png
- items:
- - id: logstash-standalone
- name: "Logstash server"
- description: "Single Logstash server"
- item:
- type: org.apache.brooklyn.entity.software.base.VanillaSoftwareProcess
- provisioning.properties:
- osFamily: ubuntu
-
- brooklyn.config:
- install.version: "1.5.4"
- logstash.config.input: input { file { path => "/var/log/*" } }
- logstash.config.filter: ''
- logstash.config.output: output { stdout { } }
- logstash.config.dir: /etc/logstash/conf.d/
-
- shell.env:
- VERSION: $brooklyn:config("install.version")
- INPUT_CONFIG: $brooklyn:config("logstash.config.input")
- FILTER_CONFIG: $brooklyn:config("logstash.config.filter")
- OUTPUT_CONFIG: $brooklyn:config("logstash.config.output")
- CONFIG_DIR: $brooklyn:config("logstash.config.dir")
-
- install.command: |
- # Install required dependencies
- sudo apt-get update
- sudo DEBIAN_FRONTEND=noninteractive apt-get install -y --allow-unauthenticated tzdata openjdk-7-jdk wget
-
- # download logstash
- sudo mkdir -p /opt/logstash/
- cd /opt/logstash
- sudo chmod -R 777 /opt/logstash
- wget -qO - https://download.elastic.co/logstash/logstash/logstash-${VERSION}.tar.gz | tar xz
-
- # add a config file for logstash
- sudo mkdir -p ${CONFIG_DIR}
- echo "${INPUT_CONFIG} ${FILTER_CONFIG} ${OUTPUT_CONFIG}" | sudo tee ${CONFIG_DIR}/01-basic.conf
-
- launch.command: |
- sudo mkdir -p /var/log/logstash/
- sudo chmod -R 777 /var/log/logstash/
- nohup /opt/logstash/logstash-${VERSION}/bin/logstash agent -f ${CONFIG_DIR} -l /var/log/logstash/logstash.log &
- echo $! > $PID_FILE
- - id: logstash-child
- name: "Logstash Child"
- description: |
- Logstash server to be embedded as a child of a SoftwareProcess who
- publishes his 'log.location' as a sensor.
- Callers should configure 'logstash.elasticsearch.host' (if using ES)
- or 'logstash.config.output'.
- item:
- type: logstash-standalone
- brooklyn.config:
- logstash.config.input: $brooklyn:formatString("input { file { path => \"%s\" start_position => \"beginning\" } }", $brooklyn:parent().attributeWhenReady("log.location"))
- logstash.elasticsearch.host: 127.0.0.1:9200 # must be supplied by caller!
- logstash.config.output: $brooklyn:formatString("output { elasticsearch { host => %s protocol => \"http\" embedded => false } }", $brooklyn:config("logstash.elasticsearch.host"))
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/example_yaml/cluster-vm.yaml
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/yaml/example_yaml/cluster-vm.yaml b/brooklyn-docs/guide/yaml/example_yaml/cluster-vm.yaml
deleted file mode 100644
index 2b57f4e..0000000
--- a/brooklyn-docs/guide/yaml/example_yaml/cluster-vm.yaml
+++ /dev/null
@@ -1,12 +0,0 @@
-name: cluster-vm
-services:
-- type: org.apache.brooklyn.entity.group.DynamicCluster
- initialSize: 5
- memberSpec:
- $brooklyn:entitySpec:
- type: org.apache.brooklyn.entity.software.base.EmptySoftwareProcess
- name: VM
- provisioning.properties:
- minRam: 8g
- minCores: 4
- minDisk: 100g
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/example_yaml/simple-appserver-with-location-byon.yaml
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/yaml/example_yaml/simple-appserver-with-location-byon.yaml b/brooklyn-docs/guide/yaml/example_yaml/simple-appserver-with-location-byon.yaml
deleted file mode 100644
index 8e9c951..0000000
--- a/brooklyn-docs/guide/yaml/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: org.apache.brooklyn.entity.webapp.jboss.JBoss7Server
- location:
- byon:(hosts="127.0.0.1")
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/example_yaml/simple-appserver-with-location.yaml
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/yaml/example_yaml/simple-appserver-with-location.yaml b/brooklyn-docs/guide/yaml/example_yaml/simple-appserver-with-location.yaml
deleted file mode 100644
index 79344c8..0000000
--- a/brooklyn-docs/guide/yaml/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: org.apache.brooklyn.entity.webapp.jboss.JBoss7Server
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/example_yaml/simple-appserver.yaml
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/yaml/example_yaml/simple-appserver.yaml b/brooklyn-docs/guide/yaml/example_yaml/simple-appserver.yaml
deleted file mode 100644
index 8e9d76a..0000000
--- a/brooklyn-docs/guide/yaml/example_yaml/simple-appserver.yaml
+++ /dev/null
@@ -1,4 +0,0 @@
-name: simple-appserver
-location: localhost
-services:
-- type: org.apache.brooklyn.entity.webapp.jboss.JBoss7Server
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/example_yaml/simple-vm.yaml
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/yaml/example_yaml/simple-vm.yaml b/brooklyn-docs/guide/yaml/example_yaml/simple-vm.yaml
deleted file mode 100644
index 8f6447c..0000000
--- a/brooklyn-docs/guide/yaml/example_yaml/simple-vm.yaml
+++ /dev/null
@@ -1,8 +0,0 @@
-name: simple-vm
-services:
-- type: org.apache.brooklyn.entity.software.base.EmptySoftwareProcess
- name: VM
- provisioning.properties:
- minRam: 8192mb
- minCores: 4
- minDisk: 100gb
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/example_yaml/test-app-with-enrichers-slightly-simpler.yaml
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/yaml/example_yaml/test-app-with-enrichers-slightly-simpler.yaml b/brooklyn-docs/guide/yaml/example_yaml/test-app-with-enrichers-slightly-simpler.yaml
deleted file mode 100644
index 55d5b87..0000000
--- a/brooklyn-docs/guide/yaml/example_yaml/test-app-with-enrichers-slightly-simpler.yaml
+++ /dev/null
@@ -1,57 +0,0 @@
-#
-# example showing how enrichers can be set
-#
-name: test-app-with-enrichers
-description: Testing many enrichers
-services:
-- type: org.apache.brooklyn.entity.group.DynamicCluster
- id: cluster
- initialSize: 3
- location: localhost
- memberSpec:
- $brooklyn:entitySpec:
- type: org.apache.brooklyn.core.test.entity.TestEntity
- brooklyn.enrichers:
- - type: org.apache.brooklyn.enricher.stock.Transformer
- # transform "ip" (which we expect a feed, not shown here, to set) to a URL;
- # you can curl an address string to the sensors/ip endpoint an entity to trigger these enrichers
- brooklyn.config:
- enricher.sourceSensor: $brooklyn:sensor("ip")
- enricher.targetSensor: $brooklyn:sensor("url")
- enricher.targetValue: $brooklyn:formatString("http://%s/", $brooklyn:attributeWhenReady("ip"))
- - type: org.apache.brooklyn.enricher.stock.Propagator
- # use propagator to duplicate one sensor as another, giving the supplied sensor mapping;
- # the other use of Propagator is where you specify a producer (using $brooklyn:entity(...) as below)
- # from which to take sensors; in that mode you can specify `propagate` as a list of sensors whose names are unchanged,
- # instead of (or in addition to) this map
- brooklyn.config:
- sensorMapping:
- $brooklyn:sensor("url"): $brooklyn:sensor("org.apache.brooklyn.core.entity.Attributes", "main.uri")
- brooklyn.enrichers:
- - type: org.apache.brooklyn.enricher.stock.Aggregator
- # aggregate `url` sensors from children into a list
- brooklyn.config:
- enricher.sourceSensor: $brooklyn:sensor("url")
- enricher.targetSensor: $brooklyn:sensor("urls.list")
- enricher.aggregating.fromMembers: true
- - type: org.apache.brooklyn.enricher.stock.Joiner
- # create a string from that list, for use e.g. in bash scripts
- brooklyn.config:
- enricher.sourceSensor: $brooklyn:sensor("urls.list")
- enricher.targetSensor: $brooklyn:sensor("urls.list.comma_separated.max_2")
- maximum: 2
- # TODO infer uniqueTag, name etc
- uniqueTag: urls.list.comma_separated.max_2
- - type: org.apache.brooklyn.enricher.stock.Joiner
- # pick one uri as the main one to use
- brooklyn.config:
- enricher.sourceSensor: $brooklyn:sensor("urls.list")
- enricher.targetSensor: $brooklyn:sensor("org.apache.brooklyn.core.entity.Attributes", "main.uri")
- quote: false
- maximum: 1
-brooklyn.enrichers:
-- type: org.apache.brooklyn.enricher.stock.Propagator
- # if nothing specified for `propagating` or `sensorMapping` then
- # Propagator will do all but the usual lifecycle defaults, handy at the root!
- brooklyn.config:
- producer: $brooklyn:entity("cluster")
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/example_yaml/vanilla-bash-netcat-catalog.bom
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/yaml/example_yaml/vanilla-bash-netcat-catalog.bom b/brooklyn-docs/guide/yaml/example_yaml/vanilla-bash-netcat-catalog.bom
deleted file mode 100644
index 7551818..0000000
--- a/brooklyn-docs/guide/yaml/example_yaml/vanilla-bash-netcat-catalog.bom
+++ /dev/null
@@ -1,35 +0,0 @@
-brooklyn.catalog:
- id: netcat-example
- version: "1.0"
- item:
- type: org.apache.brooklyn.entity.software.base.VanillaSoftwareProcess
- name: Simple Netcat Server
-
- launch.command: |
- echo $MESSAGE | nc -l $NETCAT_PORT &
- echo $! > $PID_FILE
-
- env:
- MESSAGE: $brooklyn:config("message")
- NETCAT_PORT: $brooklyn:attributeWhenReady("netcat.port")
-
- brooklyn.parameters:
- - name: message
- description: a message to send to the caller
- default: hello
- - name: netcat.port
- type: port
- description: the port netcat should run on
- default: 4321+
-
- brooklyn.enrichers:
- - type: org.apache.brooklyn.enricher.stock.Transformer
- brooklyn.config:
- uniqueTag: main-uri-generator
- enricher.sourceSensor: $brooklyn:sensor("host.address")
- enricher.targetSensor: $brooklyn:sensor("main.uri")
- enricher.targetValue:
- $brooklyn:formatString:
- - "http://%s:%s/"
- - $brooklyn:attributeWhenReady("host.address")
- - $brooklyn:attributeWhenReady("netcat.port")
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/example_yaml/vanilla-bash-netcat-cluster.yaml
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/yaml/example_yaml/vanilla-bash-netcat-cluster.yaml b/brooklyn-docs/guide/yaml/example_yaml/vanilla-bash-netcat-cluster.yaml
deleted file mode 100644
index 70b69af..0000000
--- a/brooklyn-docs/guide/yaml/example_yaml/vanilla-bash-netcat-cluster.yaml
+++ /dev/null
@@ -1,11 +0,0 @@
-name: Netcat Cluster Example
-location: localhost
-services:
-- type: org.apache.brooklyn.entity.group.DynamicCluster
- memberSpec:
- $brooklyn:entitySpec:
- type: netcat-example
- message: hello from cluster member
- netcat.port: 8000+
- initialSize: 3
- restartMode: parallel
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/example_yaml/vanilla-bash-netcat-file.yaml
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/yaml/example_yaml/vanilla-bash-netcat-file.yaml b/brooklyn-docs/guide/yaml/example_yaml/vanilla-bash-netcat-file.yaml
deleted file mode 100644
index d768739..0000000
--- a/brooklyn-docs/guide/yaml/example_yaml/vanilla-bash-netcat-file.yaml
+++ /dev/null
@@ -1,6 +0,0 @@
-name: Simple Netcat Example From File
-location: localhost
-services:
-- type: org.apache.brooklyn.entity.software.base.VanillaSoftwareProcess
- name: Simple Netcat Server
- download.url: file:///tmp/netcat-server.tgz
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/example_yaml/vanilla-bash-netcat-more-commands.yaml
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/yaml/example_yaml/vanilla-bash-netcat-more-commands.yaml b/brooklyn-docs/guide/yaml/example_yaml/vanilla-bash-netcat-more-commands.yaml
deleted file mode 100644
index f4e894f..0000000
--- a/brooklyn-docs/guide/yaml/example_yaml/vanilla-bash-netcat-more-commands.yaml
+++ /dev/null
@@ -1,16 +0,0 @@
-name: Netcat Example with Explicit Check and Stop Commands
-location: localhost
-services:
-- type: org.apache.brooklyn.entity.software.base.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; }
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/example_yaml/vanilla-bash-netcat-port-parameter.yaml
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/yaml/example_yaml/vanilla-bash-netcat-port-parameter.yaml b/brooklyn-docs/guide/yaml/example_yaml/vanilla-bash-netcat-port-parameter.yaml
deleted file mode 100644
index 90f83b4..0000000
--- a/brooklyn-docs/guide/yaml/example_yaml/vanilla-bash-netcat-port-parameter.yaml
+++ /dev/null
@@ -1,21 +0,0 @@
-name: Netcat Example with Parameter
-location: localhost
-services:
-- type: org.apache.brooklyn.entity.software.base.VanillaSoftwareProcess
- name: Simple Netcat Server
- launch.command: |
- echo $MESSAGE | nc -l $NETCAT_PORT &
- echo $! > $PID_FILE
-
- env:
- MESSAGE: $brooklyn:config("message")
- NETCAT_PORT: $brooklyn:attributeWhenReady("netcat.port")
-
- brooklyn.parameters:
- - name: message
- description: a message to send to the caller
- default: hello
- - name: netcat.port
- type: port
- description: the port netcat should run on
- default: 4321+
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/example_yaml/vanilla-bash-netcat-port.yaml
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/yaml/example_yaml/vanilla-bash-netcat-port.yaml b/brooklyn-docs/guide/yaml/example_yaml/vanilla-bash-netcat-port.yaml
deleted file mode 100644
index 3ec0212..0000000
--- a/brooklyn-docs/guide/yaml/example_yaml/vanilla-bash-netcat-port.yaml
+++ /dev/null
@@ -1,13 +0,0 @@
-name: Netcat Example with Port Opened
-location: localhost
-services:
-- type: org.apache.brooklyn.entity.software.base.VanillaSoftwareProcess
- name: Simple Netcat Server
- launch.command: |
- echo hello | nc -l 4321 &
- echo $! > $PID_FILE
-
- brooklyn.config:
- # matching the regex `.*\.port` will cause the port to be opened
- # if in a cloud where configurable security groups are available
- netcat.port: 4321
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/example_yaml/vanilla-bash-netcat-reference.yaml
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/yaml/example_yaml/vanilla-bash-netcat-reference.yaml b/brooklyn-docs/guide/yaml/example_yaml/vanilla-bash-netcat-reference.yaml
deleted file mode 100644
index 0f10c55..0000000
--- a/brooklyn-docs/guide/yaml/example_yaml/vanilla-bash-netcat-reference.yaml
+++ /dev/null
@@ -1,5 +0,0 @@
-name: Netcat Type Reference Example
-location: localhost
-services:
-- type: netcat-example
- message: hello from netcat using a registered type
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/example_yaml/vanilla-bash-netcat-restarter.yaml
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/yaml/example_yaml/vanilla-bash-netcat-restarter.yaml b/brooklyn-docs/guide/yaml/example_yaml/vanilla-bash-netcat-restarter.yaml
deleted file mode 100644
index 47e54ab..0000000
--- a/brooklyn-docs/guide/yaml/example_yaml/vanilla-bash-netcat-restarter.yaml
+++ /dev/null
@@ -1,20 +0,0 @@
-name: Netcat Example with Restarter Policy
-location: localhost
-services:
-- type: org.apache.brooklyn.entity.software.base.VanillaSoftwareProcess
- id: netcat-server
- name: Simple Netcat Server
- launch.command: |
- echo hello | nc -l 4321 &
- echo $! > $PID_FILE
- brooklyn.enrichers:
- - type: org.apache.brooklyn.policy.ha.ServiceFailureDetector
- brooklyn.config:
- # wait 15s after service fails before propagating failure
- serviceFailedStabilizationDelay: 15s
- brooklyn.policies:
- - type: org.apache.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