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:47 UTC
[39/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/start/brooklyn.properties
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/start/brooklyn.properties b/brooklyn-docs/guide/start/brooklyn.properties
deleted file mode 100644
index f517556..0000000
--- a/brooklyn-docs/guide/start/brooklyn.properties
+++ /dev/null
@@ -1,337 +0,0 @@
-#
-# Licensed to the Apache Software Foundation (ASF) under one
-# or more contributor license agreements. See the NOTICE file
-# distributed with this work for additional information
-# regarding copyright ownership. The ASF licenses this file
-# to you under the Apache License, Version 2.0 (the
-# "License"); you may not use this file except in compliance
-# with the License. You may obtain a copy of the License at
-#
-# http://www.apache.org/licenses/LICENSE-2.0
-#
-# Unless required by applicable law or agreed to in writing,
-# software distributed under the License is distributed on an
-# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-# KIND, either express or implied. See the License for the
-# specific language governing permissions and limitations
-# under the License.
-#
-# This is Brooklyn's dot-properties file.
-# It should be located at "~/.brooklyn/brooklyn.properties" for automatic loading,
-# or can be specified as a CLI option with --localProperties /path/to/these.properties.
-
-################################## Welcome! ############################################
-
-# It's great to have you here.
-
-# Getting Started options have been pulled to the top. There's a formatting guide at the
-# very bottom.
-
-############################ Getting Started Options ####################################
-
-## GUI Security
-
-## NOTE: in production it is highly recommended to set this, as otherwise it will not require login,
-## not will it be encrypted (though for safety if security is not set it will only bind to loopback)
-
-## Edit the name(s) and passwords as appropriate to your system:
-
-# brooklyn.webconsole.security.users=admin,bob
-# brooklyn.webconsole.security.user.admin.password=password
-# brooklyn.webconsole.security.user.bob.password=bobsword
-
-## If you prefer to run with https (on port 8443 by default), uncomment this:
-
-# brooklyn.webconsole.security.https.required=true
-
-
-# By default we have AWS set up (but with invalid credentials!). Many, many other
-# providers are supported.
-
-## Amazon EC2 Credentials
-# These should be an "Access Key ID" and "Secret Access Key" for your account.
-# This is configured at https://console.aws.amazon.com/iam/home?#security_credential .
-
-brooklyn.location.jclouds.aws-ec2.identity = AKA_YOUR_ACCESS_KEY_ID
-brooklyn.location.jclouds.aws-ec2.credential = <access-key-hex-digits>
-
-# Beware of trailing spaces in your cloud credentials. This will cause unexpected
-# 401: unauthorized responses.
-
-## Using Other Clouds
-# 1. Cast your eyes down this document to find your preferred cloud in the Named Locations
-# section, and the examples.
-# 2. Uncomment the relevant line(s) for your provider.
-# 3. ADD -.identity and -.credential lines for your provider, similar to the AWS ones above,
-# replacing 'aws-ec2' with jcloud's id for your cloud.
-
-
-## Deploying to Localhost
-## see: info on locations at brooklyn.io
-#
-## ~/.ssh/id_rsa is Brooklyn's default location
-# brooklyn.location.localhost.privateKeyFile = ~/.ssh/id_rsa
-## Passphrases are supported, but not required
-# brooklyn.location.localhost.privateKeyPassphrase = s3cr3tpassphrase
-
-## Geoscaling Service - used for the Global Web Fabric demo
-## see: the global web example at brooklyn.io
-## https://www.geoscaling.com/dns2/
-## other services may take similar configuration similarly; or can usually be set in YAML
-# brooklyn.geoscaling.username = USERNAME
-# brooklyn.geoscaling.password = PASSWORD
-# brooklyn.geoscaling.primaryDomain = DOMAIN
-
-
-
-########################## Getting Started Complete! ###################################
-
-# That's it, although you may want to read through these options...
-
-################################ Brooklyn Options ########################################
-
-## Brooklyn Management Base Directory: specify where management data should be stored on this server;
-## ~/.brooklyn/ is the default but you could use something like /opt/brooklyn/state/
-## (provided this process has write permissions)
-# brooklyn.base.dir=~/.brooklyn/
-
-## Brooklyn On-Box Directory: specify where data should be stored on managed hosts;
-## for most locations a directory off home is the default (but using /tmp/brooklyn-user/ on localhost),
-## however you could specify something like /opt/brooklyn-managed-process/ (creation and permissions are handled)
-# onbox.base.dir=~/brooklyn-managed-process/
-
-## Additional security: Allow all - if you know what you are doing!
-## (Or you can also plug in e.g. LDAP security etc here)
-# brooklyn.webconsole.security.provider = org.apache.brooklyn.rest.security.provider.AnyoneSecurityProvider
-
-## Optionally disallow deployment to localhost (or any other location)
-# brooklyn.location.localhost.enabled=false
-
-## Scripting Behaviour
-
-## keep scripts around after running them (usually in /tmp)
-# brooklyn.ssh.config.noDeleteAfterExec = true
-
-## Misc Cloud Settings
-## brooklyn will fail a node if the cloud machine doesn't come up, but you can tell it to retry:
-# brooklyn.location.jclouds.machineCreateAttempts = 3
-## many cloud machines don't have sufficient entropy for lots of encrypted networking, so fake it:
-# brooklyn.location.jclouds.installDevUrandom=true
-
-## Sets a minimium ram property for all jclouds locations. Recommended to avoid getting m1.micros on AWS!
-brooklyn.location.jclouds.minRam = 2048
-
-## When setting up a new cloud machine Brooklyn creates a user with the same name as the user running
-## Brooklyn on the management server, but you can force a different user here:
-# brooklyn.location.jclouds.user=brooklyn
-## And you can force a password or key (by default it will use the keys in ~/.ssh/id_rsa{,.pub}
-# brooklyn.location.jclouds.password=s3cr3t
-
-################################ Named Locations ########################################
-
-# Named locations appear in the web console. If using the command line or YAML it may be
-# just as easy to use the jclouds:<provider> locations and specify additional properties there.
-
-## Example: AWS Virginia using Rightscale 6.3 64bit Centos AMI and Large Instances
-# brooklyn.location.named.aws-va-centos-large = jclouds:aws-ec2:us-east-1
-# brooklyn.location.named.aws-va-centos-large.imageId=us-east-1/ami-7d7bfc14
-# brooklyn.location.named.aws-va-centos-large.user=brooklyn
-# brooklyn.location.named.aws-va-centos-large.minRam=4096
-
-## You can also nest these:
-# brooklyn.location.named.aws-acct-two = jclouds:aws-ec2
-# brooklyn.location.named.aws-acct-two.identity = AKA_ACCT_TWO
-# brooklyn.location.named.aws-acct-two.credential = <access-key-hex-digits>
-# brooklyn.location.named.aws-acct-two-singapore = named:aws-acct-two
-# brooklyn.location.named.aws-acct-two-singapore.region = ap-southeast-1
-# brooklyn.location.named.aws-acct-two-singapore.displayName = AWS Singapore (Acct Two)
-
-# For convenience some common defaults:
-brooklyn.location.named.aws-california = jclouds:aws-ec2:us-west-1
-brooklyn.location.named.aws-oregon = jclouds:aws-ec2:us-west-2
-brooklyn.location.named.aws-ireland = jclouds:aws-ec2:eu-west-1
-brooklyn.location.named.aws-tokyo = jclouds:aws-ec2:ap-northeast-1
-
-## Google Compute
-## The credentials for GCE come from the "APIs & auth -> Credentials" page,
-## creating a "Service Account" of type JSON, then extracting
-## the client_email as the identity and private_key as the identity,
-## keeping new lines as \n (exactly as in the JSON supplied)
-# brooklyn.location.jclouds.google-compute-engine.identity=1234567890-somet1mesArand0mU1Dhere@developer.gserviceaccount.com
-# brooklyn.location.jclouds.google-compute-engine.credential=-----BEGIN PRIVATE KEY----- \nMIIblahablahblah \nblahblahblah \n-----END PRIVATE KEY-----
-# brooklyn.location.named.Google\ US = jclouds:google-compute-engine
-# brooklyn.location.named.Google\ US.region=us-central1-a
-# brooklyn.location.named.Google\ EU = jclouds:google-compute-engine
-# brooklyn.location.named.Google\ EU.region=europe-west1-a
-## the following flags for GCE are recommended
-## specify the network to use - otherwise it creates new networks each time and you hit quotas pretty quickly
-## you may have to manually create this network AND enable a firewall rule EG tcp:1-65535;udp:1-65535;icmp
-## (fix for this is in progress)
-# brooklyn.location.jclouds.google-compute-engine.networkName=brooklyn-default-network
-## gce images have bad entropy, this ensures they have noisy /dev/random (even if the "randomness" is not quite as random)
-# brooklyn.location.jclouds.google-compute-engine.installDevUrandom=true
-## gce images often start with iptables turned on; turn it off unless your blueprints are iptables-aware
-# brooklyn.location.jclouds.google-compute-engine.stopIptables=true
-
-## HP Cloud - also Ubuntu 12.04 LTS
-## You specify your HP Credentials like this:
-# brooklyn.location.jclouds.hpcloud-compute.identity = projectname:username
-# brooklyn.location.jclouds.hpcloud-compute.credential = password
-## where username and password are the same as logging in to the web console, and
-## projectname can be found here: https://account.hpcloud.com/projects
-# brooklyn.location.named.HP\ Cloud\ Arizona-1 = jclouds:hpcloud-compute:az-1.region-a.geo-1
-# brooklyn.location.named.HP\ Cloud\ Arizona-1.imageId = az-1.region-a.geo-1/75845
-# brooklyn.location.named.HP\ Cloud\ Arizona-1.user = ubuntu
-
-## Softlayer - need a key from the gui, under "administrative -> user administration -> api-access
-# brooklyn.location.jclouds.softlayer.identity=username
-# brooklyn.location.jclouds.softlayer.credential=<private-key-hex-digits>
-## locations
-# brooklyn.location.named.Softlayer\ Dallas=jclouds:softlayer:dal05
-# brooklyn.location.named.Softlayer\ Seattle=jclouds:softlayer:sea01
-# brooklyn.location.named.Softlayer\ Washington\ DC=jclouds:softlayer:wdc01
-# brooklyn.location.named.Softlayer\ Singapore\ 1=jclouds:softlayer:sng01
-# brooklyn.location.named.Softlayer\ Amsterdam\ 1=jclouds:softlayer:ams01
-
-
-## Brooklyn uses the jclouds multi-cloud library to access many clouds.
-## http://www.jclouds.org/documentation/reference/supported-providers/
-
-## Templates for many other clouds, but remember to add identity and credentials:
-
-# brooklyn.location.named.Bluelock = jclouds:bluelock-vcloud-zone01
-
-# brooklyn.location.named.CloudSigma\ Nevada = jclouds:cloudsigma-lvs
-# brooklyn.location.named.CloudSigma\ Zurich = jclouds:cloudsigma-zrh
-
-# brooklyn.location.named.ElasticHosts\ London = jclouds:elastichosts-lon-p
-# brooklyn.location.named.ElasticHosts\ Texas = jclouds:elastichosts-sat-p
-
-# brooklyn.location.named.GleSYS = jclouds:glesys
-
-# brooklyn.location.named.Go2Cloud = jclouds:go2cloud-jhb1
-
-# brooklyn.location.named.GoGrid = jclouds:gogrid
-
-# brooklyn.location.named.Green\ House\ Data = jclouds:greenhousedata-element-vcloud
-
-# brooklyn.location.named.Ninefold = jclouds:ninefold-compute
-
-# brooklyn.location.named.OpenHosting = jclouds:openhosting-east1
-
-## Rackspace (Next Gen)
-# brooklyn.location.named.Rackspace\ Chicago\ (ord) = jclouds:rackspace-cloudservers-us:ORD
-# brooklyn.location.named.Rackspace\ Dallas\ (dfw) = jclouds:rackspace-cloudservers-us:DFW
-# brooklyn.location.named.Rackspace\ Hong\ Kong\ (hkg) = jclouds:rackspace-cloudservers-us:HKG
-# brooklyn.location.named.Rackspace\ Northern\ Virginia\ (iad) = jclouds:rackspace-cloudservers-us:IAD
-# brooklyn.location.named.Rackspace\ Sydney\ (syd) = jclouds:rackspace-cloudservers-us:SYD
-
-## For UK you will need a separate account with rackspace.co.uk
-# brooklyn.location.named.Rackspace\ London\ (lon) = jclouds:rackspace-cloudservers-uk:LON
-
-# brooklyn.location.jclouds.rackspace-cloudservers-us.identity = YOUR_USERNAME
-# brooklyn.location.jclouds.rackspace-cloudservers-us.credential = YOUR_API_KEY
-
-## Separate account credentials for the UK
-# brooklyn.location.jclouds.rackspace-cloudservers-uk.identity = YOUR_USERNAME
-# brooklyn.location.jclouds.rackspace-cloudservers-uk.credential = YOUR_API_KEY
-
-## Rackspace (First Gen)
-## If you need to use Rackspace "first gen" API
-## (note the "next gen" api configured above seems to be faster)
-# brooklyn.location.named.Rackspace\ US\ (First Gen) = jclouds:cloudservers-us
-# brooklyn.location.named.Rackspace\ UK\ (First Gen) = jclouds:cloudservers-uk
-
-# brooklyn.location.jclouds.cloudservers-us.identity = YOUR_USERNAME
-# brooklyn.location.jclouds.cloudservers-us.credential = YOUR_API_KEY
-
-## Separate account credentials for the UK
-# brooklyn.location.jclouds.cloudservers-uk.identity = YOUR_USERNAME
-# brooklyn.location.jclouds.cloudservers-uk.credential = YOUR_API_KEY
-
-# brooklyn.location.named.SeverLove = jclouds:serverlove-z1-man
-
-# brooklyn.location.named.SkaliCloud = jclouds:skalicloud-sdg-my
-
-# brooklyn.location.named.Stratogen = jclouds:stratogen-vcloud-mycloud
-
-# brooklyn.location.named.TryStack\ (Openstack) = jclouds:trystack-nova
-
-
-## Production pool of machines for my application (deploy to named:On-Prem\ Iron\ Example)
-# brooklyn.location.named.On-Prem\ Iron\ Example=byon:(hosts="10.9.1.1,10.9.1.2,produser2@10.9.2.{10,11,20-29}")
-# brooklyn.location.named.On-Prem\ Iron\ Example.user=produser1
-# brooklyn.location.named.On-Prem\ Iron\ Example.privateKeyFile=~/.ssh/produser_id_rsa
-# brooklyn.location.named.On-Prem\ Iron\ Example.privateKeyPassphrase=s3cr3tpassphrase
-
-## Various Private Clouds
-
-## Example: OpenStack Nova
-
-## openstack identity and credential are random strings of letters and numbers (TBC - still the case?)
-# brooklyn.location.named.My\ Openstack=jclouds:openstack-nova:https://9.9.9.9:9999/v2.0/
-
-## OpenStack Nova access information can be downloaded from the openstack web interface; for example, as openrc.sh file
-# brooklyn.location.named.My\ Openstack=jclouds:openstack-nova:keystone-url
-# brooklyn.location.named.My\ OpenStack.identity=your-tenant-name:your-user-name
-# brooklyn.location.named.My\ OpenStack.credential=your-password
-# brooklyn.location.named.My\ OpenStack.endpoint=your-keystone-url
-
-## The ID of the image must be configured according to the local OpenStack settings
-## Use the command nova image-list to list all the available images
-## Use the command nova show <image-name> to get more details
-# brooklyn.location.named.My\ OpenStack.imageId=the-region-name/the-image-id
-
-## Virtual Machine flavors must match the ones created upfront according to the local OpenStack settings
-## Use the command nova flavor-list to list all the available options
-## Use the command nova flavor-show <flavor-name> to get more details
-# brooklyn.location.named.My\ OpenStack.hardwareId=the-region-name/the-flavor-id
-
-## (Optional) Configurations
-
-# brooklyn.location.named.My\ OpenStack.user=user-name-inside-the-instance
-
-## The keyPair must by created upfront. Both the following two options are required at the same time.
-# brooklyn.location.named.My\ OpenStack.keyPair=the-key-pair-name
-# brooklyn.location.named.My\ OpenStack.loginUser.privateKeyFile=/path/to/keypair.pem
-
-## Security groups must be created upfront (TBC - How to specify many security groups at one ?)
-# brooklyn.location.named.My\ OpenStack.securityGroups=universal
-
-# brooklyn.location.named.My\ OpenStack.openIptables=true
-# brooklyn.location.named.My\ OpenStack.selinux.disabled=true
-# brooklyn.location.named.My\ OpenStack.auto-create-floating-ips=true
-# brooklyn.location.named.My\ OpenStack.openstack-nova.auto-generate-keypairs=false
-
-## cloudstack identity and credential are rather long random strings of letters and numbers
-## you generate this in the cloudstack gui, under accounts, then "view users", then "generate key"
-## use the "api key" as the identity and "secret key" as the credential
-# brooklyn.location.named.My\ Cloudstack=jclouds:cloudstack:http://9.9.9.9:9999/client/api/
-
-## abiquo identity and credential are your login username/passed
-# brooklyn.location.named.My\ Abiquo=jclouds:abiquo:http://demonstration.abiquo.com/api/
-
-############################### Formatting Guide #######################################
-
-! Both # and ! mark lines as comments
-# The follow syntax are ALL valid.
-# example_key example_value
-# example_key : example_value
-# example_key = example_value
-# example_key=example_value
-
-# The backslash below tells Brooklyn to continue reading the value onto the next line.
-# example_key = A very \
-# long string!
-# Note all white space before 'long...' is ignored. Also '!' is kept as part of the string
-
-
-# Keys with spaces should be escaped with backslashes.
-# This is useful for named locations, as the name displayed in Brooklyn's web
-# interface is derived from the key name.
-# key\ with\ spaces = some\ value
-
-# Encoding for .properties must be ISO-8859-1, aka Latin-1.
-# All non-latin1 characters must be entered using unicode escape characters
-# polish_pangram = P\u00F3jd\u017A\u017Ce, ki\u0144 \
-# t\u0119 chmurno\u015B\u0107 w g\u0142\u0105b flaszy!
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/start/concept-quickstart.md
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/start/concept-quickstart.md b/brooklyn-docs/guide/start/concept-quickstart.md
deleted file mode 100644
index 3f04557..0000000
--- a/brooklyn-docs/guide/start/concept-quickstart.md
+++ /dev/null
@@ -1,33 +0,0 @@
----
-title: Brooklyn Concepts Quickstart
-layout: website-normal
-menu_parent: index.md
----
-
-The following section provides a quick summary of the main Brooklyn concepts you will encounter in Getting Started. For further discussion of these concepts see [The Theory Behind Brooklyn]({{site.path.website}}/learnmore/theory.html), and the detailed descriptions in [Brooklyn Concepts]({{site.path.guide}}/concepts/).
-
-***Deployment and Management*** Brooklyn is built for agile deployment of applications across cloud and other targets, and real-time autonomic management. "Autonomic computing" is the concept of components looking after themselves where possible (self-healing, self-optimizing, etc).
-
-***Blueprints*** A blueprint defines an application by specifying its components, such as processes, or combinations of processes across multiple machines and services. The blueprint also specifies the inter-relationships between the configurations of the components.
-
-***Entities*** The central concept in a Brooklyn deployment is that of an entity. An entity represents a resource under management (individual machines or software processes) or logical collections of these. Entities are arranged hierarchically. They can have events, operations, and processing logic associated with them, and it is through this mechanism that the active management is delivered.
-
-***Applications*** are the top level entities that are the parents of all other entities.
-
-***Configuration*** Entities can have arbitrary configuration values, which get inherited by their child entities. You can set global (Brooklyn-wide) properties in (``~/.brooklyn/brooklyn.properties``). Common configuration keys have convenient aliases called "flags".
-
-***Sensors*** are the mechanism for entities to expose information for other entities to see. Sensors from an entity can be subscribed to by other entities to track changes in the entity’s activity. Sensors can be updated, potentially frequently, by the entity or associated tasks.
-
-***Effectors*** are the mechanism for entities to expose the operations that can be invoked on it by other entities. The invoker is able to track the execution of that effector with tasks.
-
-
-***Lifecycle*** The management context of Brooklyn associates a "lifecycle" with Brooklyn entities. Common operations are start, stop, and restart (whose meaning differs slightly for applications and processes; the details are in the concepts guide linked above). Starting an application results in the start() operation being performed recursively (typically in parallel) on the application's children.
-
-***Tasks*** Lifecycle and other operations in Brooklyn are tracked as tasks. This allows current and past processing to be observed by operators, and processing to be managed across multiple management nodes.
-
-
-***Locations*** can be defined in order to specify where the processes of an application will run. Brooklyn supports different cloud providers and pre-prepared machines (including localhost), known as "BYON" (Bring Your Own Nodes).
-
-***Policies*** Policies perform the active management enabled by Brooklyn. Entities can have Policy instances attached to them, which can subscribe to sensors from other entities or run periodically. When they run they can perform calculations, look up other values, invoke effectors or emit sensor values from the entity with which they are associated.
-
-***Enrichers*** These are mechanisms that subscribe to a sensor, or multiple sensors, and output a new sensor. For example, the enricher which sums a sensor across multiple entities (used to get the total requests-per-second for all the web servers in a cluster), and the enricher which calculates a 60-second rolling average.
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/start/images/add-application-catalog-web-cluster-with-db-large.png
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/start/images/add-application-catalog-web-cluster-with-db-large.png b/brooklyn-docs/guide/start/images/add-application-catalog-web-cluster-with-db-large.png
deleted file mode 100644
index 1e1cf4e..0000000
Binary files a/brooklyn-docs/guide/start/images/add-application-catalog-web-cluster-with-db-large.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/start/images/add-application-catalog-web-cluster-with-db-location-large.png
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/start/images/add-application-catalog-web-cluster-with-db-location-large.png b/brooklyn-docs/guide/start/images/add-application-catalog-web-cluster-with-db-location-large.png
deleted file mode 100644
index 05e9b0c..0000000
Binary files a/brooklyn-docs/guide/start/images/add-application-catalog-web-cluster-with-db-location-large.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/start/images/add-application-catalog-web-cluster-with-db-location.png
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/start/images/add-application-catalog-web-cluster-with-db-location.png b/brooklyn-docs/guide/start/images/add-application-catalog-web-cluster-with-db-location.png
deleted file mode 100644
index c13fdd8..0000000
Binary files a/brooklyn-docs/guide/start/images/add-application-catalog-web-cluster-with-db-location.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/start/images/add-application-catalog-web-cluster-with-db.png
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/start/images/add-application-catalog-web-cluster-with-db.png b/brooklyn-docs/guide/start/images/add-application-catalog-web-cluster-with-db.png
deleted file mode 100644
index 0a7d985..0000000
Binary files a/brooklyn-docs/guide/start/images/add-application-catalog-web-cluster-with-db.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/start/images/add-application-modal-yaml-large.png
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/start/images/add-application-modal-yaml-large.png b/brooklyn-docs/guide/start/images/add-application-modal-yaml-large.png
deleted file mode 100644
index 57c9e5c..0000000
Binary files a/brooklyn-docs/guide/start/images/add-application-modal-yaml-large.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/start/images/add-application-modal-yaml.png
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/start/images/add-application-modal-yaml.png b/brooklyn-docs/guide/start/images/add-application-modal-yaml.png
deleted file mode 100644
index a9b2c35..0000000
Binary files a/brooklyn-docs/guide/start/images/add-application-modal-yaml.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/start/images/my-db-activities-step1-large.png
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/start/images/my-db-activities-step1-large.png b/brooklyn-docs/guide/start/images/my-db-activities-step1-large.png
deleted file mode 100644
index c715ba3..0000000
Binary files a/brooklyn-docs/guide/start/images/my-db-activities-step1-large.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/start/images/my-db-activities-step1.png
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/start/images/my-db-activities-step1.png b/brooklyn-docs/guide/start/images/my-db-activities-step1.png
deleted file mode 100644
index 382a198..0000000
Binary files a/brooklyn-docs/guide/start/images/my-db-activities-step1.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/start/images/my-db-activities-step2-large.png
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/start/images/my-db-activities-step2-large.png b/brooklyn-docs/guide/start/images/my-db-activities-step2-large.png
deleted file mode 100644
index 3a6d1e3..0000000
Binary files a/brooklyn-docs/guide/start/images/my-db-activities-step2-large.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/start/images/my-db-activities-step2.png
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/start/images/my-db-activities-step2.png b/brooklyn-docs/guide/start/images/my-db-activities-step2.png
deleted file mode 100644
index e771a06..0000000
Binary files a/brooklyn-docs/guide/start/images/my-db-activities-step2.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/start/images/my-db-activities-step3-large.png
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/start/images/my-db-activities-step3-large.png b/brooklyn-docs/guide/start/images/my-db-activities-step3-large.png
deleted file mode 100644
index 7f484a2..0000000
Binary files a/brooklyn-docs/guide/start/images/my-db-activities-step3-large.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/start/images/my-db-activities-step3.png
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/start/images/my-db-activities-step3.png b/brooklyn-docs/guide/start/images/my-db-activities-step3.png
deleted file mode 100644
index 0e1b508..0000000
Binary files a/brooklyn-docs/guide/start/images/my-db-activities-step3.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/start/images/my-web-cluster-starting.png
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/start/images/my-web-cluster-starting.png b/brooklyn-docs/guide/start/images/my-web-cluster-starting.png
deleted file mode 100644
index c389b0b..0000000
Binary files a/brooklyn-docs/guide/start/images/my-web-cluster-starting.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/start/images/my-web-cluster-stop-confirm-large.png
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/start/images/my-web-cluster-stop-confirm-large.png b/brooklyn-docs/guide/start/images/my-web-cluster-stop-confirm-large.png
deleted file mode 100644
index c9bdab6..0000000
Binary files a/brooklyn-docs/guide/start/images/my-web-cluster-stop-confirm-large.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/start/images/my-web-cluster-stop-confirm.png
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/start/images/my-web-cluster-stop-confirm.png b/brooklyn-docs/guide/start/images/my-web-cluster-stop-confirm.png
deleted file mode 100644
index 179b00a..0000000
Binary files a/brooklyn-docs/guide/start/images/my-web-cluster-stop-confirm.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/start/images/my-web-large.png
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/start/images/my-web-large.png b/brooklyn-docs/guide/start/images/my-web-large.png
deleted file mode 100644
index 8954441..0000000
Binary files a/brooklyn-docs/guide/start/images/my-web-large.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/start/images/my-web-summary-large.png
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/start/images/my-web-summary-large.png b/brooklyn-docs/guide/start/images/my-web-summary-large.png
deleted file mode 100644
index fc4bffe..0000000
Binary files a/brooklyn-docs/guide/start/images/my-web-summary-large.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/start/images/my-web-summary.png
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/start/images/my-web-summary.png b/brooklyn-docs/guide/start/images/my-web-summary.png
deleted file mode 100644
index e85752f..0000000
Binary files a/brooklyn-docs/guide/start/images/my-web-summary.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/start/images/my-web-validating-app-endpoint-large.png
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/start/images/my-web-validating-app-endpoint-large.png b/brooklyn-docs/guide/start/images/my-web-validating-app-endpoint-large.png
deleted file mode 100644
index 69005c4..0000000
Binary files a/brooklyn-docs/guide/start/images/my-web-validating-app-endpoint-large.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/start/images/my-web-validating-app-endpoint.png
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/start/images/my-web-validating-app-endpoint.png b/brooklyn-docs/guide/start/images/my-web-validating-app-endpoint.png
deleted file mode 100644
index d775717..0000000
Binary files a/brooklyn-docs/guide/start/images/my-web-validating-app-endpoint.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/start/images/my-web.png
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/start/images/my-web.png b/brooklyn-docs/guide/start/images/my-web.png
deleted file mode 100644
index a370606..0000000
Binary files a/brooklyn-docs/guide/start/images/my-web.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/start/index.md
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/start/index.md b/brooklyn-docs/guide/start/index.md
deleted file mode 100644
index ea8c2a3..0000000
--- a/brooklyn-docs/guide/start/index.md
+++ /dev/null
@@ -1,14 +0,0 @@
----
-layout: website-normal
-title: Getting Started
-children:
-- running.md
-- blueprints.md
-- managing.md
-- policies.md
-- concept-quickstart.md
----
-
-{% include list-children.html %}
-
-
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/start/managing.md
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/start/managing.md b/brooklyn-docs/guide/start/managing.md
deleted file mode 100644
index 3724590..0000000
--- a/brooklyn-docs/guide/start/managing.md
+++ /dev/null
@@ -1,494 +0,0 @@
----
-title: Monitoring and Managing Applications
-title_in_menu: Monitoring and Managing Applications
-layout: website-normal
-menu_parent: index.md
-children:
-- { section: Applications }
-- { section: Entities }
-- { section: Sensors }
-- { section: Effectors }
-- { section: Activities }
----
-
-
-
-So far we have gone through Apache Brooklyn's ability to *deploy* an application blueprint to a location, but this just
-the beginning. Next we will outline how to *manage* the application that has been deployed.
-
-## Applications
-
-Having created the application, we can find a summary of all deployed applications using:
-{% highlight bash %}
-$ br application
-{% endhighlight %}
-
-<pre>
- Id Name Status Location
- hTPAF19s Tomcat RUNNING ajVVAhER
-</pre>
-
-```application``` can be shortened to the alias ```app```, for example:
-{% highlight bash %}
-$ br app
-{% endhighlight %}
-<pre>
- Id Name Status Location
- hTPAF19s Tomcat RUNNING ajVVAhER
-</pre>
-
-A full list of abbreviations such as this can be found in the [CLI reference guide](../ops/cli/cli-ref-guide.html#abbreviations){:target="_blank"}.
-
-In the above example the Id `hTPAF19s` and the Name `Tomcat` are shown. You can use either of these handles to monitor and control the application. The Id shown for your application will be different to this but the name should be the same, note that if you are running multiple applications the Name may not be unique.
-
-#### Things we might want to do
-
-<div class="panel-group" id="accordion">
- <div class="panel panel-default">
- <div class="panel-heading">
- <h4 class="panel-title">
- <a data-toggle="collapse" data-parent="#accordion" href="#collapseOne">Get the application details</a>
- </h4>
- </div>
- <div id="collapseOne" class="panel-collapse collapse in">
- <div class="panel-body">
-<p>
-Using the name `Tomcat` we can get the application details:
-</p>
-{% highlight bash %}
-$ br application Tomcat
-{% endhighlight %}
-<pre>
- Id: hTPAF19s
- Name: Tomcat
- Status: RUNNING
- ServiceUp: true
- Type: org.apache.brooklyn.entity.stock.BasicApplication
- CatalogItemId: null
- LocationId: ajVVAhER
- LocationName: FixedListMachineProvisioningLocation:ajVV
- LocationSpec: vagrantbyon
- LocationType: org.apache.brooklyn.location.byon.FixedListMachineProvisioningLocation
-</pre>
- </div>
- </div>
- </div>
- <div class="panel panel-default">
- <div class="panel-heading">
- <h4 class="panel-title">
- <a data-toggle="collapse" data-parent="#accordion" href="#collapseTwo">Explore the hierarchy of all applications</a>
- </h4>
- </div>
- <div id="collapseTwo" class="panel-collapse collapse">
- <div class="panel-body">
-<p>
-We can explore the management hierarchy of all applications, which will show us the entities they are composed of.
-</p>
-{% highlight bash %}
-$ br tree
-{% endhighlight %}
-<pre>
-|- Tomcat
-+- org.apache.brooklyn.entity.stock.BasicApplication
- |- tomcatServer
- +- org.apache.brooklyn.entity.webapp.tomcat.TomcatServer
-</pre>
- </div>
- </div>
- </div>
- <div class="panel panel-default">
- <div class="panel-heading">
- <h4 class="panel-title">
- <a data-toggle="collapse" data-parent="#accordion" href="#collapseThree">View our application's blueprint</a>
- </h4>
- </div>
- <div id="collapseThree" class="panel-collapse collapse">
- <div class="panel-body">
-<p>
-You can view the blueprint for the application again:
-</p>
-{% highlight bash %}
-$ br application Tomcat spec
-{% endhighlight %}
-<pre>
-"name: Tomcat\nlocation:\n mylocation\nservices:\n- serviceType: brooklyn.entity.webapp.tomcat.TomcatServer\n"
-</pre> </div>
- </div>
- </div>
- <div class="panel panel-default">
- <div class="panel-heading">
- <h4 class="panel-title">
- <a data-toggle="collapse" data-parent="#accordion" href="#collapseFour">View our application's configuration</a>
- </h4>
- </div>
- <div id="collapseFour" class="panel-collapse collapse">
- <div class="panel-body">
-<p>
-You can view the configuration of the application:
-</p>
-{% highlight bash %}
-$ br application Tomcat config
-{% endhighlight %}
-<pre>
-Key Value
-camp.template.id l67i25CM
-brooklyn.wrapper_app true
-</pre>
- </div>
- </div>
- </div>
- </div>
-
-## Entities
-
-An *Entity* is Apache Brooklyn's representation of a software package or service which it can control or interact with. All of the entities Apache Brooklyn can use are listed in the __[Brooklyn Catalog](../../website/learnmore/catalog/)__.
-
-To list the entities of the application you can use the `entity` or `ent` command:
-
-{% highlight bash %}
-$ br application Tomcat entity
-{% endhighlight %}
-<pre>
-Id Name Type
-Wx7r1C4e tomcatServer org.apache.brooklyn.entity.webapp.tomcat.TomcatServer
-</pre>
-
-This shows one entity is available: `tomcatServer`. Note that this is the name we gave the entity in the YAML in [Launching from a Blueprint](./blueprints.html#launching-from-a-blueprint) on the previous page.
-
-You can get summary information for this entity by providing its name (or ID).
-
-{% highlight bash %}
-$ br application Tomcat entity tomcatServer
-{% endhighlight %}
-<pre>
-Id: Wx7r1C4e
-Name: tomcatServer
-Status: RUNNING
-ServiceUp: true
-Type: org.apache.brooklyn.entity.webapp.tomcat.TomcatServer
-CatalogItemId: null
-</pre>
-
-Also you can see the configuration of this entity with the ```config``` command.
-
-{% highlight bash %}
-$ br application Tomcat entity tomcatServer config
-{% endhighlight %}
-<pre>
-Key Value
-jmx.agent.mode JMXMP_AND_RMI
-brooklyn.wrapper_app true
-camp.template.id yBcQuFZe
-onbox.base.dir /home/vagrant/brooklyn-managed-processes
-onbox.base.dir.resolved true
-install.unique_label TomcatServer_7.0.65
-</pre>
-
-## Sensors
-
-*Sensors* are properties which show the state of an *entity* and provide a real-time picture of an *entity* within an application.
-
-You can view the sensors available on the application using:
-
-{% highlight bash %}
-$ br application Tomcat sensor
-{% endhighlight %}
-<pre>
-Name Description Value
-service.isUp Whether the service is active and availability (confirmed and monitored) true
-service.notUp.indicators A map of namespaced indicators that the service is not up {}
-service.problems A map of namespaced indicators of problems with a service {}
-service.state Actual lifecycle state of the service "RUNNING"
-service.state.expected Last controlled change to service state, indicating what the expected state should be "running @ 1450356994928 / Thu Dec 17 12:56:34 GMT 2015"
-</pre>
-
-To explore sensors on a specific entity use the `sensor` command with an entity specified:
-
-{% highlight bash %}
-$ br application Tomcat entity tomcatServer sensor
-{% endhighlight %}
-<pre>
-Name Description Value
-download.addon.urls URL patterns for downloading named add-ons (will substitute things like ${version} automatically)
-download.url URL pattern for downloading the installer (will substitute things like ${version} automatically) "http://download.nextag.com/apache/tomcat/tomcat-7/v${version}/bin/apache-tomcat-${version}.tar.gz"
-expandedinstall.dir Directory for installed artifacts (e.g. expanded dir after unpacking .tgz) "/home/vagrant/brooklyn-managed-processes/installs/TomcatServer_7.0.65/apache-tomcat-7.0.65"
-host.address Host IP address "10.10.10.101"
-host.name Host name "10.10.10.101"
-host.sshAddress user@host:port for ssh'ing (or null if inappropriate) "vagrant@10.10.10.101:22"
-host.subnet.address Host address as known internally in the subnet where it is running (if different to host.name) "10.10.10.101"
-host.subnet.hostname Host name as known internally in the subnet where it is running (if different to host.name) "10.10.10.101"
-# etc. etc.
-</pre>
-
-
-To display the value of a selected sensor, give the command the sensor name as an argument
-
-{% highlight bash %}
-$ br application Tomcat entity tomcatServer sensor webapp.url
-{% endhighlight %}
-<pre>
-"http://10.10.10.101:8080/"
-</pre>
-
-
-## Effectors
-
-Effectors are a means by which you can manipulate the entities in an application. You can list the available effectors for your application using:
-
-{% highlight bash %}
-$ br application Tomcat effector
-{% endhighlight %}
-<pre>
-Name Description Parameters
-restart Restart the process/service represented by an entity
-start Start the process/service represented by an entity locations
-stop Stop the process/service represented by an entity
-</pre>
-
-For example, to stop an application, use the ```stop``` effector. This will cleanly shutdown all components in the application and return any cloud machines that were being used.
-Note that the three "lifecycle" related effectors, ```start```, ```stop```, and ```restart```, are common to all applications and software process entities in Brooklyn.
-
-You can list the effectors for a specific entity using the command:
-
-{% highlight bash %}
-$ br application Tomcat entity tomcatServer effector
-{% endhighlight %}
-<pre>
-Name Description Parameters
-deploy Deploys the given artifact, from a source URL, to a given deployment filename/context url,targetName
-populateServiceNotUpDiagnostics Populates the attribute service.notUp.diagnostics, with any available health indicators
-restart Restart the process/service represented by an entity restartChildren,restartMachine
-start Start the process/service represented by an entity locations
-stop Stop the process/service represented by an entity stopProcessMode,stopMachineMode
-undeploy Undeploys the given context/artifact targetName
-</pre>
-
-To view the details for a specific effector, append it's name to the command:
-
-{% highlight bash %}
-$ br application Tomcat entity tomcatServer effector deploy
-{% endhighlight %}
-<pre>
-Name Description Parameters
-deploy Deploys the given artifact, from a source URL, to a given deployment filename/context url,targetName
-</pre>
-
-These effectors can also be invoked by appending ```invoke``` to this command. Some effectors require parameters for their invocation. For example, if we look at the details for ```deploy``` above we can see it requires a url and targetName.
-
-These parameters can be supplied using ```--param parm=value``` or just ```-P parm=value```.
-
-The commands below deploy the Apache Tomcat [hello world example](http://tomcat.apache.org/tomcat-6.0-doc/appdev/index.html){:target="_blank"} to our Tomcat Server. In these commands, a variable is created for the root URL using the appropriate
-sensor and the index page html is displayed.
-
-{% highlight bash %}
-$ br application Tomcat entity tomcatServer effector deploy invoke -P url=https://tomcat.apache.org/tomcat-6.0-doc/appdev/sample/sample.war -P targetName=sample
-$ webapp=$(br application Tomcat entity tomcatServer sensor webapp.url | tr -d '"')
-$ curl $webapp/sample/
-{% endhighlight %}
- <html>
- <head>
- <title>Sample "Hello, World" Application</title>
- </head>
- ...
-
-**Note** that at present a ```tr``` command is required in the second line below to strip quotation characters from the returned sensor value.
-
-## Activities
-
-*Activities* are the actions an application or entity takes within Apache Brooklyn. The ```activity``` command allows us to list out these activities.
-
-To view a list of all activities associated with an entity enter:
-
-{% highlight bash %}
-$ br application Tomcat entity tomcatServer activity
-{% endhighlight %}
-<pre>
-Id Task Submitted Status Streams
-LtD5P1cb start Thu Dec 17 15:04:43 GMT 2015 Completed
-l2qo4vTl provisioning (FixedListMachineProvisi... Thu Dec 17 15:04:43 GMT 2015 Completed
-wLD764HE pre-start Thu Dec 17 15:04:43 GMT 2015 Completed
-KLTxDkoa ssh: initializing on-box base dir ./b... Thu Dec 17 15:04:43 GMT 2015 Completed env,stderr,stdin,stdout
-jwwcJWmF start (processes) Thu Dec 17 15:04:43 GMT 2015 Completed
-...
-</pre>
-
-To view the details of an individual activity, add its ID to the command. In our case this is `jwwcJWmF`
-
-{% highlight bash %}
-$ br application Tomcat entity tomcatServer activity jwwcJWmF
-{% endhighlight %}
-<pre>
-Id: jwwcJWmF
-DisplayName: start (processes)
-Description:
-EntityId: efUvVWAw
-EntityDisplayName: TomcatServer:efUv
-Submitted: Thu Dec 17 15:04:43 GMT 2015
-Started: Thu Dec 17 15:04:43 GMT 2015
-Ended: Thu Dec 17 15:08:59 GMT 2015
-CurrentStatus: Completed
-IsError: false
-IsCancelled: false
-SubmittedByTask: LtD5P1cb
-Streams:
-DetailedStatus: "Completed after 4m 16s
-
-No return value (null)"
-</pre>
-
-
-#### Things we might want to do
-
-<div class="panel-group" id="accordionB">
- <div class="panel panel-default">
- <div class="panel-heading">
- <h4 class="panel-title">
- <a data-toggle="collapse" data-parent="#accordionB" href="#collapseOneB">View Input and Output Streams</a>
- </h4>
- </div>
- <div id="collapseOneB" class="panel-collapse collapse in">
- <div class="panel-body">
-<p>
-If an activity has associated input and output streams, these may be viewed by providing the activity scope and
-using the commands, "env", "stdin", "stdout", and "stderr". For example, for the "initializing on-box base dir"
-activity from the result of the earlier example,
-</p>
-{% highlight bash %}
-$ br application Tomcat entity tomcatServer act KLTxDkoa stdout
-{% endhighlight %}
-<pre>
-BASE_DIR_RESULT:/home/vagrant/brooklyn-managed-processes:BASE_DIR_RESULT
-</pre>
- </div>
- </div>
- </div>
- <div class="panel panel-default">
- <div class="panel-heading">
- <h4 class="panel-title">
- <a data-toggle="collapse" data-parent="#accordionB" href="#collapseTwoB">Monitor the progress of an effector</a>
- </h4>
- </div>
- <div id="collapseTwoB" class="panel-collapse collapse">
- <div class="panel-body">
-
-<p>
-To monitor progress on an application as it deploys, for example, one could use a shell loop:
-</p>
-{% highlight bash %}
-$ while br application Tomcat entity tomcatServer activity | grep 'In progress' ; do
- sleep 1; echo ; date;
-done
-{% endhighlight %}
-<p>
-This loop will exit when the application has deployed successfully or has failed. If it fails then the 'stderr'
-command may provide information about what happened in any activities that have associated streams:
-</p>
-{% highlight bash %}
-$ br application Tomcat entity tomcatServer act KLTxDkoa stderr
-{% endhighlight %}
-
- </div>
- </div>
- </div>
- <div class="panel panel-default">
- <div class="panel-heading">
- <h4 class="panel-title">
- <a data-toggle="collapse" data-parent="#accordionB" href="#collapseThreeB">Diagnose a failure</a>
- </h4>
- </div>
- <div id="collapseThreeB" class="panel-collapse collapse">
- <div class="panel-body">
-
-<p>
-If an activity has failed, the "DetailedStatus" value will help us diagnose what went wrong by showing information about the failure.
-</p>
-{% highlight bash %}
-$ br application evHUlq0n entity tomcatServer activity lZZ9x662
-{% endhighlight %}
-<pre>
-Id: lZZ9x662
-DisplayName: post-start
-Description:
-EntityId: qZeyoITy
-EntityDisplayName: tomcatServer
-Submitted: Mon Jan 25 12:54:55 GMT 2016
-Started: Mon Jan 25 12:54:55 GMT 2016
-Ended: Mon Jan 25 12:59:56 GMT 2016
-CurrentStatus: Failed
-IsError: true
-IsCancelled: false
-SubmittedByTask: hWU7Qvgm
-Streams:
-DetailedStatus: "Failed after 5m: Software process entity TomcatServerImpl{id=qZeyoITy} did not pass is-running check within the required 5m limit (5m elapsed)
-
-java.lang.IllegalStateException: Software process entity TomcatServerImpl{id=qZeyoITy} did not pass is-running check within the required 5m limit (5m elapsed)
- at org.apache.brooklyn.entity.software.base.SoftwareProcessImpl.waitForEntityStart(SoftwareProcessImpl.java:586)
- at org.apache.brooklyn.entity.software.base.SoftwareProcessImpl.postDriverStart(SoftwareProcessImpl.java:260)
- at org.apache.brooklyn.entity.software.base.SoftwareProcessDriverLifecycleEffectorTasks.postStartCustom(SoftwareProcessDriverLifecycleEffectorTasks.java:169)
- at org.apache.brooklyn.entity.software.base.lifecycle.MachineLifecycleEffectorTasks$PostStartTask.run(MachineLifecycleEffectorTasks.java:570)
- at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
- at org.apache.brooklyn.util.core.task.DynamicSequentialTask$DstJob.call(DynamicSequentialTask.java:342)
- at org.apache.brooklyn.util.core.task.BasicExecutionManager$SubmissionCallable.call(BasicExecutionManager.java:468)
- at java.util.concurrent.FutureTask.run(FutureTask.java:266)
- at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
- at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
- at java.lang.Thread.run(Thread.java:745)"
-</pre>
-<p>
-Adding the "--children" or "-c" parameter will show the activity's child activities, to allow the hierarchical structure
-of the activities to be investigated:
-</p>
-{% highlight bash %}
-$ br application Tomcat entity tomcatServer activity -c jwwcJWmF
-{% endhighlight %}
-<pre>
-Id Task Submitted Status
-UpYRc3fw copy-pre-install-resources Thu Dec 17 15:04:43 GMT 2015 Completed
-ig8sBHQr pre-install Thu Dec 17 15:04:43 GMT 2015 Completed
-Elp4HaVj pre-install-command Thu Dec 17 15:04:43 GMT 2015 Completed
-YOvNobJk setup Thu Dec 17 15:04:43 GMT 2015 Completed
-VN3cDKki copy-install-resources Thu Dec 17 15:08:43 GMT 2015 Completed
-xDJXQC0J install Thu Dec 17 15:08:43 GMT 2015 Completed
-zxMDXUxz post-install-command Thu Dec 17 15:08:58 GMT 2015 Completed
-qnQnw7Oc customize Thu Dec 17 15:08:58 GMT 2015 Completed
-ug044ArS copy-runtime-resources Thu Dec 17 15:08:58 GMT 2015 Completed
-STavcRc8 pre-launch-command Thu Dec 17 15:08:58 GMT 2015 Completed
-HKrYfH6h launch Thu Dec 17 15:08:58 GMT 2015 Completed
-T1m8VXbq post-launch-command Thu Dec 17 15:08:59 GMT 2015 Completed
-n8eK5USE post-launch Thu Dec 17 15:08:59 GMT 2015 Completed
-</pre>
-
- </div>
- </div>
- </div>
- </div>
-
-
-{::comment}
-## Scopes in CLI commands
-Many commands require a "scope" expression to indicate the target on which they operate. The scope expressions are
-as follows (values in brackets are aliases for the scope):
-
-- ```application``` APP-ID (app, a)
- Selects an application, e.g. "br application myapp"
-- ```entity``` ENT-ID (ent, e)
- Selects an entity within an application scope, e.g. ```br application myapp entity myserver```
-- ```effector``` EFF-ID (eff, f)
- Selects an effector of an entity or application, e.g. ```br a myapp e myserver eff xyz```
-- ```config``` CONF-KEY (conf, con, c)
- Selects a configuration key of an entity e.g. ```br a myapp e myserver config jmx.agent.mode```
-- ```activity``` ACT-ID (act, v)
- Selects an activity of an entity e.g. ```br a myapp e myserver act iHG7sq1```
-
-For example
-{% highlight bash %}
-$ br application Tomcat entity tomcatServer config
-{% endhighlight %}
-runs the ```config``` command with application scope of ```Tomcat``` and entity scope of ```tomcatServer```.
-
-{:/comment}
-
-## Next
-
-We will look next at a slightly more complex example, which will illustrate the capabilities of Brooklyn's
-**[policies](policies.html)** mechanism, and how to configure dependencies between application entities.
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/start/policies.md
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/start/policies.md b/brooklyn-docs/guide/start/policies.md
deleted file mode 100644
index 2de509b..0000000
--- a/brooklyn-docs/guide/start/policies.md
+++ /dev/null
@@ -1,177 +0,0 @@
----
-title: Getting Started - Policies
-title_in_menu: Policies
-layout: website-normal
-menu_parent: index.md
-children:
-- { section: "A Clustered Example", title_in_menu: "Clustering" }
-- { section: "Configuring Dependencies", title_in_menu: "Dependencies" }
-- { section: "Managing with Policies", title_in_menu: "Policies" }
----
-
-
-
-## A Clustered Example
-
-We'll now look at a more complex example that better shows the capabilities of Brooklyn.
-
-We'll start by deploying an application via YAML blueprint consisting of the following layers.
-
-- A dynamically scalable Web App Cluster
-- A MySQL DB
-
-
-Copy the blueprint below into a text file, "mycluster.yaml", in your workspace, but *before* you create an application
-with it, again modify the YAML to specify the location where the application will be deployed.
-You will need at least five machines for this example, one for the DB, one for the Nginx controller, and three for the tomcats
-(but you can reduce this by changing the "maxPoolSize" below.
-
-{% highlight yaml %}
-name: cluster
-
-location:
- jclouds:aws-ec2:
- identity: ABCDEFGHIJKLMNOPQRST
- credential: s3cr3tsq1rr3ls3cr3tsq1rr3ls3cr3tsq1rr3l
-
-
-services:
-- serviceType: brooklyn.entity.webapp.ControlledDynamicWebAppCluster
- name: webcluster
- brooklyn.config:
- wars.root: http://search.maven.org/remotecontent?filepath=io/brooklyn/example/brooklyn-example-hello-world-sql-webapp/0.6.0-M2/brooklyn-example-hello-world-sql-webapp-0.6.0-M2.war
- http.port: 9280+
- proxy.http.port: 9210+
- java.sysprops:
- brooklyn.example.db.url: $brooklyn:formatString("jdbc:%s%s?user=%s\\&password=%s",
- component("db").attributeWhenReady("datastore.url"), "visitors", "brooklyn", "br00k11n")
- brooklyn.policies:
- - policyType: brooklyn.policy.autoscaling.AutoScalerPolicy
- brooklyn.config:
- metric: $brooklyn:sensor("brooklyn.entity.webapp.DynamicWebAppCluster", "webapp.reqs.perSec.windowed.perNode")
- metricLowerBound: 10
- metricUpperBound: 100
- minPoolSize: 1
- maxPoolSize: 3
-
-- serviceType: brooklyn.entity.database.mysql.MySqlNode
- id: db
- name: mysql
- brooklyn.config:
- creationScriptUrl: https://bit.ly/brooklyn-visitors-creation-script
-{% endhighlight %}
-
-Explore this app using the ```application``` and other commands from the previous section.
-
-## Configuring Dependencies
-The App above illustrates how one component in a blueprint can be configured with information relating to one of the other
-components in the blueprint. In this example the web cluster is configured with a URL for JDBC connections to the database.
-{% highlight yaml %}
-java.sysprops:
- brooklyn.example.db.url: $brooklyn:formatString("jdbc:%s%s?user=%s\\&password=%s",
- component("db").attributeWhenReady("datastore.url"), "visitors", "brooklyn", "br00k11n")
-{% endhighlight %}
-
-the syntax ```$brooklyn:formatString(...)``` is an example of the Brooklyn DSL (Domain Specific Language) which
-allows expressions referring to Brooklyn's management information to be embedded in blueprints. The line above also illustrates the use of Brooklyn's ```component(...)``` and ```attributeWhenReady(...)``` to get an identified component from a deployment, and to wait until the component is fully deployed before reading one of its sensors ("datastore.url" in this case).
-
-## Managing with Policies
-
-
-The app server cluster has an `AutoScalerPolicy`and the loadbalancer has a `Controller targets tracker` policy.
-
-For example
-{% highlight yaml %}
-$ br app cluster ent webcluster policy
-Id Name State
-mMZngBnb org.apache.brooklyn.policy.autoscaling.AutoScalerPolicy RUNNING
-{% endhighlight %}
-
-You can investigate the status of the `AutoScalerPolicy` with its name or, more succinctly, its ID:
-
-{% highlight yaml %}
-$ br app cluster ent webcluster policy mMZngBnb
-"RUNNING"
-{% endhighlight %}
-
-A more detailed description of the parameters of the policy can be obtained with
-{% highlight yaml %}
-$ br app cluster ent webcluster policy org.apache.brooklyn.policy.autoscaling.AutoScalerPolicy
-Name Value Description
-autoscaler.currentSizeOperator org.apache.brooklyn.policy.autoscaling.AutoScalerPolicy$4@9393100
-autoscaler.entityWithMetric The Entity with the metric that will be monitored
-autoscaler.maxPoolSize 4
-autoscaler.maxReachedNotificationDelay 0ms Time that we consistently wanted to go above the maxPoolSize for, after which the maxSizeReachedSensor (if any) will be emitted
-autoscaler.maxSizeReachedSensor Sensor for which a notification will be emitted (on the associated entity) when we consistently wanted to resize the pool above the max allowed size, for maxReachedNotificationDelay milliseconds
-autoscaler.metric Sensor: webapp.reqs.perSec.windowed.perNode (java.lang.Double)
-autoscaler.metricLowerBound 10 The lower bound of the monitored metric. Below this the policy will resize down
-autoscaler.metricUpperBound 100 The upper bound of the monitored metric. Above this the policy will resize up
-autoscaler.minPeriodBetweenExecs 100ms
-autoscaler.minPoolSize 1
-autoscaler.poolColdSensor Sensor: resizablepool.cold (java.util.Map)
-autoscaler.poolHotSensor Sensor: resizablepool.hot (java.util.Map)
-autoscaler.poolOkSensor Sensor: resizablepool.cold (java.util.Map)
-autoscaler.resizeDownIterationIncrement 1 Batch size for resizing down; the size will be decreased by a multiple of this value
-autoscaler.resizeDownIterationMax 2147483647 Maximum change to the size on a single iteration when scaling down
-autoscaler.resizeDownStabilizationDelay 0ms
-autoscaler.resizeOperator org.apache.brooklyn.policy.autoscaling.AutoScalerPolicy$3@387a7e10
-autoscaler.resizeUpIterationIncrement 1 Batch size for resizing up; the size will be increased by a multiple of this value
-autoscaler.resizeUpIterationMax 2147483647 Maximum change to the size on a single iteration when scaling up
-autoscaler.resizeUpStabilizationDelay 0ms
-{% endhighlight %}
-
-
-The loadbalancer's `Controller targets tracker` policy ensures that the loadbalancer is updated as the cluster size changes.
-
-This policy automatically scales the cluster up or down to be the right size for the cluster's current load. One server
-is the minimum size allowed by the policy.
-
-Sitting idle, this cluster will only contain one server, but you can use a tool like [jmeter](http://jmeter.apache.org/)
-pointed at the nginx endpoint to create load on the cluster. Download a jmeter test
-plan [here](https://github.com/apache/incubator-brooklyn/blob/master/examples/simple-web-cluster/resources/jmeter-test-plan.jmx).
-
-As load is added, Apache Brooklyn requests a new cloud machine, creates a new app server, and adds it to the cluster.
-As load is removed, servers are removed from the cluster, and the infrastructure is handed back to the cloud.
-
-
-### Under the Covers
-
-The `AutoScalerPolicy` here is configured to respond to the sensor
-reporting requests per second per node, invoking the default ```resize``` effector.
-By updating on the policy, you can configure it to respond to a much lower threshhold
-or set long stabilization delays (the period before it scales out or back).
-
-At present the CLI does not support a command to update a policy.
-
-However it is possible to manually suspend the policy, by
-
-{% highlight bash %}
-$ br app cluster ent webcluster stop-policy org.apache.brooklyn.policy.autoscaling.AutoScalerPolicy
-
-{% endhighlight %}
-
-You can then invoke a ```resize``` using the appropriate effector:
-{% highlight bash %}
-$ br app cluster ent webcluster effector resize invoke -P desiredSize=3
-{% endhighlight %}
-
-On resize, new nodes are created and configured,
-and in this case a policy on the nginx node reconfigures nginx whenever the set of active
-targets changes.
-
-The policy can then be re-enabled with start-policy:
-
-{% highlight bash %}
-$ br app cluster ent webcluster start-policy org.apache.brooklyn.policy.autoscaling.AutoScalerPolicy
-
-{% endhighlight %}
-
-
-## Next
-
-This guide has given a quick overview to writing blueprints for applications, deploying applications, and
-managing them. Next, learn more about any of:
-
-* [Writing Blueprints with YAML](../yaml/)
-* [Writing Blueprints with Java](../java/)
-* [Operating Brooklyn](../ops/)
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/start/running.md
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/start/running.md b/brooklyn-docs/guide/start/running.md
deleted file mode 100644
index 5da792c..0000000
--- a/brooklyn-docs/guide/start/running.md
+++ /dev/null
@@ -1,135 +0,0 @@
----
-title: Running Apache Brooklyn
-title_in_menu: Running Apache Brooklyn
-layout: website-normal
-menu_parent: index.md
----
-
-This guide will walk you through deploying an example 3-tier web application to a public cloud, and demonstrate the autoscaling capabilities of the Brooklyn platform.
-
-An overview of core [Brooklyn concepts](./concept-quickstart.html){:target="_blank"} is available for reference.
-
-Two methods of deployment are detailed in this tutorial, using virtualisation with Vagrant and a local install. Both assume that you are using Linux or Mac OS X.
-
-## Install Apache Brooklyn
-
-{::options parse_block_html="true" /}
-
-<ul class="nav nav-tabs">
- <li class="active impl-1-tab"><a data-target="#impl-1, .impl-1-tab" data-toggle="tab" href="#">Vagrant</a></li>
- <li class="impl-2-tab"><a data-target="#impl-2, .impl-2-tab" data-toggle="tab" href="#">Local Install</a></li>
-</ul>
-
-<div class="tab-content">
-<div id="impl-1" class="tab-pane fade in active">
-
-[Vagrant](https://www.vagrantup.com/){:target="_blank"} is a software package which automates the process of setting up virtual environments such as [Oracle VirtualBox](https://www.virtualbox.org){:target="_blank"}. We recommend it as
-the easiest way of getting started with Apache Brooklyn.
-
-Firstly, download and install:
-
- * [Vagrant](http://www.vagrantup.com/downloads){:target="_blank"}
- * [Oracle VirtualBox](https://www.virtualbox.org/wiki/Downloads){:target="_blank"}
-
-Then download the default Apache Brooklyn vagrant configuration from [here](https://github.com/johnmccabe/vagrant-brooklyn-getting-started/archive/master.tar.gz){:target="_blank"}. This configuration contains everything you need to get started using Apache Brooklyn.
-
-Extract the `tar.gz` archive and navigate into the expanded `vagrant-brooklyn-getting-started-master` folder
-
-{% highlight bash %}
-$ tar xvf master.tar.gz
-$ cd vagrant-brooklyn-getting-started-master
-{% endhighlight %}
-
-
-</div>
-<div id="impl-2" class="tab-pane fade">
-
-Download the Apache Brooklyn binary distribution as described on [the download page]({{site.path.website}}/download/){:target="_blank"}.
-
-{% if brooklyn_version contains 'SNAPSHOT' %}
-Extract the `tar.gz` archive (note: as this is a -SNAPSHOT version, your filename will be slightly different):
-{% else %}
-Extract the `tar.gz` archive and navigate into the expanded `apache-brooklyn-{{ site.brooklyn-version }}` folder.
-{% endif %}
-
-{% if brooklyn_version contains 'SNAPSHOT' %}
-{% highlight bash %}
-$ tar -zxf apache-brooklyn-dist-{{ site.brooklyn-version }}-timestamp-dist.tar.gz
-$ cd apache-brooklyn-{{ site.brooklyn.version }}
-{% endhighlight %}
-{% else %}
-{% highlight bash %}
-$ tar -zxf apache-brooklyn-{{ site.brooklyn-version }}-dist.tar.gz
-$ cd apache-brooklyn-{{ site.brooklyn.version }}
-{% endhighlight %}
-{% endif %}
-
-**Note**: You'll need a [Java Runtime Environment (JRE)](https://www.java.com){:target="_blank"} installed (version 7 or later), as Brooklyn is Java under the covers.
-
-It is not necessary at this time, but depending on what you are going to do,
-you may wish to set up other configuration options first:
-
-* [Security](../ops/brooklyn_properties.html)
-* [Persistence](../ops/persistence/)
-* [Cloud credentials](../ops/locations/)
-
-</div>
-</div>
-
----
-
-## Launch Apache Brooklyn
-
-<ul class="nav nav-tabs">
- <li class="active impl-1-tab"><a data-target="#impl-1, .impl-1-tab" data-toggle="tab" href="#">Vagrant</a></li>
- <li class="impl-2-tab"><a data-target="#impl-2, .impl-2-tab" data-toggle="tab" href="#">Local Install</a></li>
-</ul>
-
-<div class="tab-content">
-<div id="impl-1" class="tab-pane fade in active">
-
-Now start Apache Brooklyn with the following command:
-
-{% highlight bash %}
-$ vagrant up brooklyn
-{% endhighlight %}
-
-You can see if Apache Brooklyn launched OK by viewing the log files with the command
-
-{% highlight bash %}
-$ vagrant ssh brooklyn --command 'sudo journalctl -n15 -f -u brooklyn'
-{% endhighlight %}
-
-</div>
-<div id="impl-2" class="tab-pane fade">
-
-Now start Apache Brooklyn with the following command:
-
-{% highlight bash %}
-$ bin/brooklyn launch
-{% endhighlight %}
-
-The application should then output it's log into the console
-
-</div>
-</div>
-
----
-
-## Control Apache Brooklyn
-
-Apache Brooklyn has a web console which can be used to control the application. The Brooklyn log will contain the address of the management interface:
-
-<pre>
-INFO Started Brooklyn console at http://127.0.0.1:8081/, running classpath://brooklyn.war
-</pre>
-
-By default it can be accessed by opening [127.0.0.1:8081](http://127.0.0.1:8081){:target="_blank"} in your web browser.
-
-The rest of this getting started guide uses the Apache Brooklyn command line interface (CLI). To use this, download and install the tool as described on the [CLI GitHub page](https://github.com/brooklyncentral/brooklyn-cli){:target="_blank"}.
-
-The CLI provides the command `br`, it's full usage is described in the user manual which can be found [here](../ops/cli/){:target="_blank"}
-
-## Next
-
-The first thing we want to do with Brooklyn is **[deploy a blueprint](blueprints.html)**.
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/advanced-example.md
----------------------------------------------------------------------
diff --git a/brooklyn-docs/guide/yaml/advanced-example.md b/brooklyn-docs/guide/yaml/advanced-example.md
deleted file mode 100644
index 326feb7..0000000
--- a/brooklyn-docs/guide/yaml/advanced-example.md
+++ /dev/null
@@ -1,180 +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.
-
-
-### 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.
-
-#### 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. Clustering is a useful technique that is explained in more depth [here](../clusters.html).
-
-#### 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
-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: |
- $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")
- )
-~~~
-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 then use `$brooklyn:formatString` notation to build the string from configuration. 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: |
- $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"))
-~~~
-There are many different ways to implement this command. For this example, we are querying the REST API to get the status. This command creates a variable called counter, and populates it by performing a `wget` call to the status URL or the Elasticsearch node, grepping for a 200 status OK code. We then check the counter is populated (i.e. that the end point does return status 200) and exit with an error code of one if not.
-
-#### 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.address")
- enricher.targetSensor: $brooklyn:sensor("url.tcp")
- enricher.targetValue: $brooklyn:formatString("%s:%s", $brooklyn:attributeWhenReady("host.address"), $brooklyn:config("elasticsearch.tcp.port"))
-~~~
-
-In this example, we take the host.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.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
- ...
- name: Kibana Server
- customize.latch: $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.
-
-#### 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.