You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@brooklyn.apache.org by tb...@apache.org on 2018/02/16 10:26:52 UTC
[13/25] brooklyn-docs git commit: Delete all the guide files
Delete all the guide files
Project: http://git-wip-us.apache.org/repos/asf/brooklyn-docs/repo
Commit: http://git-wip-us.apache.org/repos/asf/brooklyn-docs/commit/58bb3aa0
Tree: http://git-wip-us.apache.org/repos/asf/brooklyn-docs/tree/58bb3aa0
Diff: http://git-wip-us.apache.org/repos/asf/brooklyn-docs/diff/58bb3aa0
Branch: refs/heads/website
Commit: 58bb3aa0ef28e2261230b4c724b050c938f3130d
Parents: e1d08e5
Author: Richard Downer <ri...@apache.org>
Authored: Wed Oct 11 15:09:30 2017 +0100
Committer: Richard Downer <ri...@apache.org>
Committed: Tue Oct 17 13:25:56 2017 +0100
----------------------------------------------------------------------
guide/blueprints/advanced-example.md | 285 ---------
guide/blueprints/ansible/about-ansible.md | 34 --
.../ansible/creating-ansible-blueprints.md | 213 -------
guide/blueprints/ansible/index.md | 16 -
guide/blueprints/blueprinting-tips.md | 183 ------
guide/blueprints/catalog/bundle.md | 145 -----
guide/blueprints/catalog/cli.md | 31 -
.../catalog/images/add-to-catalog.png | Bin 4919 -> 0 bytes
guide/blueprints/catalog/index.md | 21 -
guide/blueprints/catalog/management.md | 58 --
.../catalog/mysql-in-catalog-w700.png | Bin 92767 -> 0 bytes
guide/blueprints/catalog/mysql-in-catalog.png | Bin 168831 -> 0 bytes
guide/blueprints/catalog/schema.md | 272 ---------
guide/blueprints/catalog/templates.md | 14 -
guide/blueprints/catalog/versioning.md | 146 -----
guide/blueprints/chef/about-chef.md | 50 --
.../chef/advanced-chef-integration.md | 49 --
guide/blueprints/chef/chef-call-flow.png | Bin 36222 -> 0 bytes
guide/blueprints/chef/creating-blueprints.md | 105 ----
.../chef/example_yaml/mysql-chef-1.yaml | 25 -
.../chef/example_yaml/mysql-chef-2.yaml | 27 -
guide/blueprints/chef/index.md | 18 -
guide/blueprints/chef/writing-chef.md | 79 ---
guide/blueprints/clusters-and-policies.md | 46 --
guide/blueprints/clusters.md | 34 --
guide/blueprints/config-files.md | 102 ----
guide/blueprints/configuring-vms.md | 31 -
guide/blueprints/creating-yaml.md | 78 ---
guide/blueprints/custom-entities.md | 343 -----------
guide/blueprints/effectors.md | 185 ------
guide/blueprints/enrichers.md | 145 -----
guide/blueprints/entity-configuration.md | 548 -----------------
.../appserver-clustered-w-db-concise.yaml | 15 -
.../example_yaml/appserver-clustered-w-db.yaml | 26 -
.../example_yaml/appserver-configured.yaml | 6 -
.../appserver-w-db-other-flavor.yaml | 23 -
.../blueprints/example_yaml/appserver-w-db.yaml | 21 -
.../example_yaml/appserver-w-policy.yaml | 33 --
.../brooklyn-elasticsearch-catalog.bom | 125 ----
.../example_yaml/brooklyn-elk-catalog.bom | 94 ---
.../example_yaml/brooklyn-kibana-catalog.bom | 58 --
.../example_yaml/brooklyn-logstash-catalog.bom | 66 ---
guide/blueprints/example_yaml/cluster-vm.yaml | 13 -
.../example_yaml/enricher-aggregator.yaml | 7 -
.../example_yaml/enricher-joiner.yaml | 6 -
.../example_yaml/enricher-propagator.yaml | 8 -
.../enricher-time-weighted-delta.yaml | 6 -
.../example_yaml/enricher-transformer.yaml | 6 -
.../fabric-with-multiple-locations.yaml | 15 -
.../simple-appserver-with-location-byon.yaml | 10 -
...mple-appserver-with-location-per-entity.yaml | 8 -
.../simple-appserver-with-location.yaml | 8 -
.../example_yaml/simple-appserver.yaml | 4 -
guide/blueprints/example_yaml/simple-vm.yaml | 9 -
...est-app-with-enrichers-slightly-simpler.yaml | 58 --
.../vanilla-bash-netcat-catalog.bom | 37 --
.../vanilla-bash-netcat-cluster.yaml | 12 -
.../example_yaml/vanilla-bash-netcat-env.yaml | 14 -
.../example_yaml/vanilla-bash-netcat-file.yaml | 10 -
.../vanilla-bash-netcat-more-commands.yaml | 21 -
.../vanilla-bash-netcat-port-parameter.yaml | 22 -
.../example_yaml/vanilla-bash-netcat-port.yaml | 14 -
.../vanilla-bash-netcat-reference.yaml | 5 -
.../vanilla-bash-netcat-restarter.yaml | 21 -
.../vanilla-bash-netcat-w-client.yaml | 80 ---
.../example_yaml/vanilla-bash-netcat.yaml | 9 -
guide/blueprints/index.md | 29 -
guide/blueprints/java/archetype.md | 114 ----
guide/blueprints/java/bundle-dependencies.md | 135 -----
guide/blueprints/java/common-usage.md | 209 -------
guide/blueprints/java/defining-and-deploying.md | 177 ------
guide/blueprints/java/entities.md | 223 -------
guide/blueprints/java/entitlements.md | 42 --
guide/blueprints/java/entity.md | 104 ----
guide/blueprints/java/feeds.md | 233 --------
.../java/gist_generator/GistGenerator.java | 29 -
.../java/gist_generator/GistGeneratorImpl.java | 47 --
.../java/gist_generator/GistGeneratorTest.java | 20 -
.../gist_generator/GistGeneratorYamlTest.java | 39 --
.../java/gist_generator/gist_create_token.png | Bin 390046 -> 0 bytes
.../java/gist_generator/gist_generator.bom | 14 -
.../java/gist_generator/gist_grant_access.png | Bin 411974 -> 0 bytes
guide/blueprints/java/index.md | 36 --
.../blueprints/java/java_app/ExampleWebApp.java | 62 --
guide/blueprints/java/service-state.md | 73 ---
guide/blueprints/java/topology-dependencies.md | 53 --
.../java/wt-deployed-application-700.png | Bin 176494 -> 0 bytes
.../blueprints/java/wt-deployed-application.png | Bin 127347 -> 0 bytes
guide/blueprints/java/wt-starting-700.png | Bin 303892 -> 0 bytes
guide/blueprints/java/wt-starting.png | Bin 332710 -> 0 bytes
.../java/wt-tree-jboss-sensors-700.png | Bin 268853 -> 0 bytes
guide/blueprints/java/wt-tree-jboss-sensors.png | Bin 169929 -> 0 bytes
guide/blueprints/logstash-snapshot.png | Bin 80486 -> 0 bytes
guide/blueprints/multiple-services.md | 91 ---
guide/blueprints/policies.md | 265 ---------
guide/blueprints/salt/about-salt.md | 38 --
.../blueprints/salt/creating-salt-blueprints.md | 163 -----
guide/blueprints/salt/index.md | 16 -
guide/blueprints/setting-locations.md | 132 -----
...infrastructuredeploymenttestcase-entity.yaml | 11 -
.../entities/loopovergroupmembers-entity.yaml | 7 -
.../entities/paralleltestcase-entity.yaml | 6 -
.../test/example_yaml/entities/script1.sh | 2 -
.../example_yaml/entities/testcase-entity.yaml | 6 -
.../entities/testeffector-entity.yaml | 9 -
.../entities/testhttpcall-entity.yaml | 8 -
.../entities/testsensor-entity.yaml | 8 -
.../entities/testsshcommand-entity.yaml | 30 -
.../testcases/effector-test-snippet.yaml | 31 -
.../testcases/getting-started-test-example.yaml | 77 ---
.../testcases/http-test-snippet.yaml | 22 -
.../testcases/sensor-test-snippet.yaml | 8 -
.../getting-started-blueprint-test-large.png | Bin 156553 -> 0 bytes
.../images/getting-started-blueprint-test.png | Bin 84906 -> 0 bytes
guide/blueprints/test/index.md | 33 --
guide/blueprints/test/test-entities.md | 198 -------
guide/blueprints/test/usage-examples.md | 58 --
guide/blueprints/web-console-yaml-700.png | Bin 138229 -> 0 bytes
guide/blueprints/web-console-yaml.png | Bin 661136 -> 0 bytes
guide/blueprints/winrm/client.md | 125 ----
guide/blueprints/winrm/index.md | 589 -------------------
guide/blueprints/yaml-reference.md | 253 --------
guide/concepts/application-parent-membership.md | 25 -
...ooklyn-flow-websequencediagrams.com-w400.png | Bin 58518 -> 0 bytes
.../brooklyn-flow-websequencediagrams.com.png | Bin 106928 -> 0 bytes
.../concepts/configuration-sensor-effectors.md | 40 --
guide/concepts/dependent-configuration.md | 34 --
guide/concepts/entities.md | 23 -
guide/concepts/execution.md | 34 --
guide/concepts/index.md | 22 -
guide/concepts/lifecycle-managementcontext.md | 44 --
guide/concepts/location.md | 22 -
guide/concepts/policies.md | 11 -
guide/concepts/stop-start-restart-behaviour.md | 65 --
guide/dev/code/licensing.md | 122 ----
guide/dev/code/structure.md | 59 --
guide/dev/code/tests.md | 31 -
guide/dev/env/ide/eclipse.include.md | 6 -
guide/dev/env/ide/index.md | 108 ----
guide/dev/env/maven-build.md | 191 ------
guide/dev/index.md | 42 --
guide/dev/tips/debugging-remote-brooklyn.md | 138 -----
guide/dev/tips/index.md | 70 ---
guide/dev/tips/logging.md | 165 ------
guide/glossary.json | 22 -
guide/index.md | 21 -
guide/locations/_AWS.md | 141 -----
guide/locations/_GCE.md | 89 ---
guide/locations/_azure-ARM.md | 266 ---------
guide/locations/_azure-classic.md | 233 --------
guide/locations/_byon.md | 77 ---
guide/locations/_clouds.md | 305 ----------
guide/locations/_cloudstack.md | 143 -----
guide/locations/_ibm-softlayer.md | 135 -----
.../_inheritance-and-named-locations.md | 80 ---
guide/locations/_localhost.md | 48 --
.../_location-customizer-security-groups.md | 55 --
guide/locations/_location-customizers.md | 178 ------
guide/locations/_openstack.md | 269 ---------
guide/locations/_special-locations.md | 117 ----
guide/locations/_ssh-keys.md | 88 ---
guide/locations/cloud-credentials.md | 6 -
guide/locations/index.md | 21 -
.../provisioned-machine-requirements.md | 161 -----
guide/misc/download.md | 172 ------
guide/misc/index.md | 20 -
guide/misc/javadoc/index.md | 11 -
guide/misc/known-issues.md | 27 -
guide/misc/release-notes.md | 24 -
guide/ops/cli/cli-ref-guide.md | 322 ----------
guide/ops/cli/cli-usage-guide.md | 486 ---------------
guide/ops/cli/index.md | 41 --
guide/ops/configuration/brooklyn_cfg.md | 203 -------
guide/ops/configuration/cors.md | 45 --
guide/ops/configuration/https.md | 63 --
guide/ops/configuration/index.md | 143 -----
guide/ops/externalized-configuration.md | 270 ---------
guide/ops/gui/_my-web-cluster.yaml | 24 -
guide/ops/gui/_my-web-cluster2.yaml | 32 -
guide/ops/gui/blueprints.md | 68 ---
...cation-catalog-web-cluster-with-db-large.png | Bin 165148 -> 0 bytes
...talog-web-cluster-with-db-location-large.png | Bin 152721 -> 0 bytes
...ion-catalog-web-cluster-with-db-location.png | Bin 86425 -> 0 bytes
...-application-catalog-web-cluster-with-db.png | Bin 70109 -> 0 bytes
.../images/add-application-modal-yaml-large.png | Bin 124297 -> 0 bytes
.../gui/images/add-application-modal-yaml.png | Bin 55183 -> 0 bytes
.../ops/gui/images/home-app-starting-large.png | Bin 490707 -> 0 bytes
guide/ops/gui/images/home-app-starting.png | Bin 188754 -> 0 bytes
.../gui/images/my-db-activities-step1-large.png | Bin 99671 -> 0 bytes
guide/ops/gui/images/my-db-activities-step1.png | Bin 57813 -> 0 bytes
.../gui/images/my-db-activities-step2-large.png | Bin 176900 -> 0 bytes
guide/ops/gui/images/my-db-activities-step2.png | Bin 97061 -> 0 bytes
.../gui/images/my-db-activities-step3-large.png | Bin 162986 -> 0 bytes
guide/ops/gui/images/my-db-activities-step3.png | Bin 84365 -> 0 bytes
.../ops/gui/images/my-web-cluster-starting.png | Bin 32948 -> 0 bytes
.../my-web-cluster-stop-confirm-large.png | Bin 148155 -> 0 bytes
.../gui/images/my-web-cluster-stop-confirm.png | Bin 79280 -> 0 bytes
guide/ops/gui/images/my-web-large.png | Bin 104519 -> 0 bytes
guide/ops/gui/images/my-web-summary-large.png | Bin 178785 -> 0 bytes
guide/ops/gui/images/my-web-summary.png | Bin 80583 -> 0 bytes
.../my-web-validating-app-endpoint-large.png | Bin 123007 -> 0 bytes
.../images/my-web-validating-app-endpoint.png | Bin 68969 -> 0 bytes
guide/ops/gui/images/my-web.png | Bin 58849 -> 0 bytes
guide/ops/gui/index.md | 11 -
guide/ops/gui/managing.md | 70 ---
guide/ops/gui/policies.md | 49 --
guide/ops/gui/running.md | 54 --
.../high-availability-supplemental.md | 168 ------
guide/ops/high-availability/index.md | 53 --
guide/ops/index.md | 23 -
guide/ops/logging.md | 80 ---
guide/ops/paths.md | 49 --
guide/ops/persistence/index.md | 269 ---------
guide/ops/production-installation.md | 107 ----
guide/ops/requirements.md | 117 ----
guide/ops/rest.md | 89 ---
guide/ops/security-guidelines.md | 103 ----
guide/ops/server-cli-reference.md | 201 -------
guide/ops/starting-stopping-monitoring.md | 77 ---
guide/ops/troubleshooting/_connectivity.md | 152 -----
guide/ops/troubleshooting/connectivity.md | 7 -
guide/ops/troubleshooting/deployment.md | 193 ------
.../troubleshooting/detailed-support-report.md | 43 --
.../going-deep-in-java-and-logs.md | 484 ---------------
.../images/external-error-large.png | Bin 131907 -> 0 bytes
.../troubleshooting/images/external-error.png | Bin 71972 -> 0 bytes
.../images/failed-task-large.png | Bin 169079 -> 0 bytes
.../ops/troubleshooting/images/failed-task.png | Bin 92530 -> 0 bytes
.../images/jmx-sensors-all-large.png | Bin 133517 -> 0 bytes
.../troubleshooting/images/jmx-sensors-all.png | Bin 76581 -> 0 bytes
.../images/jmx-sensors-large.png | Bin 197177 -> 0 bytes
.../ops/troubleshooting/images/jmx-sensors.png | Bin 109139 -> 0 bytes
.../images/resource-exception-large.png | Bin 134842 -> 0 bytes
.../images/resource-exception.png | Bin 76059 -> 0 bytes
.../images/script-failure-large.png | Bin 130227 -> 0 bytes
.../troubleshooting/images/script-failure.png | Bin 71912 -> 0 bytes
guide/ops/troubleshooting/increase-entropy.md | 81 ---
.../increase-system-resource-limits.md | 39 --
guide/ops/troubleshooting/index.md | 18 -
guide/ops/troubleshooting/memory-usage.md | 138 -----
guide/ops/troubleshooting/overview.md | 116 ----
guide/ops/troubleshooting/slow-unresponsive.md | 240 --------
guide/ops/troubleshooting/softwareprocess.md | 51 --
guide/ops/troubleshooting/web-console-issues.md | 23 -
guide/ops/upgrade.md | 355 -----------
guide/start/_my-web-cluster.yaml | 24 -
guide/start/_my-web-cluster2.yaml | 32 -
guide/start/blueprints.md | 133 -----
guide/start/brooklyn.properties | 347 -----------
guide/start/concept-quickstart.md | 33 --
guide/start/example_yaml/mycluster.yaml | 59 --
...cation-catalog-web-cluster-with-db-large.png | Bin 165148 -> 0 bytes
...talog-web-cluster-with-db-location-large.png | Bin 152721 -> 0 bytes
...ion-catalog-web-cluster-with-db-location.png | Bin 86425 -> 0 bytes
...-application-catalog-web-cluster-with-db.png | Bin 70109 -> 0 bytes
.../images/add-application-modal-yaml-large.png | Bin 124297 -> 0 bytes
.../start/images/add-application-modal-yaml.png | Bin 55183 -> 0 bytes
.../images/my-db-activities-step1-large.png | Bin 99671 -> 0 bytes
guide/start/images/my-db-activities-step1.png | Bin 57813 -> 0 bytes
.../images/my-db-activities-step2-large.png | Bin 176900 -> 0 bytes
guide/start/images/my-db-activities-step2.png | Bin 97061 -> 0 bytes
.../images/my-db-activities-step3-large.png | Bin 162986 -> 0 bytes
guide/start/images/my-db-activities-step3.png | Bin 84365 -> 0 bytes
guide/start/images/my-web-cluster-starting.png | Bin 32948 -> 0 bytes
.../my-web-cluster-stop-confirm-large.png | Bin 148155 -> 0 bytes
.../images/my-web-cluster-stop-confirm.png | Bin 79280 -> 0 bytes
guide/start/images/my-web-large.png | Bin 104519 -> 0 bytes
guide/start/images/my-web-summary-large.png | Bin 178785 -> 0 bytes
guide/start/images/my-web-summary.png | Bin 80583 -> 0 bytes
.../my-web-validating-app-endpoint-large.png | Bin 123007 -> 0 bytes
.../images/my-web-validating-app-endpoint.png | Bin 68969 -> 0 bytes
guide/start/images/my-web.png | Bin 58849 -> 0 bytes
guide/start/index.md | 15 -
guide/start/managing.md | 494 ----------------
guide/start/policies.md | 506 ----------------
guide/start/running.md | 260 --------
276 files changed, 18999 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/58bb3aa0/guide/blueprints/advanced-example.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/advanced-example.md b/guide/blueprints/advanced-example.md
deleted file mode 100644
index 786d2c5..0000000
--- a/guide/blueprints/advanced-example.md
+++ /dev/null
@@ -1,285 +0,0 @@
----
-title: YAML Blueprint Advanced Example
-layout: website-normal
----
-
-By this point you should be familiar with the fundamental concepts behind both Apache Brooklyn and YAML blueprints. This section of the documentation is intended to show a complete, advanced example of a YAML blueprint.
-
-The intention is that this example is used to learn the more in-depth concepts, and also to serve as a reference when writing your own blueprints. This page will first explain what the example application is and how to run it, then it will spotlight interesting features.
-
-Please note, there is now a much more up-to-date ELK blueprint that can be found [here](https://github.com/brooklyncentral/brooklyn-elk/). We've using an older version of this in the tutorial as it highlights some key Brooklyn concepts.
-
-
-### ELK Stack Example
-
-This example demonstrates the deployment of an ELK Stack (Elasticsearch, Logstash and Kibana), using the provided blueprint to deploy, install, run and manage all three. Briefly, the component parts are:
-
-* Elasticsearch: A clustered search engine
-* Logstash: Collects, parses and stores logs. For our example it will store logs in Elasticsearch
-* Kibana: A web front end to Elasticsearch
-
-We also deploy a simple webserver whose logs will be collected.
-
-* Tomcat 8: Web server whose logs will be stored in Elasticsearch by Logstash.
-
-For more about the ELK stack, please see the documentation [here](https://www.elastic.co/webinars/introduction-elk-stack).
-
-
-#### The Blueprints
------------
-
-There are four blueprints that make up this application. Each of them are used to add one or more catalog items to Brooklyn. You can find them below:
-
-* [Elasticsearch](example_yaml/brooklyn-elasticsearch-catalog.bom)
-* [Logstash](example_yaml/brooklyn-logstash-catalog.bom)
-* [Kibana](example_yaml/brooklyn-kibana-catalog.bom)
-* [ELK](example_yaml/brooklyn-elk-catalog.bom)
-
-#### Running the example
-First, add all four blueprints to the Brooklyn Catalog. This can be done by clicking the 'Catalog' tab, clicking the '+'
- symbol and pasting the YAML. Once this is done, click the 'Application' tab, then the '+' button to bring up the add
-application wizard. A new Catalog application will be available called 'ELK Stack'. Using the add application wizard,
-you should be able to deploy an ELK stack to a location of your choosing. Alternatively use the `br` Brooklyn
-command line tool and add the files with `br catalog add`.
-
-#### Exploring the example
-After the application has been deployed, you can ensure it is working as expected by checking the following:
-
-* There is a Kibana sensor called `main.uri`, the value of which points to the Kibana front end. You can explore this
-front end, and observe the logs stored in Elasticsearch. Many Brooklyn applications have a `main.uri` set to point you
-in the right direction.
-* You can also use the Elasticsearch REST API to explore further. The Elasticsearch Cluster entity has a `urls.http.list`
-sensor. Using a host:port from that list you will be able to access the REST API. The following URL will give you the
-state of the cluster `http://<host:port>/_cluster/health?pretty=true`. As you can see the `number_of_nodes` is
-currently 2, indicating that the Elasticsearch nodes are communicating with each other.
-
-### Interesting Feature Spotlight
-We will mainly focus on the Elasticsearch blueprint, and will be clear when another blueprint is being discussed. This blueprint describes a cluster of Elasticsearch nodes.
-
-#### Provisioning Properties
-Our Elasticsearch blueprint has a few requirements of the location in which it is run. Firstly, it must be run on an
-Ubuntu machine as the example has been written specifically for this OS. Secondly, two ports must opened to ensure
-that the entities can be accessed from the outside world. Both of these requirements are configured via
-`provisioning.properties` as follows:
-
-~~~yaml
-brooklyn.config:
- elasticsearch.http.port: 9220
- elasticsearch.tcp.port: 9330
- provisioning.properties:
- osFamily: ubuntu
- inboundPorts:
- - $brooklyn:config("elasticsearch.http.port")
- - $brooklyn:config("elasticsearch.tcp.port")
-~~~
-
-#### VanillaSoftwareProcess
-When composing a YAML blueprint, the VanillaSoftwareProcess is a very useful entity to be aware of.
-A VanillaSoftwareProcess will instruct Brooklyn to provision an instance, and run a series of shell
-commands to setup, run, monitor and teardown your program. The commands are specified as configuration
-on the VanillaSoftwareProcess and there are several available. We will spotlight a few now. To simplify
- this blueprint, we have specified ubuntu only installs so that our commands can be tailored to this
- system (e.g. use apt-get rather than yum).
-
-##### Customize Command
-The Customize Command is run after the application has been installed but before it is run. It is the perfect
- place to create and amend config files. Please refer to the following section of the Elasticsearch blueprint:
-
-~~~yaml
-customize.command: |
- 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: ${URLS_WITH_BRACKETS} | sudo tee -a /etc/elasticsearch/elasticsearch.yml
- echo http.port: ${ES_HTTP_PORT} | sudo tee -a /etc/elasticsearch/elasticsearch.yml
- echo transport.tcp.port: ${ES_TCP_PORT} | sudo tee -a /etc/elasticsearch/elasticsearch.yml
- echo network.host: ${IP_ADDRESS} | sudo tee -a /etc/elasticsearch/elasticsearch.yml
-~~~
-
-The purpose of this section is to create a YAML file with all of the required configuration. We use the YAML
-literal style `|` indicator to write a multi line command. We start our series of commands by using the `rm` command to remove the
-previous config file. We then use `echo` and `tee` to create the new config file and insert the config. Part
-of the configuration is a list of all hosts that is set on the parent entity- this is done by using a combination
- of the `component` and `attributeWhenReady` DSL commands. More on how this is generated later.
-
-##### Check running
-After an app is installed and run, this command is scheduled to run regularly and used to populate the `service.isUp`
-sensor. If this command is not specified, or returns an exit code of anything other than zero, then Brooklyn will
-assume that your entity has failed and will display the fire status symbol. Please refer to the following section
-of the Elasticsearch blueprint:
-
-~~~yaml
-checkRunning.command: sudo systemctl status kibana.service
-~~~
-
-There are many different ways to implement this command. For this example, we are simply using the systemctl status
-of the appropriate service.
-
-#### Enrichers
-
-##### Elasticsearch URLS
-To ensure that all Elasticsearch nodes can communicate with each other they need to be configured with the TCP URL
-of all other nodes. Similarly, the Logstash instances need to be configured with all the HTTP URLs of the Elasticsearch
-nodes. The mechanism for doing this is the same, and involves using Transformers, Aggregators and Joiners, as follows:
-
-~~~yaml
-brooklyn.enrichers:
- - type: org.apache.brooklyn.enricher.stock.Transformer
- brooklyn.config:
- enricher.sourceSensor: $brooklyn:sensor("host.subnet.address")
- enricher.targetSensor: $brooklyn:sensor("url.tcp")
- enricher.targetValue: $brooklyn:formatString("%s:%s", $brooklyn:attributeWhenReady("host.subnet.address"), $brooklyn:config("elasticsearch.tcp.port"))
-~~~
-
-In this example, we take the host.subnet.address and append the TCP port, outputting the result as `url.tcp`.
-After this has been done, we now need to collect all the URLs into a list in the Cluster entity, as follows:
-
-~~~yaml
-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
-
-~~~
-
-In the preceding example, we aggregated all of the TCP URLs generated in the early example.
-These are then stored in a sensor called `urls.tcp.list`. This list is then joined together into one long string:
-
-~~~yaml
-- 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
-~~~
-
-Finally, the string has brackets added to the start and end:
-
-~~~yaml
-- 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"))
-~~~
-
-The resulting sensor will be called `urls.tcp.withBrackets` and will be used by all Elasticsearch nodes during setup.
-
-##### Kibana URL
-Kibana also needs to be configured such that it can access the Elasticsearch cluster. However, Kibana can
- only be configured to point at one Elasticsearch instance. To enable this, we use another enricher in the
- cluster to select the first URL from the list, as follows:
-
-~~~yaml
-- type: org.apache.brooklyn.enricher.stock.Aggregator
- brooklyn.config:
- enricher.sourceSensor: $brooklyn:sensor("host.subnet.address")
- enricher.targetSensor: $brooklyn:sensor("host.address.first")
- enricher.aggregating.fromMembers: true
- enricher.transformation:
- $brooklyn:object:
- type: "org.apache.brooklyn.util.collections.CollectionFunctionals$FirstElementFunction"
-~~~
-
-Similar to the above Aggregator, this Aggregator collects all the URLs from the members of the cluster.
-However, this Aggregator specifies a transformation. In this instance a transformation is a Java class that
-implements a Guava Function `<? super Collection<?>, ?>>`, i.e. a function that takes in a collection and
-returns something. In this case we specify the FirstElementFunction from the CollectionFunctionals to ensure
-that we only get the first member of the URL list.
-
-#### Latches
-In the ELK blueprint, there is a good example of a latch. Latches are used to force an entity to wait until
-certain conditions are met before continuing. For example:
-
-~~~yaml
-- type: kibana-standalone
- id: kibana
- name: Kibana Server
- latch.customize: $brooklyn:component("es").attributeWhenReady("service.isUp")
-~~~
-
-This latch is used to stop Kibana customizing until the Elasticsearch cluster is up. We do this to ensure
-that the URL sensors have been setup, so that they can be passed into Kibana during the customization phase.
-
-Latches can also be used to control how many entities can execute the same step at any given moment. When
-a latch is given the value of a `MaxConcurrencySensor` it will unblock execution only when there are
-available "slots" to execute (think of it as a semaphore). For example to let a single entity execute the
-launch step of the start effector:
-
-~~~yaml
-services:
-- type: cluster
-
- brooklyn.initializers:
- - type: org.apache.brooklyn.core.sensor.MaxConcurrencySensor
- brooklyn.config:
- name: single-executor
- latch.concurrency.max: 1
-
- brooklyn.config:
- initialSize: 10
- memberSpec:
- $brooklyn:entitySpec:
- type: vanilla-bash-server
- brooklyn.config:
- launch.command: sleep 2
- checkRunning.command: true
- latch.launch: $brooklyn:parent().attributeWhenReady("single-executor")
-~~~
-
-It's important to note that the above setup is not reentrant. This means that users should be careful to
-avoid deadlocks. For example having a start and launch latches against the `single-executor` from above.
-The launch latch will block forever since the start latch already would've acquired the free slot.
-
-#### Child entities
-The ELK blueprint also contains a good example of a child entity.
-
-~~~yaml
-- type: org.apache.brooklyn.entity.webapp.tomcat.Tomcat8Server
- brooklyn.config:
- children.startable.mode: background_late
- ...
- brooklyn.children:
- - type: logstash-child
-~~~
-
-In this example, a logstash-child is started as a child of the parent Tomcat server. The Tomcat server needs
-to be configured with a `children.startable.mode` to inform Brooklyn when to bring up the child. In this case
- we have selected background so that the child is disassociated from the parent entity, and late to specify that
- the parent entity should start before we start the child.
-
-The example also shows how to configure Logstash inputs and filters, if necessary, for a particular application,
-in this case Tomcat.
-
-~~~yaml
-- type: logstash-child
- name: Logstash
- brooklyn.config:
- logstash.elasticsearch.hosts: $brooklyn:entity("es").attributeWhenReady("urls.http.withBrackets")
- logstash.config.input:
- $brooklyn:formatString:
- - |
- input {
- file {
- path => "%s/logs/localhost_access_log.*"
- start_position => "beginning"
- }
- }
- - $brooklyn:entity("tomcat").attributeWhenReady("run.dir")
- logstash.config.filter: |
- filter {
- grok {
- match => { "message" => "%{COMBINEDAPACHELOG}" }
- }
- date {
- match => [ "timestamp" , "dd/MMM/yyyy:HH:mm:ss Z" ]
- }
- }
-~~~
-
-Configuring an appropriate visualisation on the Kibana server (access it via the URL on the summary tab for
-that entity) allows a dashboard to be created such as
-
-
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/58bb3aa0/guide/blueprints/ansible/about-ansible.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/ansible/about-ansible.md b/guide/blueprints/ansible/about-ansible.md
deleted file mode 100644
index 9886993..0000000
--- a/guide/blueprints/ansible/about-ansible.md
+++ /dev/null
@@ -1,34 +0,0 @@
----
-title: About Ansible
-title_in_menu: About Ansible
-layout: website-normal
----
-
-## What you need to know about Ansible
-
-[Ansible](http://docs.ansible.com/ansible/) is a deployment tool designed to work in an agent-less manner, normally
-performing its operations on a node over SSH from some central administrating node. Brooklyn can deploy software
-via Ansible on one of its managed nodes, by first installing Ansible on the node itself and then using Ansible to deploy
-the required software.
-
-A 'Playbook' in Ansible is a specification of the configuration and deployment of a system.
-Playbooks are expressed in YAML format, and contain a number of 'plays', which are in turn lists of tasks to carry out
-to achieve the desired configuration on the system. 'Roles' are pre-written modular collections of tasks, and can
-be included in playbooks.
-
-Ansible comes with built-in support for many software systems, and has a community repository of roles exists at
-[https://galaxy.ansible.com](https://galaxy.ansible.com).
-
-
-### How Brooklyn interacts with Ansible
-
-Brooklyn provides a Ansible entity type. An entity of this type can be specified in a blueprint in order to provision the
-node through Ansible. The Ansible entity will download Ansible and install it on the node. The entity type supports the
-configuration of Ansible playbooks to download, or write inline in the blueprint, for simple playbooks.
-Configuration values for the playbooks can be supplied in the blueprint.
-
-Brooklyn will deploy the software specified in the playbook when the entity starts. In addition, an effector is
-provided on the entity that supports general purpose Ansible instructions.
-
-
-
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/58bb3aa0/guide/blueprints/ansible/creating-ansible-blueprints.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/ansible/creating-ansible-blueprints.md b/guide/blueprints/ansible/creating-ansible-blueprints.md
deleted file mode 100644
index 6f92524..0000000
--- a/guide/blueprints/ansible/creating-ansible-blueprints.md
+++ /dev/null
@@ -1,213 +0,0 @@
----
-title: Creating Blueprints with Ansible
-title_in_menu: Creating Blueprints with Ansible
-layout: website-normal
----
-
-To write a blueprint to use Ansible with Brooklyn it will help to have a degree of familiarity with Ansible itself. In the
-sections below, when the Brooklyn configuration is described, the underlying Ansible operation is also noted briefly, for
-clarity for readers who know Ansible.
-
-To manage a node with Ansible, create a blueprint containing a service of type `org.apache.brooklyn.entity.cm.ansible.AnsibleEntity`
-and define and minimum the `playbook` value, and one or other of `playbook.url` or `playbook.yaml`. You must also define
-the `service.name` that will be tested in order to determine if the entity is running successfully.
-
-For example:
-
- name: myweb
- location: ...
- services:
- - type: org.apache.brooklyn.entity.cm.ansible.AnsibleEntity
- id: apache
- name: apache
- service.name: apache2
- playbook: apache-playbook
- playbook.url: http://myhost/projectX/apache-playbook.yaml
-
-
-This example specifies that Brooklyn should use Ansible to download the playbook from the repository on
-"myhost". The playbook contains the instructions to install the Apache web server. To start the
-entity, Brooklyn will use Ansible's "ansible-playbook" command to run the playbook, which will bring up the web server.
-
-
-### Lifecycle of AnsibleEntity
-
-The start effector applies the playbook and verifies that it has started the software correctly by checking the service
-defined as `service.name` is running. This can be customized, see `ansible.service.start` configuration below.
-
-The stop effector will stop the service `service.name`. Again, this can be customized, with `ansible.service.stop`.
-
-The restart effector will apply stop and then start.
-
-
-### Configuration of AnsibleEntity
-
-The `playbook` configuration key names the top level list of states that will be applied using Ansible.
- This configuration key is mandatory.
-
-The playbook must be defined using one or other (both together are not permitted) of `playbook.yaml` or `playbook.url`.
-The former allows the playbook content to be defined inline within the blueprint, using the normal YAML format of an
-Ansible playbook. The latter obtains the playbook from an external URL.
-
-The `ansible.service.start` configuration key allows the blueprint author to override the command used by default to
-verify that the service `service.name` is running (or to start it, if the playbook did not specify it should run by
-default). The default value is:
-
- sudo ansible localhost -c local -m service -a "name=<service.name> state=started"
-
-Similarly the `ansible.service.stop` configuration key permits override of the instruction used to get Ansible to stop the
-service, by default
-
- sudo ansible localhost -c local -m service -a "name=<service.name> state=stopped"
-
-The `ansible.service.checkPort` configuration key allows the user to override the mechanism used to check that the
-service `service.name` is operating. By default Brooklyn checks that the service process is running. However, if the
- service is one that listens on a particular port, this configuration key allows the blueprint author to instruct
- Brooklyn to check that the port is being listened on, using the Ansible `wait_for` module. The value of the key is
- the port number to check.
-
-The `ansible.vars` configuration key allows the blueprint author to provide entity-specific values for configuration
-variables used in the playbook, so that one playbook can be used by multiple entities, each customized appropriately.
-The value of `ansible.vars` is an arbitrary block of YAML configuration that will be applied to the playbook using
-Ansible's `--extra-vars` mechanism, as described in the
-Ansible [documentation](http://docs.ansible.com/ansible/playbooks_variables.html#passing-variables-on-the-command-line).
-For example, if the playbook in the example above contained configuration such as:
-
- - hosts: all
- vars:
- http_port: 80
- max_clients: 200
- remote_user: root
- tasks:
- ...
-
- then to change the port that the webserver in the example above runs on, it would be possible to define the following
- in the blueprint:
-
- name: myweb
- location: ...
- services:
- - type: org.apache.brooklyn.entity.cm.ansible.AnsibleEntity
- id: apache
- name: apache
- service.name: apache2
- playbook: apache-playbook
- playbook.url: http://myhost/projectX/apache-playbook.yaml
- ansible.vars:
- http_port: 8080
-
-
-### ansibleCall Effector
-
-The Ansible entity includes a general purpose Ansible effector, `ansibleCommand`, which permits execution of Ansible
-commands via `ansible`. It contains a two parameters:
-1. `module` specifies the Ansible module to invoke. The default is "command".
-2. `args` specifies the argument data for the Ansible module. For example, to download an additional file for the
-webserver, the command could be invoked with the following arguments. (For convenience this
-example uses the client CLI, "br", but the effector could be invoked by any applicable means, e.g. via the web UI
-or REST API.)
-
- $ br app myweb ent apache effector ansibleCommand invoke \
- -P module=shell -P args='curl http://myhost:8080/additional.html > /var/www/html/additional.html'
-
-### Roles and Multi-Playbook Installations
-
-There is no specific configuration in AnsibleEntity for Ansible [Roles](http://docs.ansible.com/ansible/playbooks_roles.html),
- or to install multiple playbooks. However, the installation of roles or multiple playbooks can be carried out first
- by taking advantage of Brooklyn's SameServerEntity. The installation step can be applied in one child of the same server
- entity, while the AnsibleEntity can operate under the second child. It will typically be necessary to delay the start
- of the AnsibleEntity until the first child has carried out whatever preparation is required. The examples below
- illustrate the concept (with just one playbook, for brevity).
-
- One way to a achieve this, as with any Brooklyn entity, is to use the idiom of making it a child of a BasicApplication
- with a start latch waiting on the first child, such as in the following example, which installs the standalone Tomcat example,
- with its playbook and roles, from the "Ansible Examples" Github site.
- (Note, this is designed for installation on Redhat/Centos 6.)
- The first child in the SameServerEntity downloads
- and unpacks the Ansible examples. This might also install standalone Ansible roles, or whatever other resources the
- AnsibleEntity might require. The second child uses `attributeWhenReady` to block until the first is ready, before
- starting the AnsibleEntity to apply the desired playbook.
-
-
- name: multi
- location:
- red1
- services:
- - serviceType: brooklyn.entity.basic.SameServerEntity
- name: Entities
- brooklyn.children:
-
- - serviceType: org.apache.brooklyn.entity.cm.ansible.AnsibleEntity
- id: bootstrap
- service.name: crond
- playbook: bootstrap
- playbook.yaml: |
- ---
- - hosts: localhost
- tasks:
- - shell: printf "[tomcat-servers]\nlocalhost ansible_connection=local\n" >> /etc/ansible/hosts
- - file: path=/etc/ansible/playbooks state=directory mode=0755
- - get_url: url=https://github.com/ansible/ansible-examples/archive/master.zip dest=/tmp/master.zip mode=0440
- - command: unzip -o -d /etc/ansible/playbooks /tmp/master.zip
-
- - serviceType: org.apache.brooklyn.entity.stock.BasicApplication
- latch.start: $brooklyn:entity("bootstrap").attributeWhenReady("service.isUp")
- brooklyn.children:
- - type: org.apache.brooklyn.entity.cm.ansible.AnsibleEntity
- name: test
- service.name: tomcat
- playbook: tomcat
- playbook.yaml: |
- ---
- - hosts: localhost
- - include: /etc/ansible/playbooks/ansible-examples-master/tomcat-standalone/site.yml
- vars:
- http_port: 8080
- https_port: 8443
- admin_username: admin
- admin_password: secret
-
-
-An alternative to the above is to use Ansible itself to do the waiting, as in the variant below, which uses AnsibleEntity
-itself in the first SameServerEntity child, to install the required material. In the second child, which is simply an
-AnsibleEntity rather than a BasicApplication, Ansible's `wait_for` operation is used as the first step in the playbook,
-to block the remaining steps in its playbook until the first is complete.
-
- name: multi
- location:
- red1
- services:
- - serviceType: brooklyn.entity.basic.SameServerEntity
- name: Entities
- brooklyn.children:
-
- - serviceType: org.apache.brooklyn.entity.cm.ansible.AnsibleEntity
- id: bootstrap
- service.name: crond
- playbook: bootstrap
- playbook.yaml: |
- ---
- - hosts: localhost
- tasks:
- - command: rm -f /tmp/bootstrap.done
- - shell: printf "[tomcat-servers]\nlocalhost ansible_connection=local\n" >> /etc/ansible/hosts
- - file: path=/etc/ansible/playbooks state=directory mode=0755
- - get_url: url=https://github.com/ansible/ansible-examples/archive/master.zip dest=/tmp/master.zip mode=0440
- - command: unzip -o -d /etc/ansible/playbooks /tmp/master.zip
- - file: path=/tmp/bootstrap.done state=touch
-
- - serviceType: org.apache.brooklyn.entity.cm.ansible.AnsibleEntity
- name: test
- service.name: tomcat
- playbook: tomcat
- playbook.yaml: |
- ---
- - tasks:
- - wait_for: path=/tmp/bootstrap.done
- include: /etc/ansible/playbooks/ansible-examples-master/tomcat-standalone/site.yml
- vars:
- http_port: 8080
- https_port: 8443
- admin_username: admin
- admin_password: secret
-
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/58bb3aa0/guide/blueprints/ansible/index.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/ansible/index.md b/guide/blueprints/ansible/index.md
deleted file mode 100644
index a2376d1..0000000
--- a/guide/blueprints/ansible/index.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-title: Ansible in YAML Blueprints
-layout: website-normal
-children:
-- about-ansible.md
-- creating-ansible-blueprints.md
----
-
-This guide describes how Brooklyn entities can be created using the Ansible infrastructure management tool
- ([ansible.com](http://ansible.com)).
-At present Brooklyn provides basic support for Ansible, operating in a 'masterless' mode.
-Comments on this support and suggestions for further development are welcome.
-
-This guide assumes you are familiar with the basics of [creating YAML blueprints](../).
-
-{% include list-children.html %}
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/58bb3aa0/guide/blueprints/blueprinting-tips.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/blueprinting-tips.md b/guide/blueprints/blueprinting-tips.md
deleted file mode 100644
index 9712fef..0000000
--- a/guide/blueprints/blueprinting-tips.md
+++ /dev/null
@@ -1,183 +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.
-
-
-## Be Familiar with Brooklyn
-
-Be familiar with the stock entities available in Brooklyn. For example, prove you understand
-the concepts by making a deployment of a cluster of Tomcat servers before you begin writing your
-own blueprints.
-
-
-## Ask For Help
-
-Ask for help early. The community is keen to help, and also keen to find out what people find
-hard and how people use the product. Such feedback is invaluable for improving future versions.
-
-
-## 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 Bring Your Own Nodes (BYON)
-
-A [BYON location]({{ site.path.guide }}/locations/#byon) 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]({{ site.path.guide }}/start/running.html) (e.g. with VirtualBox)
-to create VMs on your local machine, and to use these as the target for a BYON location.
-
-These VMs should mirror the target environment as much as possible.
-
-
-#### 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 Clocker
-
-Docker containers provide a convenient way to test blueprints (and also to run blueprints in
-production!).
-
-The [Clocker project](http://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.
-
-
-#### Local Repository of 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 possible, synchronise this directory with your test VMs.
-
-
-#### Re-install on BYON
-
-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 (a marker file being used to indicate completion). 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.
-
-
-## Monitoring and Managing Applications
-
-Think about what it really means for an application to be running. The out-of-the-box default
-for a software process is the lowest common denominator: that the process is still running.
-Consider checking that the app responds over HTTP etc.
-
-If you have control of the app code, then consider adding an explicit health check URL that
-does more than basic connectivity tests. For example, can it reach the database, message broker,
-and other components that it will need for different operations.
-
-
-## Writing Composite Blueprints
-
-Write everything in discrete chunks that can be composed into larger pieces. Do not write a single
-mega-blueprint. For example, ensure each component is added to the catalog independently, along
-with a blueprint for the composite app.
-
-Experiment with lots of small blueprints to test independent areas before combining them into the
-real thing.
-
-
-## Writing Entity Tests
-
-Use the [test framework]({{ site.path.guide }}/blueprints/test/) to write test cases. This will make
-automated (regression) testing easier, and will allow others to easily confirm that the entity
-works in their environment.
-
-If using Maven/Gradle then use the [Brooklyn Maven plugin](https://github.com/brooklyncentral/brooklyn-maven-plugin)
-to test blueprints at build time.
-
-
-## Custom Entity Development
-
-If writing a custom integration, the following recommendations may be useful:
-
-* Always be comfortable installing and running the process yourself before attempting to automate
- it.
-
-* 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.
-
-* Where appropriate, share the new entity with the Brooklyn community so that it can be reviewed,
- tested and improved by others in the community!
-
-
-## Cloud Portability
-
-You get a lot of support out-of-the-box for deploying blueprints to different clouds. The points
-below may also be of help:
-
-* Test (and regression test) on each target cloud.
-
-* Be aware that images on different clouds can be very different. For example, two CentOS 6.6 VMs
- might have different pre-installed libraries, different default iptables or SE Linux settings,
- different repos, different sudo configuration, etc.
-
-* Different clouds handle private and public IPs differently. One must be careful about which
- address to advertise to for use by other entities.
-
-* VMs on some clouds may not have a well-configured hostname (e.g. `ping $(hostname)` can fail).
-
-* VMs in different clouds have a different number of NICs. This is important when choosing whether
- to listen on 0.0.0.0 or on a specific NIC.
-
-
-## Investigating Errors
-
-ALWAYS keep logs when there is an error.
-
-See the [Troubleshooting]({{ site.path.guide }}/ops/troubleshooting/) guide for more information.
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/58bb3aa0/guide/blueprints/catalog/bundle.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/catalog/bundle.md b/guide/blueprints/catalog/bundle.md
deleted file mode 100644
index 964dee0..0000000
--- a/guide/blueprints/catalog/bundle.md
+++ /dev/null
@@ -1,145 +0,0 @@
----
-title: Bundling
-layout: website-normal
----
-
-### Bundling Catalog Resources
-
-It is possible to upload catalog items and associated resources as a single bundle to AMP.
-This is useful when you have a blueprint that needs to reference external scripts, icons,
-config files or other resources, or
-when you have multiple blueprints that you want to keep in sync. Brooklyn will persist any
-uploaded bundles so that they are available after a restart or on HA failover.
-
-The bundle must be a ZIP file including a `catalog.bom` in the root.
-(The `br` CLI will create a ZIP from a local folder, for convenience.)
-The `catalog.bom` must declare a `bundle` identifier and a `version`,
-following Brooklyn's [versioning](versioning.html) rules.
-Brooklyn will keep track of that bundle, allowing items to be added and removed as a group,
-and associated resources to be versioned and included alongside them.
-With SNAPSHOT-version bundles, it allows replacement of multiple related items at the same time,
-and in advanced cases it allows setting up dependent bundles
-(specified as `brooklyn.libraries` or, for people familiar with OSGi, the `Required-bundle` manifest header)
-which will be searched if a blueprint in one bundle references resources from another bundle.
-
-Resources in the bundle can be referenced from the `catalog.bom` by using
-the `classpath:` URL protocol, as in `classpath://path/to/script.sh`.
-This can also be used to load resources in explicitly declared dependent bundles.
-
-
-### Example
-
-In this example, we will create a simple `my-server` catalog item, bundled with a simple script. The script will be run when launching the server.
-
-First, create a folder called bundleFolder, then add a file called myfile.sh to it.
-The contents of myfile.sh should be as follows:
-
-~~~ bash
-echo Hello, World!
-~~~
-
-Now create a file in bundleFolder called `catalog.bom` with the following contents:
-
-~~~ yaml
-brooklyn.catalog:
- bundle: MyServerBundle
- version: 1.0.0
- items:
- - id: my-server
- item:
- type: org.apache.brooklyn.entity.software.base.VanillaSoftwareProcess
- brooklyn.config:
- files.runtime:
- classpath://myfile.sh: files/myfile.sh
- launch.command: |
- chmod +x ./files/myfile.sh
- ./files/myfile.sh
- checkRunning.command: echo "Running"
-
-~~~
-
-The `bundle: MyServerBundle` line specifies the OSGI bundle name for this bundle. Any resources included
-in this bundle will be accessible on the classpath, but will be scoped to this bundle. This prevents an
-issue where multiple bundles include the same resource.
-
-To create the bundle, simply use the br command as follows. This will create a zip and send it to Brooklyn. Please note you can also specify a zip file (either on the file system or hosted remotely):
-
-~~~ bash
-br catalog add bundleFolder
-~~~
-
-This will have added our bundle to the catalog. We can now deploy an instance of our server as follows. Please note that in this example we deploy to localhost. If you have not setup your machine to use localhost please see the instructions [here](../../locations#localhost-setup) or use a non localhost location.
-
-~~~ yaml
-location: localhost
-services:
-- type: my-server
-~~~
-
-We can now see the result of running that script. In the UI find the activities for this application. The start activity has a sub task called launch (you will have to click through multiple activities called start/launch. Looking at the stdout of the launch task you should see:
-
-~~~ bash
-Hello, World!
-~~~
-
-Alternatively you can view the script directly if you run the following against localhost. Please note that brooklyn-username and the id of your app will be different.
-
-~~~ bash
-cat /tmp/brooklyn-username/apps/nl9djqbq2i/entities/VanillaSoftwareProcess_g52gahfxnt/files/myfile.sh
-~~~
-
-It should look like this:
-
-~~~ bash
-echo Hello, World!
-~~~
-
-Now modify `myfile.sh` to contain a different message, change the version number in `catalog.bom` to
-`1.1.0`, and use the br command to send the bundle to the server.
-
-If you now deploy a new instance of the server using the same YAML as above, you should be
-able to confirm that the new script has been run (either by looking at the stdout of the launch task, or looking at the script itself)
-
-At this point, it is also possible to deploy the original `Hello, World!` version by explicitly stating
-the version number in the YAML:
-
-~~~ yaml
-location: localhost
-services:
-- type: my-server:1.0.0
-~~~
-
-To demonstrate the scoping, you can create another bundle with the following `catalog.bom`. Note the
-bundle name and entity id have been changed, but it still references a script with the same name.
-
-~~~ yaml
-brooklyn.catalog:
- bundle: DifferentServerBundle
- version: 1.0.0
- item:
- id: different-server
- type: org.apache.brooklyn.entity.software.base.VanillaSoftwareProcess
- brooklyn.config:
- files.runtime:
- classpath://myfile.sh: files/myfile.sh
- launch.command: |
- chmod +x ./files/myfile.sh
- ./files/myfile.sh
-
- checkRunning.command:
- echo "Running"
-~~~
-
-Now create a new `myfile.sh` script with a different message, and use the br command to send the bundle to Brooklyn.
-
-Now deploy a blueprint which deploys all three servers. Each of the three deployments will utilise the script that was included with their bundle.
-
-~~~ yaml
-location: localhost
-services:
-- type: my-server:1.0.0
-- type: my-server:1.1.0
-- type: different-server
-~~~
-
-**Note**: All three entities copy a file from `classpath://myfile.sh`, but as they are in different bundles, the scripts copied to the server will be different.
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/58bb3aa0/guide/blueprints/catalog/cli.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/catalog/cli.md b/guide/blueprints/catalog/cli.md
deleted file mode 100644
index 2621a5b..0000000
--- a/guide/blueprints/catalog/cli.md
+++ /dev/null
@@ -1,31 +0,0 @@
----
-title: Brooklyn Server Command Line Arguments
-layout: website-normal
----
-
-### Brooklyn Server Command Line Arguments
-
-The command line arguments when launching `brooklyn` include several commands for working with the catalog.
-
-* `--catalogAdd <file.bom>` will add the catalog items in the `bom` file
-* `--catalogReset` will reset the catalog to the initial state
- (based on `brooklyn/default.catalog.bom` on the classpath, by default in a dist in the `conf/` directory)
-* `--catalogInitial <file.bom>` will set the catalog items to use on first run,
- on a catalog reset, or if persistence is off
-
-If `--catalogInitial` is not specified, the default initial catalog at `brooklyn/default.catalog.bom` will be used.
-As `scanJavaAnnotations: true` is set in `default.catalog.bom`, Brooklyn will scan the classpath for catalog items,
-which will be added to the catalog.
-To launch Brooklyn without initializing the catalog, use `--catalogInitial classpath://brooklyn/empty.catalog.bom`
-
-If [persistence](../../ops/persistence/) is enabled, catalog additions will remain between runs. If items that were
-previously added based on items in `brooklyn/default.catalog.bom` or `--catalogInitial` are
-deleted, they will not be re-added on subsequent restarts of brooklyn. I.e. `--catalogInitial` is ignored
-if persistence is enabled and persistent state has already been created.
-
-For more information on these commands, run `brooklyn help launch`.
-
-
-<!--
-TODO: make test cases from the code snippets here, and when building the docs assert that they match test cases
--->
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/58bb3aa0/guide/blueprints/catalog/images/add-to-catalog.png
----------------------------------------------------------------------
diff --git a/guide/blueprints/catalog/images/add-to-catalog.png b/guide/blueprints/catalog/images/add-to-catalog.png
deleted file mode 100644
index 0565e7e..0000000
Binary files a/guide/blueprints/catalog/images/add-to-catalog.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/58bb3aa0/guide/blueprints/catalog/index.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/catalog/index.md b/guide/blueprints/catalog/index.md
deleted file mode 100644
index ed56483..0000000
--- a/guide/blueprints/catalog/index.md
+++ /dev/null
@@ -1,21 +0,0 @@
----
-title: Catalog
-layout: website-normal
-children:
-- schema.md
-- templates.md
-- versioning.md
-- management.md
-- bundle.md
-- cli.md
-
-
----
-
-Apache Brooklyn provides a **catalog**, which is a persisted collection of versioned blueprints
-and other resources. A set of blueprints is loaded from the `default.catalog.bom` in the Brooklyn
-folder by default and additional ones can be added through the web console or CLI. Blueprints in
-the catalog can be deployed directly, via the Brooklyn CLI or the web console, or referenced in
-other blueprints using their `id`.
-
-{% include list-children.html %}
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/58bb3aa0/guide/blueprints/catalog/management.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/catalog/management.md b/guide/blueprints/catalog/management.md
deleted file mode 100644
index 7dc2072..0000000
--- a/guide/blueprints/catalog/management.md
+++ /dev/null
@@ -1,58 +0,0 @@
----
-title: Catalog Management
-layout: website-normal
----
-
-### Catalog Management
-
-The Catalog tab in the web console will show all versions of catalog items,
-and allow you to add new items.
-
-
-#### Adding to the Catalog
-
-On the UI the "add" button <img src="images/add-to-catalog.png" width="24" alt="add-to-catalog" /> at the top of the menu panel allows the
-addition of new Applications to the catalog, via YAML, and of new Locations.
-
-In addition to the GUI, items can be added to the catalog via the REST API
-with a `POST` of the YAML file to `/v1/catalog` endpoint.
-To do this using `curl`:
-
-~~~ bash
-curl -u admin:password http://127.0.0.1:8081/v1/catalog --data-binary @/path/to/riak.catalog.bom
-~~~
-
-Or using the CLI:
-
-~~~ bash
-br catalog add /path/to/riak.catalog.bom
-~~~
-
-
-
-#### Deleting from the Catalog
-
-On the UI, if an item is selected, a 'Delete' button in the detail panel can be used to delete it from the catalog.
-
-Using the REST API, you can delete a versioned item from the catalog using the corresponding endpoint.
-For example, to delete the item with id `datastore` and version `1.0` with `curl`:
-
-~~~ bash
-curl -u admin:password -X DELETE http://127.0.0.1:8081/v1/catalog/applications/datastore/1.0
-~~~
-
-
-**Note:** Catalog items should not be deleted if there are running apps which were created using the same item.
-During rebinding the catalog item is used to reconstruct the entity.
-
-If you have running apps which were created using the item you wish to delete, you should instead deprecate the catalog item.
-Deprecated catalog items will not appear in the add application wizard, or in the catalog list but will still
-be available to Brooklyn for rebinding. The option to display deprecated catalog items in the catalog list will be added
-in a future release.
-
-Deprecation applies to a specific version of a catalog item, so the full
-id including the version number is passed to the REST API as follows:
-
-~~~ bash
-curl -u admin:password -X POST http://127.0.0.1:8081/v1/catalog/entities/MySQL:1.0/deprecated/true
-~~~
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/58bb3aa0/guide/blueprints/catalog/mysql-in-catalog-w700.png
----------------------------------------------------------------------
diff --git a/guide/blueprints/catalog/mysql-in-catalog-w700.png b/guide/blueprints/catalog/mysql-in-catalog-w700.png
deleted file mode 100644
index f370249..0000000
Binary files a/guide/blueprints/catalog/mysql-in-catalog-w700.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/58bb3aa0/guide/blueprints/catalog/mysql-in-catalog.png
----------------------------------------------------------------------
diff --git a/guide/blueprints/catalog/mysql-in-catalog.png b/guide/blueprints/catalog/mysql-in-catalog.png
deleted file mode 100644
index 685455d..0000000
Binary files a/guide/blueprints/catalog/mysql-in-catalog.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/58bb3aa0/guide/blueprints/catalog/schema.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/catalog/schema.md b/guide/blueprints/catalog/schema.md
deleted file mode 100644
index 3edccf9..0000000
--- a/guide/blueprints/catalog/schema.md
+++ /dev/null
@@ -1,272 +0,0 @@
----
-title: Catalog Items YAML Syntax
-layout: website-normal
----
-
-### Catalog Items YAML Syntax
-
-An item or items to be added to the catalog is defined by a YAML file,
-specifying the catalog metadata for the items and the actual blueprint or resource definition.
-
-
-#### General YAML Schema
-
-Catalog items can be defined using the general structure below:
-
-~~~ yaml
-brooklyn.catalog:
- <catalog-metadata>
- items:
- - <additional-catalog-metadata>
- item:
- <blueprint-or-resource-definition>
- - <additional-catalog-metadata>
- item:
- <blueprint-or-resource-definition>
-~~~
-
-Alternatively, a single catalog item can be defined using the following general structure:
-
-~~~ yaml
-brooklyn.catalog:
- <catalog-metadata>
- item:
- <blueprint-or-resource-definition>
-~~~
-
-For example, the YAML below adds to the catalog a Tomcat entity with some additional default
-configuration:
-
-~~~ yaml
-brooklyn.catalog:
- items:
- - id: tomcat-server
- version: "1.0.0"
- itemType: entity
- item:
- type: org.apache.brooklyn.entity.webapp.tomcat.Tomcat8Server
- brooklyn.config:
- webapp.enabledProtocols: https
- httpsSsl:
- url: classpath://org/apache/brooklyn/entity/webapp/sample-java-keystore.jks
- alias: myname
- password: mypass
-~~~
-
-
-#### Catalog Metadata
-
-Catalog metadata fields supply the additional information required in order to register an item in the catalog.
-These fields can be supplied as `key: value` entries
-where either the `<catalog-metadata>` or `<additional-catalog-metadata>` placeholders are,
-with the latter overriding the former unless otherwise specified below.
-
-The following metadata is *required* for all items:
-
-- `id`: a human-friendly unique identifier for how this catalog item will be referenced from blueprints
-- `version`: multiple versions of a blueprint can be installed and used simultaneously;
- this field disambiguates between blueprints of the same `id`.
- Note that this is typically *not* the version of the software being installed,
- but rather the version of the blueprint. For more information on versioning, see below.
- (Also note YAML treats numbers differently to Strings. Explicit quotes are recommended, to avoid
- `1.10` being interpretted as the number `1.1`.)
-- `itemType`: the type of the item being defined. The supported item types are:
- - `entity`
- - `template`
- - `policy`
- - `location`
-
-To reference a catalog item in another blueprint, simply reference its ID and optionally its version number.
-For instance, if we've added an item with metadata `{ id: datastore, version: "1.0" }` (such as the example below),
-we could refer to it in another blueprint with:
-
-~~~ yaml
-services:
-- type: datastore:1.0
-~~~
-
-In addition to the above fields, exactly **one** of the following is also required:
-
-- `item`: the YAML for an entity, or policy, or location specification
- (a map containing `type` and optional `brooklyn.config`). For a "template" item, it
- should be a map containing `services` (i.e. the usual YAML format for a full application
- blueprint). **Or**
-- `items`: a list of catalog items, where each entry in the map follows the same schema as
- the `brooklyn.catalog` value, and the keys in these map override any metadata specified as
- a sibling of this `items` key (or, in the case of `brooklyn.libraries` they add to the list);
- if there are references between items, then order is important:
- `items` are processed in order, depth-first, and forward references are not supported. Entries
- can be URL to another catalog file to include, inheriting the metadata from the current hierarchy.
- Libraries defined so far in the metadata will be used to load classpath entries. For example:
-
-~~~ yaml
-brooklyn.catalog:
- brooklyn.libraries:
- - http://some.server.or.other/path/my.jar
- items:
- - classpath://my-catalog-entries-inside-jar.bom
- - some-property: value
- include: classpath://more-catalog-entries-inside-jar.bom
- - id: use-from-my-catalog
- version: "1.0.0"
- itemType: entity
- item:
- type: some-type-defined-in-my-catalog-entries
- brooklyn.config:
- some.config: "some value"
-~~~
-
-The following optional catalog metadata is supported:
-
-- `name`: a nicely formatted display name for the item, used when presenting it in a GUI.
-- `description`: supplies an extended textual description for the item.
-- `iconUrl`: points to an icon for the item, used when presenting it in a GUI.
- The URL prefix `classpath` is supported but these URLs may *not* refer to resources in any OSGi
- bundle in the `brooklyn.libraries` section (to prevent requiring all OSGi bundles to be loaded
- at launch). Icons are instead typically installed either at the web server from which the OSGi
- bundles or catalog items are supplied or in the `conf` folder of the Brooklyn distro.
-- `scanJavaAnnotations` [experimental; deprecated]: if provided (as `true`), this will scan any
- locally provided library URLs for types annotated `@Catalog` and extract metadata to include
- them as catalog items. If no libraries are specified this will scan the default classpath.
- This feature will likely be removed.
- Also note that external OSGi dependencies are not supported
- and other metadata (such as versions, etc) may not be applied.
-- `brooklyn.libraries`: a list of pointers to OSGi bundles required for the catalog item.
- This can be omitted if blueprints are pure YAML and everything required is included in the classpath and catalog.
- Where custom Java code or bundled resources is needed, however, OSGi JARs supply
- a convenient packaging format and a very powerful versioning format.
- Libraries should be supplied in the form
- `brooklyn.libraries: [ "http://...", "http://..." ]`,
- or as
- `brooklyn.libraries: [ { name: symbolic-name, version: "1.0", url: http://... }, ... ]` if `symbolic-name:1.0`
- might already be installed from a different URL and you want to skip the download.
- Note that these URLs should point at immutable OSGi bundles;
- if the contents at any of these URLs changes, the behaviour of the blueprint may change
- whenever a bundle is reloaded in a Brooklyn server,
- and if entities have been deployed against that version, their behavior may change in subtle or potentially incompatible ways.
- To avoid this situation, it is highly recommended to use OSGi version stamps as part of the URL.
-- `include`: A URL to another catalog file to include, inheriting the meta from the current hierarchy.
- Libraries defined so far in the meta will be used to load classpath entries. `include` must be used
- when you have sibling properties. If it's the only property it may be skipped by having the URL as the
- value - see `items` example above.
-
-
-#### Catalog YAML Examples
-
-##### A Simple Example
-
-The following example installs the `RiakNode` entity, making it also available as an application template,
-with a nice display name, description, and icon.
-It can be referred in other blueprints to as `datastore:1.0`,
-and its implementation will be the Java class `org.apache.brooklyn.entity.nosql.riak.RiakNode` included with Brooklyn.
-
-~~~ yaml
-brooklyn.catalog:
- id: datastore
- version: "1.0"
- itemType: template
- iconUrl: classpath://org/apache/brooklyn/entity/nosql/riak/riak.png
- name: Datastore (Riak)
- description: Riak is an open-source NoSQL key-value data store.
- item:
- services:
- - type: org.apache.brooklyn.entity.nosql.riak.RiakNode
- name: Riak Node
-~~~
-
-
-##### Multiple Items
-
-This YAML will install three items:
-
-~~~ yaml
-brooklyn.catalog:
- version: "1.1"
- iconUrl: classpath://org/apache/brooklyn/entity/nosql/riak/riak.png
- description: Riak is an open-source NoSQL key-value data store.
- items:
- - id: riak-node
- itemType: entity
- item:
- type: org.apache.brooklyn.entity.nosql.riak.RiakNode
- name: Riak Node
- - id: riak-cluster
- itemType: entity
- item:
- type: org.apache.brooklyn.entity.nosql.riak.RiakCluster
- name: Riak Cluster
- - id: datastore
- name: Datastore (Riak Cluster)
- itemType: template
- item:
- services:
- - type: riak-cluster
- brooklyn.config:
- # the default size is 3 but this can be changed to suit your requirements
- initial.size: 3
- provisioning.properties:
- # you can also define machine specs
- minRam: 8gb
-~~~
-
-The items this will add to the catalog are:
-
-- `riak-node`, as before, but with a different name
-- `riak-cluster` as a convenience short name for the `org.apache.brooklyn.entity.nosql.riak.RiakCluster` class
-- `datastore`, now pointing at the `riak-cluster` blueprint, in SoftLayer and with the given size and machine spec,
- as the default implementation for anyone
- requesting a `datastore` (and if installed atop the previous example, new references to `datastore`
- will access this version because it is a higher number);
- because it is a template, users will have the opportunity to edit the YAML (see below).
- (This must be supplied after `riak-cluster`, because it refers to `riak-cluster`.)
-
-
-#### Locations in the Catalog
-
-In addition to blueprints, locations can be added to the Apache Brooklyn catalog. The example below shows a location for the vagrant configuration used in the [getting started guide]({{ site.path.guide }}/start/blueprints.html), formatted as a catalog entry.
-
-~~~ yaml
-brooklyn.catalog:
- id: vagrant
- version: "1.0"
- itemType: location
- name: Vagrant getting started location
- item:
- type: byon
- brooklyn.config:
- user: vagrant
- password: vagrant
- hosts:
- - 10.10.10.101
- - 10.10.10.102
- - 10.10.10.103
- - 10.10.10.104
-~~~
-
-Once this has been added to the catalog it can be used as a named location in yaml blueprints using:
-
-~~~ yaml
-location: vagrant
-~~~
-
-
-#### Legacy Syntax
-
-The following legacy and experimental syntax is also supported, but deprecated:
-
-~~~ yaml
-<blueprint-definition>
-brooklyn.catalog:
- <catalog-metadata>
-~~~
-
-In this format, the `brooklyn.catalog` block is optional;
-and an `id` in the `<blueprint-definition>` will be used to determine the catalog ID.
-This is primarily supplied for OASIS CAMP 1.1 compatibility,
-where the same YAML blueprint can be POSTed to the catalog endpoint to add to a catalog
-or POSTed to the applications endpoint to deploy an instance.
-(This syntax is discouraged as the latter usage,
-POSTing to the applications endpoint,
-will ignored the `brooklyn.catalog` information;
-this means references to any `item` blocks in the `<catalog-metadata>` will not be resolved,
-and any OSGi `brooklyn.libraries` defined there will not be loaded.)
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/58bb3aa0/guide/blueprints/catalog/templates.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/catalog/templates.md b/guide/blueprints/catalog/templates.md
deleted file mode 100644
index 0a6b60d..0000000
--- a/guide/blueprints/catalog/templates.md
+++ /dev/null
@@ -1,14 +0,0 @@
----
-title: Templates and the Add-Application Wizard
-layout: website-normal
----
-
-### Templates and the Add-Application Wizard
-
-A `template` is a full application. It consists of one or more entities inside an application
-(though this is also composable: it can be used as part of another application).
-When a `template` is added to the catalog, the blueprint will appear in the 'Create Application' dialog
-as shown here:
-
-[](mysql-in-catalog.png)
-
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/58bb3aa0/guide/blueprints/catalog/versioning.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/catalog/versioning.md b/guide/blueprints/catalog/versioning.md
deleted file mode 100644
index 185caf5..0000000
--- a/guide/blueprints/catalog/versioning.md
+++ /dev/null
@@ -1,146 +0,0 @@
----
-title: Versioning
-layout: website-normal
----
-
-Brooklyn supports multiple versions of a type to be installed and used at the same time.
-Versions are a first-class concept and are often prominently displayed in the UI.
-
-In order to do this, Brooklyn requires that the `id:version` string be unique across the catalog:
-it is normally an error to add a type if a type with the same `id:version` is present.
-The exceptions to this are if the definition is identical, or if the `version` is noted as a `SNAPSHOT`.
-In extraordinary circumstances it may be appropriate to delete a given `id:version` definition
-and then add the new one, but this is discouraged and the usual practice is to:
-
-* Use a `-SNAPSHOT` qualifer suffix on your version when developing
-* Increase the version number when making a change to a non-SNAPSHOT type
-
-When adding to the catalog, if no version is supplied, Brooklyn will typically use
-`0.0.0-SNAPSHOT`, and some clients will automatically create and increment the version number
-for the catalog item.
-
-When deploying a blueprint, if a version number is not specified Brooklyn will typically use
-the highest ordered version (see "Ordering" below) in the catalog for the referenced type,
-and will thereafter lock the use of that version in that blueprint.
-(An exception is where types are co-bundled or an explicit search path is defined;
-in the context of evaluating one type, Brooklyn may prefer versions in the same bundle
-or on the search path.)
-
-
-#### Versioning Syntax
-
-Version numbers in Brooklyn are recommended to follow the following syntax:
-
-~~~
-<major> ( "." <minor> ( "." <patch> )? )? ( "-" <qualifier> )?
-~~~
-
-where the `<major>`, `<minor>`, and `<patch>` parts are numbers
-in accordance with [semver](http://semver.org) semantic versioning,
-assumed to be `0` if omitted,
-and an `<qualifier>` is made up of letters, numbers, `"-"` and `"_"`
-in accordance with [OSGi](https://www.osgi.org/release-4-version-4-3-download/)
-(see sections 1.3.2 and 3.2.5).
-
-Examples:
-
-* `1.2`
-* `2.0.0`
-* `3`
-* `2.0.0-SNAPSHOT`
-* `1.10-rc3-20170619`
-
-
-#### Snapshots and Ordering
-
-The string `SNAPSHOT` appearing anywhere in the version indicates a pre-release version;
-if this string is not present the version is treated as a release version.
-
-When taking an ordering, for instance to find the highest version,
-snapshot versions are always considered lower than release versions.
-Next, the natural order is taken on the major, minor, and patch fields.
-Next, a version with no qualifier is considered higher than one with a qualifier.
-Finally, the qualifier is taken in natural order.
-
-The natural order here is defined as
-numeric order for digit sequences (`"9" < "10"`)
-and ASCII-lexicographic comparison elsewhere (`"a" < "b"`),
-which is normally what people will expect for versions
-(`1.9` < `1.10` and `"1.1-rc9-b" < "1.1-rc10-a"`).
-
-Thus the _order_ of the list of examples above is:
-
-* `2.0.0-SNAPSHOT`
-* `1.2`
-* `1.10-rc3-20170619`
-* `2.0.0`
-* `3`
-
-For most practical purposes, `3`, `3.0`, and `3.0.0` are treated as equivalent,
-but if referencing a version you should use the exact version string defined.
-The version `3.0-0` is different, as the `-0` indicates a qualifier, and
-is ordered before a `3.0.0`.
-
-
-#### Advanced: Other Version Syntaxes
-
-Other version syntaxes are supported with the following restrictions:
-
-* Version strings MUST NOT contain a colon character (`:`)
-* Version strings MUST NOT be empty
-* Fragments that do not follow the recommended syntax may be ignored
- when determining version uniqueness
- (e.g. adding both `"1.0.0-v1.1"` and "1.0.0-v1_1" can result in
- one bundle _replacing_ the other rather than both versions being loaded)
-
-This means in practice that almost any common version scheme can be used.
-However the recommended scheme will fit more neatly alongside types from other sources.
-
-Internally when installing bundles, Brooklyn needs to produce OSGi-compliant versions.
-For the recommended syntax, this mapping consists of replacing the first
-occurrence of `"-"` with `"."` and setting `0` values for absent minor and patch versions.
-Thus when looking at the OSGi view, instead of version `1.10-rc3-20170619`
-you will see `1.10.0.rc3-20170619`.
-Apart from the omission of `0` as minor and patch versions,
-this mapping is guaranteed to be one-to-one so no conflicts will occur if the
-recommended syntax is used.
-Bundles `foo:3`, `foo:3.0`, and `foo:3.0.0` would all be installed using OSGi version `3.0.0`,
-and so would conflict and block installation if there is any change
-(and replace if they have a `-SNAPSHOT` qualifier);
-references to bundles can use `3` or `3.0` or `3.0.0`, though as noted above
-types contained within would have to be referenced using the exact version string supplied.
-(If different versions are specified on individual types than for the bundle itself --
-which is not recommended -- then the conversion to OSGi does not apply,
-and the versions are not treated as equal;
-in such edge cases the ordering obeys numeric then ASCII ordering on segments,
-so we have `3` < `3.0` < `3.01` < `3.1` < `3.09` < `3.9` < `3.10`
-and `v-1` < `v.1` < `v_1`.)
-
-If not using the recommended syntax, the mapping proceeds by treating the first dot-separated fragment
-as the qualifer and converts unsupported characters in a qualifier to an underscore;
-thus `1.x` becomes `1.0.0.x`, `v1` becomes `0.0.0.v1`, and `"1.0.0-v1.1"` becomes `"1.0.0.v1_1"`
-hence the bundle replacement noted above.
-
-If you are creating an OSGi `MANIFEST.MF` for a bundle that also contains a `catalog.bom`,
-you will need to use the mapped result (OSGi version syntax) in the manifest,
-but should continue to use the Brooklyn-recommended syntax in the `catalog.bom`.
-
-For those who are curious, the reason for the Brooklyn version syntax is to reconcile
-the popular usage of semver and maven with the internal requirement to use OSGi versions.
-Semver, OSGi, and maven conventions agree on up to three numeric dot-separated tokens,
-but differ quite significantly afterwards, with Brooklyn adopting what seems to be the
-most popular choices in each.
-
-A summary of the main differences between Brooklyn and other versioning syntaxes is as follows:
-
-* Qualifier preceded by hyphen (maven and semver semantics, different to OSGi which wants a dot)
-* Underscores allowed in qualifiers (OSGi and maven semantics, different to semver)
-* Periods and plus not allowed in qualifiers (OSGi semantics and maven convention,
- different to semver which gives them special meaning)
-* The ordering used in Brooklyn is different to that used in OSGi
- (where qualifiers come after the unqualified version and don't do a numeric comparison)
-* `SNAPSHOT` treated specially (maven semantics)
-* Maven's internal to-OSGi conversion is different for some non-recommended syntax strings
- (e.g. `10rc1` becomes `10.0.0.rc1` in Brooklyn but Maven will map it by default to `0.0.0.10rc1`)
-
-