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:44 UTC
[05/25] brooklyn-docs git commit: Delete all the guide files
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/58bb3aa0/guide/ops/configuration/brooklyn_cfg.md
----------------------------------------------------------------------
diff --git a/guide/ops/configuration/brooklyn_cfg.md b/guide/ops/configuration/brooklyn_cfg.md
deleted file mode 100644
index 11af09b..0000000
--- a/guide/ops/configuration/brooklyn_cfg.md
+++ /dev/null
@@ -1,203 +0,0 @@
----
-title: brooklyn.cfg
-layout: website-normal
-children:
-- { section: Quick Setup }
-- { section: Locations }
-- { section: Java }
-- { section: Authentication }
-- { section: Entitlements }
-- { section: HTTPS Configuration }
----
-
-{% include fields.md %}
-
-The file `brooklyn.cfg` is read when Apache Brooklyn starts in order to load any server configuration values. It can be found in the Brooklyn configuration folder. You can check [here](../paths.html) for the location of your Brooklyn configuration folder
-
-## Quick Setup
-
-The most common properties set in this file are for access control. Without this, Brooklyn's
-web-console and REST api will require no authentication.
-
-The simplest way to specify users and passwords is shown below (but see the
-[Authentication](#authentication) section for how to avoid storing passwords in plain text):
-
-{% highlight properties %}
-brooklyn.webconsole.security.users=admin,bob
-brooklyn.webconsole.security.user.admin.password=AdminPassw0rd
-brooklyn.webconsole.security.user.bob.password=BobPassw0rd
-{% endhighlight %}
-
-In many cases, it is preferable instead to use an external credentials store such as LDAP.
-Information on configuring these is [below](#authentication).
-
-If coming over a network it is highly recommended additionally to use `https`.
-This can be configured with:
-
-{% highlight properties %}
-brooklyn.webconsole.security.https.required=true
-{% endhighlight %}
-
-More information, including setting up a certificate, is described [further below](#https-configuration).
-
-
-## Camp YAML Expressions
-
-Values in `brooklyn.cfg` can use the Camp YAML syntax. Any value starting `$brooklyn:` is
-parsed as a Camp YAML expression.
-
-This allows [externalized configuration]({{ site.path.guide }}/ops/externalized-configuration.html) to be used from
-`brooklyn.cfg`. For example:
-
-{% highlight properties %}
-brooklyn.location.jclouds.aws-ec2.identity=$brooklyn:external("vault", "aws-identity")
-brooklyn.location.jclouds.aws-ec2.credential=$brooklyn:external("vault", "aws-credential")
-{% endhighlight %}
-
-If for some reason one requires a literal value that really does start with `$brooklyn:` (i.e.
-for the value to not be parsed), then this can be achieved by using the syntax below. This
-example returns the property value `$brooklyn:myexample`:
-
-{% highlight properties %}
-example.property=$brooklyn:literal("$brooklyn:myexample")
-{% endhighlight %}
-
-
-## Java
-
-Arbitrary data can be set in the `brooklyn.cfg`.
-This can be accessed in java using `ManagementContext.getConfig(KEY)`.
-
-
-## Authentication
-
-**Security Providers** are the mechanism by which different authentication authorities are plugged in to Brooklyn.
-These can be configured by specifying `brooklyn.webconsole.security.provider` equal
-to the name of a class implementing `SecurityProvider`.
-An implementation of this could point to Spring, LDAP, OpenID or another identity management system.
-
-The default implementation, `ExplicitUsersSecurityProvider`, reads from a list of users and passwords
-which should be specified as configuration parameters e.g. in `brooklyn.cfg`.
-This configuration could look like:
-
-{% highlight properties %}
-brooklyn.webconsole.security.users=admin
-brooklyn.webconsole.security.user.admin.salt=OHDf
-brooklyn.webconsole.security.user.admin.sha256=91e16f94509fa8e3dd21c43d69cadfd7da6e7384051b18f168390fe378bb36f9
-{% endhighlight %}
-
-The `users` line should contain a comma-separated list. The special value `*` is accepted to permit all users.
-
-To generate this, the brooklyn CLI can be used:
-
-{% highlight bash %}
-brooklyn generate-password --user admin
-
-Enter password:
-Re-enter password:
-
-Please add the following to your brooklyn.properies:
-
-brooklyn.webconsole.security.users=admin
-brooklyn.webconsole.security.user.admin.salt=OHDf
-brooklyn.webconsole.security.user.admin.sha256=91e16f94509fa8e3dd21c43d69cadfd7da6e7384051b18f168390fe378bb36f9
-{% endhighlight %}
-
-Alternatively, in dev/test environments where a lower level of security is required,
-the syntax `brooklyn.webconsole.security.user.<username>=<password>` can be used for
-each `<username>` specified in the `brooklyn.webconsole.security.users` list.
-
-Other security providers available include:
-
-### No one
-
-`brooklyn.webconsole.security.provider=org.apache.brooklyn.rest.security.provider.BlackholeSecurityProvider`
-will block all logins (e.g. if not using the web console)
-
-### No security
-
-`brooklyn.webconsole.security.provider=org.apache.brooklyn.rest.security.provider.AnyoneSecurityProvider`
-will allow logins with no credentials (e.g. in secure dev/test environments)
-
-### LDAP
-
-`brooklyn.webconsole.security.provider=org.apache.brooklyn.rest.security.provider.LdapSecurityProvider`
-will cause Brooklyn to call to an LDAP server to authenticate users;
-The other things you need to set in `brooklyn.cfg` are:
-
-* `brooklyn.webconsole.security.ldap.url` - ldap connection url
-* `brooklyn.webconsole.security.ldap.realm` - ldap dc parameter (domain)
-* `brooklyn.webconsole.security.ldap.ou` *optional, by default it set to Users* - ldap ou parameter
-
-**brooklyn.cfg example configuration:**
-
-~~~
-brooklyn.webconsole.security.provider=org.apache.brooklyn.rest.security.provider.LdapSecurityProvider
-brooklyn.webconsole.security.ldap.url=ldap://localhost:10389/????X-BIND-USER=uid=admin%2cou=system,X-BIND-PASSWORD=secret,X-COUNT-LIMIT=1000
-brooklyn.webconsole.security.ldap.realm=example.com
-~~~
-
-After you setup the brooklyn connection to your LDAP server, you can authenticate in brooklyn using your cn (e.g. John Smith) and your password.
-`org.apache.brooklyn.rest.security.provider.LdapSecurityProvider` searches in the LDAP tree in LDAP://cn=John Smith,ou=Users,dc=example,dc=com
-
-If you want to customize the ldap path or something else which is particular to your LDAP setup you
-can extend `LdapSecurityProvider` class or implement from scratch the `SecurityProvider` interface.
-
-
-## Entitlements
-
-In addition to login access, fine-grained permissions -- including
-seeing entities, creating applications, seeing sensors, and invoking effectors --
-can be defined on a per-user *and* per-target (e.g. which entity/effector) basis
-using a plug-in **Entitlement Manager**.
-
-This can be set globally with the property:
-
-{% highlight properties %}
-brooklyn.entitlements.global=<class>
-{% endhighlight %}
-
-The default entitlement manager is one which responds to per-user entitlement rules,
-and understands:
-
-* `root`: full access, including to the Groovy console
-* `user`: access to everything but actions that affect the server itself. Such actions include the
- Groovy console, stopping the server and retrieving management context configuration.
-* `readonly`: read-only access to almost all information
-* `minimal`: access only to server stats, for use by monitoring systems
-
-These keywords are also understood at the `global` level, so to grant full access to `admin`,
-read-only access to `support`, limited access to `metrics` and regular access to `user`
-you can write:
-
-{% highlight properties %}
-brooklyn.entitlements.global=user
-brooklyn.entitlements.perUser.admin=root
-brooklyn.entitlements.perUser.support=readonly
-brooklyn.entitlements.perUser.metrics=minimal
-{% endhighlight %}
-
-Under the covers this invokes the `PerUserEntitlementManager`,
-with a `default` set (and if not specified `default` defaults to `minimal`);
-so the above can equivalently be written:
-
-{% highlight properties %}
-brooklyn.entitlements.global=org.apache.brooklyn.core.mgmt.entitlement.PerUserEntitlementManager
-brooklyn.entitlements.perUser.default=user
-brooklyn.entitlements.perUser.admin=root
-brooklyn.entitlements.perUser.support=readonly
-brooklyn.entitlements.perUser.metrics=minimal
-{% endhighlight %}
-
-For more information, see
-[Java: Entitlements]({{ site.path.guide }}/blueprints/java/entitlements.html).
-or
-{% include java_link.html class_name="EntitlementManager" package_path="org/apache/brooklyn/api/mgmt/entitlement" project_subpath="api" %}.
-
-
-
-## HTTPS Configuration
-
-See [HTTPS Configuration](https.html) for general information on configuring HTTPS.
-
-
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/58bb3aa0/guide/ops/configuration/cors.md
----------------------------------------------------------------------
diff --git a/guide/ops/configuration/cors.md b/guide/ops/configuration/cors.md
deleted file mode 100644
index ab2cd05..0000000
--- a/guide/ops/configuration/cors.md
+++ /dev/null
@@ -1,45 +0,0 @@
----
-title: CORS Configuration
-layout: website-normal
----
-
-To enable / configure [cross-origin resource sharing (CORS)](https://en.wikipedia.org/wiki/Cross-origin_resource_sharing).
-The following file must be added to [`org.apache.brooklyn.rest.filter.cors.cfg`](../paths.html)
-
-{% highlight properties %}
-# Enables experimental support for Cross Origin Resource Sharing (CORS) filtering in Apache Brooklyn REST API.
-cors.enabled=true
-
-# @see CrossOriginResourceSharingFilter#setAllowOrigins(List<String>)
-# Coma separated values list of allowed origins. Access-Control-Allow-Origin header will be returned to client if Origin header in request is matching exactly a value among the list allowed origins.
-# If empty or not specified then all origins are allowed. No wildcard allowed origins are supported.
-cors.allow.origins=http://host-one.example.com:8080, http://host-two.example.com, https://host-three.example.com
-
-# @see CrossOriginResourceSharingFilter#setAllowHeaders(List<String>)
-# Coma separated values list of allowed headers for preflight checks.
-#cors.allow.headers=
-
-# @see CrossOriginResourceSharingFilter#setAllowCredentials(boolean)
-# The value for the Access-Control-Allow-Credentials header. If false, no header is added.
-# If true, the header is added with the value 'true'. False by default.
-#cors.allow.credentials=false
-
-# @see CrossOriginResourceSharingFilter#setExposeHeaders(List<String>)
-# CSV list of non-simple headers to be exposed via Access-Control-Expose-Headers.
-#cors.expose.headers=
-
-# @see CrossOriginResourceSharingFilter#setMaxAge(Integer)
-# The value for Access-Control-Max-Age. If -1 then No Access-Control-Max-Age header will be send.
-#cors.max.age=-1
-
-# @see CrossOriginResourceSharingFilter#setPreflightErrorStatus(Integer)
-# Preflight error response status, default is 200.
-cors.preflight.error.status=200
-
-# Do not apply CORS if response is going to be with UNAUTHORIZED status.
-#cors.block.if.unauthorized=false
-{% endhighlight %}
-
-*NOTE*: You must [restart Brooklyn](../starting-stopping-monitoring.html) for these changes to be applied
-
-Further information on client side [usage](https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS)
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/58bb3aa0/guide/ops/configuration/https.md
----------------------------------------------------------------------
diff --git a/guide/ops/configuration/https.md b/guide/ops/configuration/https.md
deleted file mode 100644
index 12515c5..0000000
--- a/guide/ops/configuration/https.md
+++ /dev/null
@@ -1,63 +0,0 @@
----
-title: HTTPS Configuration
-layout: website-normal
----
-
-## Getting the Certificate
-To enable HTTPS web access, you will need a server certificate in a java keystore. To create a self-signed certificate,
-for testing and non-production use, you can use the tool `keytool` from your Java distribution. (A self-signed
-certificate will cause a warning to be displayed by a browser when viewing the page. The various browsers each have
-ways to import the certificate as a trusted one, for test purposes.)
-
-The following command creates a self-signed certificate and adds it to a keystore, `keystore.jks`:
-
-{% highlight bash %}
-% keytool -genkey -keyalg RSA -alias brooklyn \
- -keystore <path-to-keystore-directory>/keystore.jks -storepass "mypassword" \
- -validity 365 -keysize 2048 -keypass "password"
-{% endhighlight %}
-
-The passwords above should be changed to your own values. Omit those arguments above for the tool to prompt you for the values.
-
-You will then be prompted to enter your name and organization details. This will use (or create, if it does not exist)
-a keystore with the password `mypassword` - you should use your own secure password, which will be the same password
-used in your `brooklyn.cfg` (below). You will also need to replace `<path-to-keystore-directory>` with the full
-path of the folder where you wish to store your keystore. The keystore will contain the newly generated key,
-with alias `brooklyn` and password `password`.
-
-For production servers, a valid signed certificate from a trusted certifying authority should be used instead.
-Typically keys from a certifying authority are not provided in Java keystore format. To create a Java keystore from
-existing certificates (CA certificate, and public and private keys), you must first create a PKCS12 keystore from them,
-for example with `openssl`; this can then be converted into a Java keystore with `keytool`. For example, with
-a CA certificate `ca.pem`, and public and private keys `cert.pem` and `key.pem`, create the PKCS12 store `server.p12`,
-and then convert it into a keystore `keystore.jks` as follows:
-
-{% highlight bash %}
-% openssl pkcs12 -export -in cert.pem -inkey key.pem \
- -out server.p12 -name "brooklyn" \
- -CAfile ca.pem -caname root -chain -passout pass:"password"
-
-% keytool -importkeystore \
- -deststorepass "password" -destkeypass "password" -destkeystore keystore.jks \
- -srckeystore server.p12 -srcstoretype PKCS12 -srcstorepass "password" \
- -alias "brooklyn"
-{% endhighlight %}
-
-
-## HTTPS Configuration
-
-In [`org.ops4j.pax.web.cfg`](../paths.html) in the Brooklyn distribution root, un-comment the settings:
-
-{% highlight properties %}
-org.osgi.service.http.port.secure=8443
-org.osgi.service.http.secure.enabled=true
-org.ops4j.pax.web.ssl.keystore=${karaf.home}/etc/keystores/keystore.jks
-org.ops4j.pax.web.ssl.password=password
-org.ops4j.pax.web.ssl.keypassword=password
-org.ops4j.pax.web.ssl.clientauthwanted=false
-org.ops4j.pax.web.ssl.clientauthneeded=false
-{% endhighlight %}
-
-replacing the passwords with appropriate values, and restart the server. Note the keystore location is relative to
-the installation root, but a fully qualified path can also be given, if it is desired to use some separate pre-existing
-store.
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/58bb3aa0/guide/ops/configuration/index.md
----------------------------------------------------------------------
diff --git a/guide/ops/configuration/index.md b/guide/ops/configuration/index.md
deleted file mode 100644
index fde9d89..0000000
--- a/guide/ops/configuration/index.md
+++ /dev/null
@@ -1,143 +0,0 @@
----
-title_in_menu: Configuring Brooklyn
-title: Brooklyn Configuration and Options
-layout: website-normal
-children:
-- { section: Memory Usage }
-- { section: Authentication }
-- brooklyn_cfg.md
-- https.md
-- cors.md
----
-
-Apache Brooklyn contains a number of configuration options managed across several files.
-Historically Brooklyn has been configured through a brooklyn.properties file, this changed
-to a [brooklyn.cfg](brooklyn_cfg.html) file when the Karaf release became the default in Brooklyn 0.12.0.
-
-The configurations for [persistence](../persistence/index.html) and [high availability](../high-availability/index.html) are described
-elsewhere in this manual.
-
-Configuration of Apache Brooklyn when running under Karaf is largely done through standard Karaf mechanisms.
-The Karaf "Configuration Admin" subsystem is used to manage configuration values loaded at first boot from the
-`.cfg` files in the `etc` directory of the distribution. In the Karaf command line these can then be viewed
-and manipulated by the `config:` commands, see the [Karaf documentation](https://karaf.apache.org/manual/latest/) for full details.
-
-## Configuring Brooklyn Properties
-
-To configure the Brooklyn runtime create an `etc/brooklyn.cfg` file. If you have previously used `brooklyn.properties` it follows the same
-file format. Values can be viewed and managed dynamically via the OSGI configuration admin commands in Karaf,
-e.g. `config:property-set`. The global `~/.brooklyn/brooklyn.properties` is still supported and has higher
-priority for duplicate keys, but it's values can't be manipulated with the Karaf commands, so its use is
-discouraged.
-
-You can use the standard `~/.brooklyn/brooklyn.properties` file to configure Brooklyn. Alternatively
-create `etc/brooklyn.cfg` inside the distribution folder (same file format). The keys in the former override
-those in the latter.
-
-Web console related configuration is done through the corresponding Karaf mechanisms:
-
- * The port is set in `etc/org.ops4j.pax.web.cfg`, key `org.osgi.service.http.port`.
- * For authentication the JAAS realm "webconsole" is used; by default it will use any
- SecurityProvider implementations configured in Brooklyn falling back to auto generating
- the password. To configure a custom JAAS realm see the `jetty.xml` file in
- `brooklyn-server/karaf/jetty-config/src/main/resources`
- and override it by creating a custom one in `etc` folder. Point the "webconsole" login service
- to the JAAS realm you would like to use.
- * For other Jetty related configuration consult the Karaf and pax-web docs.
-
-### Memory Usage
-
-The amount of memory required by Apache Brooklyn process depends on the usage - for example the number of entities/VMs under management.
-
-For a standard Brooklyn deployment, the defaults are to start with 256m, and to grow to 2g of memory. These numbers can be overridden
-by setting the `JAVA_MAX_MEM` and `JAVA_MAX_PERM_MEM` in the `bin/setenv` script:
-
- export JAVA_MAX_MEM="2G"
-
-Apache Brooklyn stores a task history in-memory using [soft references](http://docs.oracle.com/javase/7/docs/api/java/lang/ref/SoftReference.html).
-This means that, once the task history is large, Brooklyn will continually use the maximum allocated memory. It will
-only expunge tasks from memory when this space is required for other objects within the Brooklyn process.
-
-### Authentication and Security
-
-There are two areas of authentication used in Apache Brooklyn, these are as follows:
-
-* Karaf authentication
-
-Apache Brooklyn uses [Apache Karaf](https://karaf.apache.org) as a core platform, this has user level security and
-groups which can be configured as detailed [here](https://karaf.apache.org/manual/latest/security#_users_groups_roles_and_passwords).
-
-* Apache Brooklyn authentication
-
-Users and passwords for Brooklyn can be configured in the brooklyn.cfg as detailed [here](brooklyn_cfg.html#authentication).
-
-### HTTPS Configuration
-
-See [HTTPS Configuration](https.html) for general information on configuring HTTPS.
-
-
-<!--
-----------
--- NOTE: comment out this section on catalog as the behaviour described is not enabled by default since
--- https://github.com/apache/brooklyn-server/pull/233; re-enable this when that changes
-----------
-## Catalog in Karaf
-With the traditional launcher, Brooklyn loads the initial contents of the catalog from a `default.catalog.bom` file
-as described in the section on [installation](/guide/ops/production-installation.html). Brooklyn finds Java
-implementations to provide for certain things in blueprints (entities, enrichers etc.) by scanning the classpath.
-
-In the OSGI world this approach is not used, as each bundle only has visibility of its own and its imported Java packages.
-Instead, in Karaf, each bundle can declare its own `catalog.bom` file, in the root of the bundle,
-with the catalog declarations for any entities etc. that the bundle contains.
-
-For example, the `catalog.bom` file for Brooklyn's Webapp bundle looks like (abbreviated):
-
- brooklyn.catalog:
- version: ...
- items:
- - id: org.apache.brooklyn.entity.webapp.nodejs.NodeJsWebAppService
- itemType: entity
- item:
- type: org.apache.brooklyn.entity.webapp.nodejs.NodeJsWebAppService
- name: Node.JS Application
- ...
- - id: resilient-bash-web-cluster-template
- itemType: template
- name: "Template: Resilient Load-Balanced Bash Web Cluster with Sensors"
- description: |
- Sample YAML to provision a cluster of the bash/python web server nodes,
- with sensors configured, and a load balancer pointing at them,
- and resilience policies for node replacement and scaling
- item:
- name: Resilient Load-Balanced Bash Web Cluster (Brooklyn Example)
-
-In the above YAML the first item declares that the bundle provides an entity whose type is
-`org.apache.brooklyn.entity.webapp.nodejs.NodeJsWebAppService`, and whose name is 'Node.JS Application'. The second
-item declares that the bundle provides a template application, with id `resilient-bash-web-cluster-template`, and
-includes a description for what this is.
-
-## Configuring the applications in the Catalog
-
-When running some particular deployment of Brooklyn it may not be desirable for the sample applications to appear in
-the catalog (for clarity, "application" here in the sense of an item with `itemType: template`).
-For example, if you have developed
-some bundle with your own application and added it to Karaf then you might want only your own application to appear in
-the catalog.
-
-Brooklyn contains a mechanism to allow you to configure what bundles will add their applications to the catalog.
-The Karaf configuration file `/etc/org.apache.brooklyn.core.catalog.bomscanner.cfg` contains two properties,
-one `whitelist` and the other `blacklist`, that bundles must satisfy for their applications to be added to the catalog.
-Each property value is a comma-separated list of regular expressions. The symbolic id of the bundle must match one of
-the regular expressions on the whitelist, and not match any expression on the blacklist, if its applications
-are to be added to the bundle. The default values of these properties are to admit all bundles, and forbid none.
-
-## Caveats
-
-In the OSGi world specifying class names by string in Brooklyn's configuration will work only
-for classes living in Brooklyn's core modules. Raise an issue or ping us on IRC if you find
-a case where this doesn't work for you. For custom SecurityProvider implementations refer to the
-documentation of BrooklynLoginModule.
-
- END Catalog in Karaf comment -->
-
-
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/58bb3aa0/guide/ops/externalized-configuration.md
----------------------------------------------------------------------
diff --git a/guide/ops/externalized-configuration.md b/guide/ops/externalized-configuration.md
deleted file mode 100644
index 545b012..0000000
--- a/guide/ops/externalized-configuration.md
+++ /dev/null
@@ -1,270 +0,0 @@
----
-title: Externalized Configuration
-layout: website-normal
----
-
-Sometimes it is useful that configuration in a blueprint, or in Brooklyn itself, is not given explicitly, but is instead
-replaced with a reference to some other storage system. For example, it is undesirable for a blueprint to contain a
-plain-text password for a production system, especially if (as we often recommend) the blueprints are kept in the
-developer's source code control system.
-
-To handle this problem, Apache Brooklyn supports externalized configuration. This allows a blueprint to refer to
-a piece of information that is stored elsewhere. `brooklyn.cfg` defines the external suppliers of configuration
-information. At runtime, when Brooklyn finds a reference to externalized configuration in a blueprint, it consults
-`brooklyn.cfg` for information about the supplier, and then requests that the supplier return the information
-required by the blueprint.
-
-Take, as a simple example, a web app which connects to a database. In development, the developer is running a local
-instance of PostgreSQL with a simple username and password. But in production, an enterprise-grade cluster of PostgreSQL
-is used, and a dedicated service is used to provide passwords. The same blueprint can be used to service both groups
-of users, with `brooklyn.cfg` changing the behaviour depending on the deployment environment.
-
-Here is the blueprint:
-
-{% highlight yaml %}
-name: MyApplication
-services:
-- type: brooklyn.entity.webapp.jboss.JBoss7Server
- name: AppServer HelloWorld
- brooklyn.config:
- wars.root: http://search.maven.org/remotecontent?filepath=org/apache/brooklyn/example/brooklyn-example-hello-world-sql-webapp/0.8.0-incubating/brooklyn-example-hello-world-sql-webapp-0.8.0-incubating.war
- http.port: 8080+
- java.sysprops:
- brooklyn.example.db.url:
- $brooklyn:formatString:
- - jdbc:postgresql://%s/myappdb?user=%s\\&password=%s
- - $brooklyn:external("servers", "postgresql")
- - $brooklyn:external("credentials", "postgresql-user")
- - $brooklyn:external("credentials", "postgresql-password")
-{% endhighlight %}
-
-You can see that when we are building up the JDBC URL, we are using the `external` function. This takes two parameters:
-the first is the name of the configuration supplier, the second is the name of a key that is stored by the configuration
-supplier. In this case we are using two different suppliers: `servers` to store the location of the server, and
-`credentials` which is a security-optimized supplier of secrets.
-
-Developers would add lines like this to the `brooklyn.cfg` file on their workstation:
-
-{% highlight properties %}
-brooklyn.external.servers=org.apache.brooklyn.core.config.external.InPlaceExternalConfigSupplier
-brooklyn.external.servers.postgresql=127.0.0.1
-brooklyn.external.credentials=org.apache.brooklyn.core.config.external.InPlaceExternalConfigSupplier
-brooklyn.external.credentials.postgresql-user=admin
-brooklyn.external.credentials.postgresql-password=admin
-{% endhighlight %}
-
-In this case, all of the required information is included in-line in the local `brooklyn.cfg`.
-
-Whereas in production, `brooklyn.cfg` might look like this:
-
-{% highlight properties %}
-brooklyn.external.servers=org.apache.brooklyn.core.config.external.PropertiesFileExternalConfigSupplier
-brooklyn.external.servers.propertiesUrl=https://ops.example.com/servers.properties
-brooklyn.external.credentials=org.apache.brooklyn.core.config.external.vault.VaultAppIdExternalConfigSupplier
-brooklyn.external.credentials.endpoint=https://vault.example.com
-brooklyn.external.credentials.path=secret/enterprise-postgres
-brooklyn.external.credentials.appId=MyApp
-{% endhighlight %}
-
-In this case, the list of servers is stored in a properties file located on an Operations Department web server, and the
-credentials are stored in an instance of [Vault](https://www.vaultproject.io/).
-More information on these providers is below.
-
-For demo purposes, there is a pre-defined external provider called
-`brooklyn-demo-sample` which defines `hidden-brooklyn-password` as `br00k11n`.
-This is used in some of the sample blueprints, referencing `$brooklyn:external("brooklyn-demo-sample", "hidden-brooklyn-password")`.
-The value used here can be overridden with the following in your `brooklyn.cfg`:
-
-{% highlight properties %}
-brooklyn.external.brooklyn-demo-sample=org.apache.brooklyn.core.config.external.InPlaceExternalConfigSupplier
-brooklyn.external.brooklyn-demo-sample.hidden-brooklyn-password=new_password
-{% endhighlight %}
-
-
-## Defining Suppliers
-
-External configuration suppliers are defined in `brooklyn.cfg`. The minimal definition is of the form:
-
-brooklyn.external.*supplierName* = *className*
-
-This defines a supplier named *supplierName*. Brooklyn will attempt to instantiate *className*; it is this class which
-will provide the behaviour of how to retrieve data from the supplier. Brooklyn includes a number of supplier
-implementations; see below for more details.
-
-Suppliers may require additional configuration options. These are given as additional properties in
-`brooklyn.cfg`:
-
-{% highlight properties %}
-brooklyn.external.supplierName = className
-brooklyn.external.supplierName.firstConfig = value
-brooklyn.external.supplierName.secondConfig = value
-{% endhighlight %}
-
-## Referring to External Configuration in Blueprints
-
-Externalized configuration adds a new function to the Brooklyn blueprint language DSL, `$brooklyn:external`. This
-function takes two parameters:
-
-1. supplier
-2. key
-
-When resolving the external reference, Brooklyn will first identify the *supplier* of the information, then it will
-give the supplier the *key*. The returned value will be substituted into the blueprint.
-
-You can use `$brooklyn:external` directly:
-
-{% highlight yaml %}
-name: MyApplication
-brooklyn.config:
- example: $brooklyn:external("supplier", "key")
-{% endhighlight %}
-
-or embed the `external` function inside another `$brooklyn` DSL function, such as `$brooklyn:formatString`:
-
-{% highlight yaml %}
-name: MyApplication
-brooklyn.config:
- example: $brooklyn:formatString("%s", external("supplier", "key"))
-{% endhighlight %}
-
-
-## Referring to External Configuration in brooklyn.cfg
-
-The same blueprint language DSL can be used from `brooklyn.cfg`. For example:
-
-{% highlight properties %}
-brooklyn.location.jclouds.aws-ec2.identity=$brooklyn:external("mysupplier", "aws-identity")
-brooklyn.location.jclouds.aws-ec2.credential=$brooklyn:external("mysupplier", "aws-credential")
-{% endhighlight %}
-
-
-## Referring to External Configuration in Catalog Items
-
-The same blueprint language DSL can be used within YAML catalog items. For example:
-
- brooklyn.catalog:
- id: com.example.myblueprint
- version: "1.2.3"
- itemType: entity
- brooklyn.libraries:
- - >
- $brooklyn:formatString("https://%s:%s@repo.example.com/libs/myblueprint-1.2.3.jar",
- external("mysupplier", "username"), external("mysupplier", "password"))
- item:
- type: com.example.MyBlueprint
-
-Note the `>` in the example above is used to split across multiple lines.
-
-
-## Suppliers available with Brooklyn
-
-Brooklyn ships with a number of external configuration suppliers ready to use.
-
-### In-place
-
-**InPlaceExternalConfigSupplier** embeds the configuration keys and values as properties inside `brooklyn.cfg`.
-For example:
-
-{% highlight properties %}
-brooklyn.external.servers=org.apache.brooklyn.core.config.external.InPlaceExternalConfigSupplier
-brooklyn.external.servers.postgresql=127.0.0.1
-{% endhighlight %}
-
-Then, a blueprint which referred to `$brooklyn:external("servers", "postgresql")` would receive the value `127.0.0.1`.
-
-### Properties file
-
-**PropertiesFileExternalConfigSupplier** loads a properties file from a URL, and uses the keys and values in this
-file to respond to configuration lookups.
-
-Given this configuration:
-
-{% highlight properties %}
-brooklyn.external.servers=org.apache.brooklyn.core.config.external.PropertiesFileExternalConfigSupplier
-brooklyn.external.servers.propertiesUrl=https://ops.example.com/servers.properties
-{% endhighlight %}
-
-This would cause the supplier to download the given URL. Assuming that the file contained this entry:
-
-{% highlight properties %}
-postgresql=127.0.0.1
-{% endhighlight %}
-
-Then, a blueprint which referred to `$brooklyn:external("servers", "postgresql")` would receive the value `127.0.0.1`.
-
-### Vault
-
-[Vault](https://www.vaultproject.io) is a server-based tool for managing secrets. Brooklyn provides suppliers that are
-able to query the Vault REST API for configuration values. The different suppliers implement alternative authentication
-options that Vault provides.
-
-For *all* of the authentication methods, you must always set these properties in `brooklyn.cfg`:
-
-{% highlight properties %}
-brooklyn.external.supplierName.endpoint=<Vault HTTP/HTTPs endpoint>
-brooklyn.external.supplierName.path=<path to a Vault object>
-{% endhighlight %}
-
-For example, if the path is set to `secret/brooklyn`, then attempting to retrieve the key `foo` would cause Brooklyn
-to retrieve the value of the `foo` key on the `secret/brooklyn` object. This value can be set using the Vault CLI
-like this:
-
-{% highlight bash %}
-vault write secret/brooklyn foo=bar
-{% endhighlight %}
-
-#### Authentication by username and password
-
-The `userpass` plugin for Vault allows authentication with username and password.
-
-{% highlight properties %}
-brooklyn.external.supplierName=org.apache.brooklyn.core.config.external.vault.VaultUserPassExternalConfigSupplier
-brooklyn.external.supplierName.username=fred
-brooklyn.external.supplierName.password=s3kr1t
-{% endhighlight %}
-
-#### Authentication using App ID
-
-The `app_id` plugin for Vault allows you to specify an "app ID", and then designate particular "user IDs" to be part
-of the app. Typically the app ID would be known and shared, but user ID would be autogenerated on the client in some
-way. Brooklyn implements this by determining the MAC address of the server running Brooklyn (expressed as 12 lower
-case hexadecimal digits without separators) and passing this as the user ID.
-
-{% highlight properties %}
-brooklyn.external.supplierName=org.apache.brooklyn.core.config.external.vault.VaultAppIdExternalConfigSupplier
-brooklyn.external.supplierName.appId=MyApp
-{% endhighlight %}
-
-If you do not wish to use the MAC address as the user ID, you can override it with your own choice of user ID:
-
-{% highlight properties %}
-brooklyn.external.supplierName.userId=server3.cluster2.europe
-{% endhighlight %}
-
-#### Authentication by fixed token
-
-If you have a fixed token string, then you can use the *VaultTokenExternalConfigSupplier* class and provide the token
-in `brooklyn.cfg`:
-
-{% highlight properties %}
-brooklyn.external.supplierName=org.apache.brooklyn.core.config.external.vault.VaultTokenExternalConfigSupplier
-brooklyn.external.supplierName.token=1091fc84-70c1-b266-b99f-781684dd0d2b
-{% endhighlight %}
-
-This supplier is suitable for "smoke testing" the Vault supplier using the Initial Root Token or similar. However it
-is not suitable for production use as it is inherently insecure - should the token be compromised, an attacker could
-have complete access to your Vault, and the cleanup operation would be difficult. Instead you should use one of the
-other suppliers.
-
-## Writing Custom External Configuration Suppliers
-
-Supplier implementations must conform to the brooklyn.config.external.ExternalConfigSupplier interface, which is very
-simple:
-
-{% highlight java %}
-String getName();
-String get(String key);
-{% endhighlight %}
-
-Classes implementing this interface can be placed in the `lib/dropins` folder of Brooklyn, and then the supplier
-defined in `brooklyn.cfg` as normal.
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/58bb3aa0/guide/ops/gui/_my-web-cluster.yaml
----------------------------------------------------------------------
diff --git a/guide/ops/gui/_my-web-cluster.yaml b/guide/ops/gui/_my-web-cluster.yaml
deleted file mode 100644
index a00949e..0000000
--- a/guide/ops/gui/_my-web-cluster.yaml
+++ /dev/null
@@ -1,24 +0,0 @@
-name: My Web Cluster
-
-location:
- jclouds:aws-ec2:
- identity: ABCDEFGHIJKLMNOPQRST
- credential: s3cr3tsq1rr3ls3cr3tsq1rr3ls3cr3tsq1rr3l
-
-services:
-- type: org.apache.brooklyn.entity.webapp.ControlledDynamicWebAppCluster
- name: My Web
- id: webappcluster
- brooklyn.config:
- wars.root: http://search.maven.org/remotecontent?filepath=org/apache/brooklyn/example/brooklyn-example-hello-world-sql-webapp/0.8.0-incubating/brooklyn-example-hello-world-sql-webapp-0.8.0-incubating.war
- java.sysprops:
- brooklyn.example.db.url: >
- $brooklyn:formatString("jdbc:%s%s?user=%s&password=%s",
- component("db").attributeWhenReady("datastore.url"),
- "visitors", "brooklyn", $brooklyn:external("brooklyn-demo-sample", "hidden-brooklyn-password"))
-- type: org.apache.brooklyn.entity.database.mysql.MySqlNode
- name: My DB
- id: db
- brooklyn.config:
- creation.script.password: $brooklyn:external("brooklyn-demo-sample", "hidden-brooklyn-password")
- datastore.creation.script.url: https://bit.ly/brooklyn-visitors-creation-script
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/58bb3aa0/guide/ops/gui/_my-web-cluster2.yaml
----------------------------------------------------------------------
diff --git a/guide/ops/gui/_my-web-cluster2.yaml b/guide/ops/gui/_my-web-cluster2.yaml
deleted file mode 100644
index bef8d1a..0000000
--- a/guide/ops/gui/_my-web-cluster2.yaml
+++ /dev/null
@@ -1,32 +0,0 @@
-name: My Web Cluster
-
-location: localhost
-
-services:
-
-- type: org.apache.brooklyn.entity.webapp.ControlledDynamicWebAppCluster
- name: My Web
- brooklyn.config:
- wars.root: http://search.maven.org/remotecontent?filepath=org/apache/brooklyn/example/brooklyn-example-hello-world-sql-webapp/0.8.0-incubating/brooklyn-example-hello-world-sql-webapp-0.8.0-incubating.war
- java.sysprops:
- brooklyn.example.db.url: >
- $brooklyn:formatString("jdbc:%s%s?user=%s&password=%s",
- component("db").attributeWhenReady("datastore.url"),
- "visitors", "brooklyn", $brooklyn:external("brooklyn-demo-sample", "hidden-brooklyn-password"))
- brooklyn.policies:
- - type: org.apache.brooklyn.policy.autoscaling.AutoScalerPolicy
- brooklyn.config:
- metric: webapp.reqs.perSec.windowed.perNode
- metricLowerBound: 0.1
- metricUpperBound: 10
- minPoolSize: 1
- maxPoolSize: 4
- resizeUpStabilizationDelay: 10s
- resizeDownStabilizationDelay: 1m
-
-- type: org.apache.brooklyn.entity.database.mysql.MySqlNode
- id: db
- name: My DB
- brooklyn.config:
- creation.script.password: $brooklyn:external("brooklyn-demo-sample", "hidden-brooklyn-password")
- datastore.creation.script.url: https://bit.ly/brooklyn-visitors-creation-script
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/58bb3aa0/guide/ops/gui/blueprints.md
----------------------------------------------------------------------
diff --git a/guide/ops/gui/blueprints.md b/guide/ops/gui/blueprints.md
deleted file mode 100644
index 8c67f9b..0000000
--- a/guide/ops/gui/blueprints.md
+++ /dev/null
@@ -1,68 +0,0 @@
----
-title: Deploying Blueprints
-layout: website-normal
-menu_parent: index.md
-children:
-- { section: Launching from a Blueprint, title: Launching from a Blueprint }
-- { section: Launching from the Catalog, title: Launching from the Catalog }
----
-
-{% include fields.md %}
-
-
-## Launching from a Blueprint
-
-When you first access the web console on [http://127.0.0.1:8081](http://127.0.0.1:8081) you will be requested to create your first application.
-
-We'll start by deploying an application via a YAML blueprint consisting of the following layers.
-
-- MySQL DB
-- Dynamic web application cluster
- - Nginx load balancer
- - Tomcat app server cluster
-
-[](images/add-application-modal-yaml-large.png)
-
-Switch to the YAML tab and copy the blueprint below into the large text box.
-
-But *before* you submit it, modify the YAML to specify the location where the application will be deployed.
-
-{% highlight yaml %}
-{% readj _my-web-cluster.yaml %}
-{% endhighlight %}
-
-Replace the `location:` element with values for your chosen target environment, for example to use SoftLayer rather than AWS (updating with your own credentials):
-
-{% highlight yaml %}
-location:
- jclouds:softlayer:
- identity: ABCDEFGHIJKLMNOPQRST
- credential: s3cr3tsq1rr3ls3cr3tsq1rr3ls3cr3tsq1rr3l
-{% endhighlight %}
-
-**NOTE**: See __[Locations](../locations)__ in the Operations section of the User Guide for instructions on setting up alternate cloud providers, bring-your-own-nodes, or localhost targets, and storing credentials/locations in a file on disk rather than in the blueprint.
-
-With the modified YAML in the dialog, click "Finish". The dialog will close and Brooklyn will begin deploying your
-application. Your application will be shown as "Starting" on the web console's front page.
-
-[](images/home-app-starting-large.png)
-
-Depending on your choice of location it may take some time for the application nodes to start, the next page describes how you can monitor the progress of the application deployment and verify its successful deployment.
-
-## Launching from the Catalog
-
-Instead of pasting the YAML blueprint each time, it can be added to the Brooklyn Catalog where it will be accessible from the Catalog tab of the Create Application dialog.
-
-[](images/add-application-catalog-web-cluster-with-db-large.png)
-
-<!-- TODO: more detail for adding to catalog? but wait for persistence to be the default,
- rather than extensively document default.catalog.bom.
- also need to include instructions on stopping (currently in help, including stopping apps) -->
-
-See __[Catalog](../catalog/)__ in the Operations section of the User Guide for instructions on creating a new Catalog entry from your Blueprint YAML.
-
-
-## Next
-
-So far we have touched on Brooklyn's ability to *deploy* an application blueprint to a cloud provider.
-The next section will show how to **[Monitor and Manage Applications](managing.html)**.
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/58bb3aa0/guide/ops/gui/images/add-application-catalog-web-cluster-with-db-large.png
----------------------------------------------------------------------
diff --git a/guide/ops/gui/images/add-application-catalog-web-cluster-with-db-large.png b/guide/ops/gui/images/add-application-catalog-web-cluster-with-db-large.png
deleted file mode 100644
index 1e1cf4e..0000000
Binary files a/guide/ops/gui/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/58bb3aa0/guide/ops/gui/images/add-application-catalog-web-cluster-with-db-location-large.png
----------------------------------------------------------------------
diff --git a/guide/ops/gui/images/add-application-catalog-web-cluster-with-db-location-large.png b/guide/ops/gui/images/add-application-catalog-web-cluster-with-db-location-large.png
deleted file mode 100644
index 05e9b0c..0000000
Binary files a/guide/ops/gui/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/58bb3aa0/guide/ops/gui/images/add-application-catalog-web-cluster-with-db-location.png
----------------------------------------------------------------------
diff --git a/guide/ops/gui/images/add-application-catalog-web-cluster-with-db-location.png b/guide/ops/gui/images/add-application-catalog-web-cluster-with-db-location.png
deleted file mode 100644
index c13fdd8..0000000
Binary files a/guide/ops/gui/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/58bb3aa0/guide/ops/gui/images/add-application-catalog-web-cluster-with-db.png
----------------------------------------------------------------------
diff --git a/guide/ops/gui/images/add-application-catalog-web-cluster-with-db.png b/guide/ops/gui/images/add-application-catalog-web-cluster-with-db.png
deleted file mode 100644
index 0a7d985..0000000
Binary files a/guide/ops/gui/images/add-application-catalog-web-cluster-with-db.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/58bb3aa0/guide/ops/gui/images/add-application-modal-yaml-large.png
----------------------------------------------------------------------
diff --git a/guide/ops/gui/images/add-application-modal-yaml-large.png b/guide/ops/gui/images/add-application-modal-yaml-large.png
deleted file mode 100644
index 57c9e5c..0000000
Binary files a/guide/ops/gui/images/add-application-modal-yaml-large.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/58bb3aa0/guide/ops/gui/images/add-application-modal-yaml.png
----------------------------------------------------------------------
diff --git a/guide/ops/gui/images/add-application-modal-yaml.png b/guide/ops/gui/images/add-application-modal-yaml.png
deleted file mode 100644
index a9b2c35..0000000
Binary files a/guide/ops/gui/images/add-application-modal-yaml.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/58bb3aa0/guide/ops/gui/images/home-app-starting-large.png
----------------------------------------------------------------------
diff --git a/guide/ops/gui/images/home-app-starting-large.png b/guide/ops/gui/images/home-app-starting-large.png
deleted file mode 100644
index 5b92e31..0000000
Binary files a/guide/ops/gui/images/home-app-starting-large.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/58bb3aa0/guide/ops/gui/images/home-app-starting.png
----------------------------------------------------------------------
diff --git a/guide/ops/gui/images/home-app-starting.png b/guide/ops/gui/images/home-app-starting.png
deleted file mode 100644
index 5394498..0000000
Binary files a/guide/ops/gui/images/home-app-starting.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/58bb3aa0/guide/ops/gui/images/my-db-activities-step1-large.png
----------------------------------------------------------------------
diff --git a/guide/ops/gui/images/my-db-activities-step1-large.png b/guide/ops/gui/images/my-db-activities-step1-large.png
deleted file mode 100644
index c715ba3..0000000
Binary files a/guide/ops/gui/images/my-db-activities-step1-large.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/58bb3aa0/guide/ops/gui/images/my-db-activities-step1.png
----------------------------------------------------------------------
diff --git a/guide/ops/gui/images/my-db-activities-step1.png b/guide/ops/gui/images/my-db-activities-step1.png
deleted file mode 100644
index 382a198..0000000
Binary files a/guide/ops/gui/images/my-db-activities-step1.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/58bb3aa0/guide/ops/gui/images/my-db-activities-step2-large.png
----------------------------------------------------------------------
diff --git a/guide/ops/gui/images/my-db-activities-step2-large.png b/guide/ops/gui/images/my-db-activities-step2-large.png
deleted file mode 100644
index 3a6d1e3..0000000
Binary files a/guide/ops/gui/images/my-db-activities-step2-large.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/58bb3aa0/guide/ops/gui/images/my-db-activities-step2.png
----------------------------------------------------------------------
diff --git a/guide/ops/gui/images/my-db-activities-step2.png b/guide/ops/gui/images/my-db-activities-step2.png
deleted file mode 100644
index e771a06..0000000
Binary files a/guide/ops/gui/images/my-db-activities-step2.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/58bb3aa0/guide/ops/gui/images/my-db-activities-step3-large.png
----------------------------------------------------------------------
diff --git a/guide/ops/gui/images/my-db-activities-step3-large.png b/guide/ops/gui/images/my-db-activities-step3-large.png
deleted file mode 100644
index 7f484a2..0000000
Binary files a/guide/ops/gui/images/my-db-activities-step3-large.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/58bb3aa0/guide/ops/gui/images/my-db-activities-step3.png
----------------------------------------------------------------------
diff --git a/guide/ops/gui/images/my-db-activities-step3.png b/guide/ops/gui/images/my-db-activities-step3.png
deleted file mode 100644
index 0e1b508..0000000
Binary files a/guide/ops/gui/images/my-db-activities-step3.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/58bb3aa0/guide/ops/gui/images/my-web-cluster-starting.png
----------------------------------------------------------------------
diff --git a/guide/ops/gui/images/my-web-cluster-starting.png b/guide/ops/gui/images/my-web-cluster-starting.png
deleted file mode 100644
index c389b0b..0000000
Binary files a/guide/ops/gui/images/my-web-cluster-starting.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/58bb3aa0/guide/ops/gui/images/my-web-cluster-stop-confirm-large.png
----------------------------------------------------------------------
diff --git a/guide/ops/gui/images/my-web-cluster-stop-confirm-large.png b/guide/ops/gui/images/my-web-cluster-stop-confirm-large.png
deleted file mode 100644
index c9bdab6..0000000
Binary files a/guide/ops/gui/images/my-web-cluster-stop-confirm-large.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/58bb3aa0/guide/ops/gui/images/my-web-cluster-stop-confirm.png
----------------------------------------------------------------------
diff --git a/guide/ops/gui/images/my-web-cluster-stop-confirm.png b/guide/ops/gui/images/my-web-cluster-stop-confirm.png
deleted file mode 100644
index 179b00a..0000000
Binary files a/guide/ops/gui/images/my-web-cluster-stop-confirm.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/58bb3aa0/guide/ops/gui/images/my-web-large.png
----------------------------------------------------------------------
diff --git a/guide/ops/gui/images/my-web-large.png b/guide/ops/gui/images/my-web-large.png
deleted file mode 100644
index 8954441..0000000
Binary files a/guide/ops/gui/images/my-web-large.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/58bb3aa0/guide/ops/gui/images/my-web-summary-large.png
----------------------------------------------------------------------
diff --git a/guide/ops/gui/images/my-web-summary-large.png b/guide/ops/gui/images/my-web-summary-large.png
deleted file mode 100644
index fc4bffe..0000000
Binary files a/guide/ops/gui/images/my-web-summary-large.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/58bb3aa0/guide/ops/gui/images/my-web-summary.png
----------------------------------------------------------------------
diff --git a/guide/ops/gui/images/my-web-summary.png b/guide/ops/gui/images/my-web-summary.png
deleted file mode 100644
index e85752f..0000000
Binary files a/guide/ops/gui/images/my-web-summary.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/58bb3aa0/guide/ops/gui/images/my-web-validating-app-endpoint-large.png
----------------------------------------------------------------------
diff --git a/guide/ops/gui/images/my-web-validating-app-endpoint-large.png b/guide/ops/gui/images/my-web-validating-app-endpoint-large.png
deleted file mode 100644
index 69005c4..0000000
Binary files a/guide/ops/gui/images/my-web-validating-app-endpoint-large.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/58bb3aa0/guide/ops/gui/images/my-web-validating-app-endpoint.png
----------------------------------------------------------------------
diff --git a/guide/ops/gui/images/my-web-validating-app-endpoint.png b/guide/ops/gui/images/my-web-validating-app-endpoint.png
deleted file mode 100644
index d775717..0000000
Binary files a/guide/ops/gui/images/my-web-validating-app-endpoint.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/58bb3aa0/guide/ops/gui/images/my-web.png
----------------------------------------------------------------------
diff --git a/guide/ops/gui/images/my-web.png b/guide/ops/gui/images/my-web.png
deleted file mode 100644
index a370606..0000000
Binary files a/guide/ops/gui/images/my-web.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/58bb3aa0/guide/ops/gui/index.md
----------------------------------------------------------------------
diff --git a/guide/ops/gui/index.md b/guide/ops/gui/index.md
deleted file mode 100644
index 48bd620..0000000
--- a/guide/ops/gui/index.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-layout: website-normal
-title: GUI Guide
-children:
-- running.md
-- blueprints.md
-- managing.md
-- policies.md
----
-
-{% include list-children.html %}
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/58bb3aa0/guide/ops/gui/managing.md
----------------------------------------------------------------------
diff --git a/guide/ops/gui/managing.md b/guide/ops/gui/managing.md
deleted file mode 100644
index a972622..0000000
--- a/guide/ops/gui/managing.md
+++ /dev/null
@@ -1,70 +0,0 @@
----
-title: Monitoring and Managing Applications
-title_in_menu: Monitoring and Managing Applications
-layout: website-normal
-menu_parent: index.md
----
-
-From the Home page, click on the application name or open the Applications tab.
-
-We can explore the management hierarchy of the application, which will show us the entities it is composed of. Starting from the application use the arrows to expand out the list of entities, or hover over the arrow until a menu popup is displayed so that you can select `Expand All`.
-
- * My Web Cluster (A `BasicApplication`)
- * My DB (A `MySqlNode`)
- * My Web (A `ControlledDynamicWebAppCluster`)
- * Cluster of TomcatServer (A `DynamicWebAppCluster`)
- * quarantine (A `QuarantineGroup`)
- * TomcatServer (A `TomcatServer`)
- * NginxController (An `NginxController`)
-
-Clicking on the "My Web Cluster" entity will show the "Summary" tab,
-giving a very high level of what that component is doing.
-Click on each of the child components in turn for more detail on that component.
-Note that the cluster of web servers includes a "quarantine group", to which members of the
-cluster that fail will be added. These are excluded from the load-balancer's targets.
-
-[](images/my-web-large.png)
-
-
-## Activities
-
-The Activity tab allows us to drill down into the tasks each entity is currently executing or has recently completed. It is possible to drill down through all child tasks, and view the commands issued, along with any errors or warnings that occurred.
-
-For example clicking on the NginxController in the left hand tree and opening its Activity tab you can observe the 'start' task is 'In progress'.
-
-**Note**: You may observe different tasks depending on how far your deployment has progressed).
-
-[](images/my-db-activities-step1-large.png)
-
-Clicking on the 'start' task you can discover more details on the actions being carried out by that task (a task may consist of additional subtasks).
-
-[](images/my-db-activities-step2-large.png)
-
-Continuing to drill down into the 'In progress' tasks you will eventually reach the currently active task where you can investigate the ssh command executed on the target node including the current stdin, stdout and stderr output.
-
-[](images/my-db-activities-step3-large.png)
-
-
-## Sensors
-
-Now click on the "Sensors" tab:
-these data feeds drive the real-time picture of the application.
-As you navigate in the tree at the left, you can see more targeted statistics coming in in real-time.
-
-Explore the sensors and the tree to find the URL where the _NginxController_ for the webapp we just deployed is running. This can be found in '**My Web Cluster** -> **My Web** -> **NginxController** -> **_main.uri_**'.
-
-Quickly return to the **‘Brooklyn JS REST client’** web browser
-tab showing the "Sensors" and observe the '**My Web Cluster** -> **My Web** -> **Cluster of TomcatServer** -> **_webapp.reqs.perSec.last_**' sensor value increase.
-
-
-
-## Stopping the Application
-
-To stop an application, select the application in the tree view (the top/root entity), click on the Effectors tab, and invoke the "Stop" effector. This will cleanly shutdown all components in the application and return any cloud machines that were being used.
-
-[](images/my-web-cluster-stop-confirm-large.png)
-
-
-## Next
-
-Brooklyn's real power is in using **[Policies](policies.html)** to automatically *manage* applications.
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/58bb3aa0/guide/ops/gui/policies.md
----------------------------------------------------------------------
diff --git a/guide/ops/gui/policies.md b/guide/ops/gui/policies.md
deleted file mode 100644
index eec033a..0000000
--- a/guide/ops/gui/policies.md
+++ /dev/null
@@ -1,49 +0,0 @@
----
-title: Using Policies
-title_in_menu: Using Policies
-layout: website-normal
----
-
-## Exploring and Testing Policies
-
-To see an example of policy based management, please deploy the following blueprint (changing
-the location details as for the example shown earlier):
-
-{% highlight yaml %}
-{% readj _my-web-cluster2.yaml %}
-{% endhighlight %}
-
-The app server cluster has an `AutoScalerPolicy`, and the loadbalancer has a `targets` policy.
-
-Use the Applications tab in the web console to drill down into the Policies section of the ControlledDynamicWebAppCluster. You will see that the `AutoScalerPolicy` is running.
-
-
-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.
-
-The loadbalancer's `targets` policy ensures that the loadbalancer is updated as the cluster size changes.
-
-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/brooklyn-library/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 clicking 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).
-
-An even simpler test is to manually suspend the policy, by clicking "Suspend" in the policies list.
-You can then switch to the "Effectors" tab and manually trigger a `resize`.
-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.
-
-
-## Next
-
-This guide has given a quick overview of using the Apache Brooklyn GUI to deploy, monitor and manage applications. The GUI also allows you to perform various Advanced management tasks and to explore and use the REST API (from the Script tab). Please take some time now to become more familiar with the GUI.
-
-Then continue to read through the [Operations Guide](../).
-
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/58bb3aa0/guide/ops/gui/running.md
----------------------------------------------------------------------
diff --git a/guide/ops/gui/running.md b/guide/ops/gui/running.md
deleted file mode 100644
index b94f152..0000000
--- a/guide/ops/gui/running.md
+++ /dev/null
@@ -1,54 +0,0 @@
----
-title: Launching
-title_in_menu: Launching
-layout: website-normal
-menu_parent: index.md
----
-
-This guide will walk you through connecting to the Brooklyn Server Graphical User Interface and performing various tasks.
-
-For an explanation of common Brooklyn Concepts see the [Brooklyn Concepts Quickstart](../../start/concept-quickstart.html) or see the full guide in the [Brooklyn Concepts](../../concepts) chapter of the [User Guide](../../).
-
-This guide assumes that you are using Linux or Mac OS X and that Brooklyn Server will be running on your local system.
-
-## Launch Apache Brooklyn
-
-If you haven't already done so, you will need to start Brooklyn Server using the commands shown below.
-It is not necessary at this time, but depending on what you are going to do,
-you may wish to set up some other configuration options first,
-
-* [Security]({{ site.path.guide }}/ops/configuration/brooklyn_cfg.html)
-* [Persistence]({{ site.path.guide }}/ops/persistence/)
-
-Now start Brooklyn with the following command:
-
-{% highlight bash %}
-$ cd apache-brooklyn-{{ site.brooklyn.version }}
-$ bin/brooklyn launch
-{% endhighlight %}
-
-Please refer to the [Server CLI Reference](../server-cli-reference.html) for details of other possible command line options.
-
-Brooklyn will output the address of the management interface:
-
-<pre>
-INFO Starting Brooklyn web-console with no security options (defaulting to no authentication), on bind address <any>
-INFO Started Brooklyn console at http://127.0.0.1:8081/, running classpath://brooklyn.war@
-INFO Persistence disabled
-INFO High availability disabled
-INFO Launched Brooklyn; will now block until shutdown command received via GUI/API (recommended) or process interrupt.
-</pre>
-
-_Notice! Before launching Apache Brooklyn, please check the `date` on the local machine.
-Even several minutes before or after the actual time could cause problems._
-
-## Connect with Browser
-
-Next, open the web console on [http://127.0.0.1:8081](http://127.0.0.1:8081).
-No applications have been deployed yet, so the "Create Application" dialog opens automatically.
-
-[](images/add-application-catalog-web-cluster-with-db-large.png)
-
-
-## Next
-The next section will show how to **[deploy a blueprint](blueprints.html)**.
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/58bb3aa0/guide/ops/high-availability/high-availability-supplemental.md
----------------------------------------------------------------------
diff --git a/guide/ops/high-availability/high-availability-supplemental.md b/guide/ops/high-availability/high-availability-supplemental.md
deleted file mode 100644
index 8cd564b..0000000
--- a/guide/ops/high-availability/high-availability-supplemental.md
+++ /dev/null
@@ -1,168 +0,0 @@
----
-title: Configuring HA - an example
-layout: website-normal
----
-
-This supplements the [High Availability](./) documentation
-and provides an example of how to configure a pair of Apache Brooklyn servers to run in master-standby mode with a shared NFS datastore
-
-### Prerequisites
-- Two VMs (or physical machines) have been provisioned
-- NFS or another suitable file system has been configured and is available to both VMs*
-- An NFS folder has been mounted on both VMs at `/mnt/brooklyn-persistence` and both machines can write to the folder
-
-\* Brooklyn can be configured to use either an object store such as S3, or a shared NFS mount. The recommended option is to use an object
-store as described in the [Object Store Persistence](../persistence/#object-store-persistence) documentation. For simplicity, a shared NFS folder
-is assumed in this example
-
-### Launching
-To start, download and install the latest Apache Brooklyn release on both VMs following the instructions in
-[Running Apache Brooklyn]({{ site.path.guide }}/start/running.html)
-
-On the first VM, which will be the master node, set the following configuration options in [`org.apache.brooklyn.osgilauncher.cfg`](../paths.html):
-
-- highAvailabilityMode: MASTER
-- persistMode: AUTO
-- persistenceDir: /mnt/brooklyn-persistence
-
-Then launch Brooklyn with:
-
-{% highlight bash %}
-$ bin/start
-{% endhighlight %}
-
-If you are using RPMs/deb to install, please see the [Running Apache Brooklyn]({{ site.path.guide }}/start/running.html)
-documentation for the appropriate launch commands
-
-Once Brooklyn has launched, on the second VM, set the following configuration options in [`org.apache.brooklyn.osgilauncher.cfg`](../paths.html):
-
-- highAvailabilityMode: AUTO
-- persistMode: AUTO
-- persistenceDir: /mnt/brooklyn-persistence
-
-Then launch the standby Brooklyn with:
-
-{% highlight bash %}
-$ bin/start
-{% endhighlight %}
-
-### Failover
-When running as a HA standby node, each standby Brooklyn server (in this case there is only one standby) will check the shared persisted state
-every one second to determine the state of the HA master. If no heartbeat has been recorded for 30 seconds, then an election will be performed
-and one of the standby nodes will be promoted to master. At this point all requests should be directed to the new master node.
-If the master is terminated gracefully, the secondary will be immediately promoted to mater. Otherwise, the secondary will be promoted after
-heartbeats are missed for a given length of time. This defaults to 30 seconds, and is configured in `brooklyn.cfg` using
-`brooklyn.ha.heartbeatTimeout`
-
-In the event that tasks - such as the provisioning of a new entity - are running when a failover occurs, the new master will display the current
-state of the entity, but will not resume its provisioning or re-run any partially completed tasks. In this case it may be necessary
-to remove the entity and reprovision it. In the case of a failover whilst executing a task called by an effector, it may be possible to simple
-call the effector again
-
-### Client Configuration
-It is the responsibility of the client to connect to the master Brooklyn server. This can be accomplished in a variety of ways:
-
-* ###Reverse Proxy
-
- To allow the client application to automatically fail over in the event of a master server becoming unavailable, or the promotion of a new master,
- a reverse proxy can be configured to route traffic depending on the response returned by `https://<ip-address>:8443/v1/server/ha/state` (see above).
- If a server returns `"MASTER"`, then traffic should be routed to that server, otherwise it should not be. The client software should be configured
- to connect to the reverse proxy server and no action is required by the client in the event of a failover. It can take up to 30 seconds for the
- standby to be promoted, so the reverse proxy should retry for at least this period, or the failover time should be reconfigured to be shorter
-
-* ###Re-allocating an Elastic IP on Failover
-
- If the cloud provider you are using supports Elastic or Floating IPs, then the IP address should be allocated to the HA master, and the client
- application configured to connect to the floating IP address. In the event of a failure of the master node, the standby node will automatically
- be promoted to master, and the floating IP will need to be manually re-allocated to the new master node. No action is required by the client
- in the event of a failover. It is possible to automate the re-allocation of the floating IP if the Brooklyn servers are deployed and managed
- by Brooklyn using the entity `org.apache.brooklyn.entity.brooklynnode.BrooklynCluster`
-
-* ###Client-based failover
-
- In this scenario, the responsibilty for determining the Brooklyn master server falls on the client application. When configuring the client
- application, a list of all servers in the cluster is passed in at application startup. On first connection, the client application connects to
- any of the members of the cluster to retrieve the HA states (see above). The JSON object returned is used to determine the addresses of all
- members of the cluster, and also to determine which node is the HA master
-
- In the event of a failure of the master node, the client application should then retrieve the HA states of the cluster from any of the other cluster
- members. This is the same process as when the application first connects to the cluster. The client should refresh its list of cluster memebers
- and determine which node is the HA master
-
- It is also recommended that the client application periodically checks the status of the cluster and updates its list of addresses. This will
- ensure that failover is still possible if the standby server(s) has been replaced. It also allows additional standby servers to be added at any
- time
-
-### Testing
-You can confirm that Brooklyn is running in high availibility mode on the master by logging into the web console at `https://<ip-address>:8443`.
-Similarly you can log into the web console on the standby VM where you will see a warning that the server is not the high availability master.
-
-To test a failover, you can simply terminate the process on the first VM and log into the web console on the second VM. Upon launch, Brooklyn will
-output its PID to the file `pid.txt`; you can force an immediate (non-graceful) termination of the process by running the following command
-from the same directory from which you launched Brooklyn:
-
-{% highlight bash %}
-$ kill -9 $(cat pid.txt)
-{% endhighlight %}
-
-It is also possiblity to check the high availability state of a running Brooklyn server using the following curl command:
-
-{% highlight bash %}
-$ curl -k -u myusername:mypassword https://<ip-address>:8443/v1/server/ha/state
-{% endhighlight %}
-
-This will return one of the following states:
-
-{% highlight bash %}
-
-"INITIALIZING"
-"STANDBY"
-"HOT_STANDBY"
-"HOT_BACKUP"
-"MASTER"
-"FAILED"
-"TERMINATED"
-
-{% endhighlight %}
-
-Note: The quotation characters will be included in the reply
-
-To obtain information about all of the nodes in the cluster, run the following command against any of the nodes in the cluster:
-
-{% highlight bash %}
-$ curl -k -u myusername:mypassword https://<ip-address>:8443/v1/server/ha/states
-{% endhighlight %}
-
-This will return a JSON document describing the Brooklyn nodes in the cluster. An example of two HA Brooklyn nodes is as follows (whitespace formatting has been
-added for clarity):
-
-{% highlight yaml %}
-
-{
- ownId: "XkJeXUXE",
- masterId: "yAVz0fzo",
- nodes: {
- yAVz0fzo: {
- nodeId: "yAVz0fzo",
- nodeUri: "https://<server1-ip-address>:8443/",
- status: "MASTER",
- localTimestamp: 1466414301065,
- remoteTimestamp: 1466414301000
- },
- XkJeXUXE: {
- nodeId: "XkJeXUXE",
- nodeUri: "https://<server2-ip-address>:8443/",
- status: "STANDBY",
- localTimestamp: 1466414301066,
- remoteTimestamp: 1466414301000
- }
- },
- links: { }
-}
-
-{% endhighlight %}
-
-The examples above show how to use `curl` to manually check the status of Brooklyn via its REST API. The same REST API calls can also be used by
-automated third party monitoring tools such as Nagios
-
-
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/58bb3aa0/guide/ops/high-availability/index.md
----------------------------------------------------------------------
diff --git a/guide/ops/high-availability/index.md b/guide/ops/high-availability/index.md
deleted file mode 100644
index 368ad22..0000000
--- a/guide/ops/high-availability/index.md
+++ /dev/null
@@ -1,53 +0,0 @@
----
-title: High Availability
-layout: website-normal
-children:
-- high-availability-supplemental.md
----
-
-Brooklyn will automatically run in HA mode if multiple Brooklyn instances are started
-pointing at the same persistence store. One Brooklyn node (e.g. the first one started)
-is elected as HA master: all *write operations* against Brooklyn entities, such as creating
-an application or invoking an effector, should be directed to the master.
-
-Once one node is running as `MASTER`, other nodes start in either `STANDBY` or `HOT_STANDBY` mode:
-
-* In `STANDBY` mode, a Brooklyn instance will monitor the master and will be a candidate
- to become `MASTER` should the master fail. Standby nodes do *not* attempt to rebind
- until they are elected master, so the state of existing entities is not available at
- the standby node. However a standby server consumes very little resource until it is
- promoted.
-
-* In `HOT_STANDBY` mode, a Brooklyn instance will read and make available the live state of
- entities. Thus a hot-standby node is available as a read-only copy.
- As with the standby node, if a hot-standby node detects that the master fails,
- it will be a candidate for promotion to master.
-
-* In `HOT_BACKUP` mode, a Brooklyn instance will read and make available the live state of
- entities, as a read-only copy. However this node is not able to become master,
- so it can safely be used to test compatibility across different versions.
-
-To explicitly specify what HA mode a node should be in, the following options are available
-for the config option `highAvailabilityMode` in [`org.apache.brooklyn.osgilauncher.cfg`](../paths.html):
-
-* `DISABLED`: management node works in isolation; it will not cooperate with any other standby/master nodes in management plane
-* `AUTO`: will look for other management nodes, and will allocate itself as standby or master based on other nodes' states
-* `MASTER`: will startup as master; if there is already a master then fails immediately
-* `STANDBY`: will start up as lukewarm standby; if there is not already a master then fails immediately
-* `HOT_STANDBY`: will start up as hot standby; if there is not already a master then fails immediately
-* `HOT_BACKUP`: will start up as hot backup; this can be done even if there is not already a master; this node will not be a master
-
-The REST API offers live detection and control of the HA mode,
-including setting priority to control which nodes will be promoted on master failure:
-
-* `/server/ha/state`: Returns the HA state of a management node (GET),
- or changes the state (POST)
-* `/server/ha/states`: Returns the HA states and detail for all nodes in a management plane
-* `/server/ha/priority`: Returns the HA node priority for MASTER failover (GET),
- or sets that priority (POST)
-
-Note that when POSTing to a non-master server it is necessary to pass a `Brooklyn-Allow-Non-Master-Access: true` header.
-For example, the following cURL command could be used to change the state of a `STANDBY` node on `localhost:8082` to `HOT_STANDBY`:
-
- curl -v -X POST -d mode=HOT_STANDBY -H "Brooklyn-Allow-Non-Master-Access: true" http://localhost:8082/v1/server/ha/state
-
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/58bb3aa0/guide/ops/index.md
----------------------------------------------------------------------
diff --git a/guide/ops/index.md b/guide/ops/index.md
deleted file mode 100644
index 29b5061..0000000
--- a/guide/ops/index.md
+++ /dev/null
@@ -1,23 +0,0 @@
----
-title: Reference Guide
-started-pdf-exclude: true
-layout: website-normal
-children:
-- production-installation.md
-- starting-stopping-monitoring.md
-- server-cli-reference.md
-- cli/
-- gui/
-- rest.md
-- configuration/
-- persistence/
-- high-availability/
-- logging.md
-- externalized-configuration.md
-- requirements.md
-- upgrade.md
-- security-guidelines.md
-- troubleshooting/
----
-
-{% include list-children.html %}
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/58bb3aa0/guide/ops/logging.md
----------------------------------------------------------------------
diff --git a/guide/ops/logging.md b/guide/ops/logging.md
deleted file mode 100644
index 41b6e4b..0000000
--- a/guide/ops/logging.md
+++ /dev/null
@@ -1,80 +0,0 @@
----
-title: Logging
-layout: website-normal
----
-
-Brooklyn uses the SLF4J logging facade, which allows use of many popular frameworks including `logback`,
-`java.util.logging` and `log4j`.
-
-The convention for log levels is as follows:
-
-* `ERROR` and above: exceptional situations which indicate that something has unexpectedly failed or
-some other problem has occured which the user is expected to attend to
-* `WARN`: exceptional situations which the user may which to know about but which do not necessarily indicate failure or require a response
-* `INFO`: a synopsis of activity, but which should not generate large volumes of events nor overwhelm a human observer
-* `DEBUG` and lower: detail of activity which is not normally of interest, but which might merit closer inspection under certain circumstances.
-
-Loggers follow the ``package.ClassName`` naming standard.
-
-
-## Using Logback through OSGi Pax Logging
-
-In the OSGi based Apache Brooklyn logging is configured from ops4j pax logging.
-
-See: [Logging - OSGi based Apache Brooklyn](../dev/tips/logging.html#osgi-based-apache-brooklyn) <br/>
-[https://ops4j1.jira.com/wiki/display/paxlogging/Configuration](https://ops4j1.jira.com/wiki/display/paxlogging/Configuration)
-
-
-## Standard Configuration
-
-A `logback.xml` file is included in the `conf/` directly of the Brooklyn distro;
-this is read by `brooklyn` at launch time. Changes to the logging configuration,
-such as new appenders or different log levels, can be made directly in this file
-or in a new file included from this.
-
-
-## Advanced Configuration
-
-The default `logback.xml` file references a collection of other log configuration files
-included in the Brooklyn jars. It is necessary to understand the source structure
-in the [logback-includes]({{ site.brooklyn.url.git }}/logging/logback-includes) project.
-
-For example, to change the debug log inclusions, create a folder `brooklyn` under `conf`
-and create a file `logback-debug.xml` based on the
-[brooklyn/logback-debug.xml]({{ site.brooklyn.url.git }}/logging/logback-includes/src/main/resources/brooklyn/logback-debug.xml)
-from that project.
-
-
-## Log File Backup
-
-*This sub-section is a work in progress; feedback from the community is extremely welcome.*
-
-The default rolling log files can be backed up periodically, e.g. using a CRON job.
-
-Note however that the rolling log file naming scheme will rename the historic zipped log files
-such that `brooklyn.debug-1.log.zip` is the most recent zipped log file. When the current
-`brooklyn.debug.log` is to be zipped, the previous zip file will be renamed
-`brooklyn.debug-2.log.zip`. This renaming of files can make RSYNC or backups tricky.
-
-An option is to covert/move the file to a name that includes the last-modified timestamp.
-For example (on mac):
-
- LOG_FILE=brooklyn.debug-1.log.zip
- TIMESTAMP=`stat -f '%Um' $LOG_FILE`
- mv $LOG_FILE /path/to/archive/brooklyn.debug-$TIMESTAMP.log.zip
-
-
-## Logging aggregators
-
-Integration with systems like Logstash and Splunk is possible using standard logback configuration.
-Logback can be configured to [write to the syslog](http://logback.qos.ch/manual/appenders.html#SyslogAppender),
-which can then [feed its logs to Logstash](http://www.logstash.net/docs/1.4.2/inputs/syslog).
-
-
-## For More Information
-
-The following resources may be useful when configuring logging:
-
-* The [logback-includes]({{ site.brooklyn.url.git }}/usage/logback-includes) project
-* [Brooklyn Developer Guide]({{ site.path.guide }}/dev/tips/logging.html) logging tips
-* The [Logback Project](http://logback.qos.ch/) home page
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/58bb3aa0/guide/ops/paths.md
----------------------------------------------------------------------
diff --git a/guide/ops/paths.md b/guide/ops/paths.md
deleted file mode 100644
index cb6d554..0000000
--- a/guide/ops/paths.md
+++ /dev/null
@@ -1,49 +0,0 @@
----
-layout: website-normal
-title: Paths breakdown
----
-
-Based on the installation method you choose, the paths to the installed components of Apache Brooklyn will be different. The
-following table will help you to easily locate these:
-
-<table class="table">
- <thead>
- <tr>
- <th>Installation method</th>
- <th>Brooklyn Home</td>
- <th>Brooklyn Logs</th>
- <th>Brooklyn Configuration</th>
- <th>Brooklyn Persisted state</th>
- </tr>
- </thead>
- <tbody>
- <tr>
- <td>RPM Package</td>
- <td><code>/opt/booklyn</code> (symlink to <code>/opt/booklyn-<version></code>)</td>
- <td><code>/var/log/booklyn</code> (symlink to <code>/opt/booklyn-<version>/data/log</code>)</td>
- <td><code>/etc/booklyn</code></td>
- <td><code>/var/lib/booklyn</code></td>
- </tr>
- <tr>
- <td>DEB Package</td>
- <td><code>/opt/booklyn</code> (symlink to <code>/opt/booklyn-<version></code>)</td>
- <td><code>/var/log/booklyn</code> (symlink to <code>/opt/booklyn-<version>/data/log</code>)</td>
- <td><code>/etc/booklyn</code></td>
- <td><code>/var/lib/booklyn</code></td>
- </tr>
- <tr>
- <td>Vagrant</td>
- <td><code>/opt/booklyn</code> (symlink to <code>/opt/booklyn-<version></code>)</td>
- <td><code>/var/log/booklyn</code> (symlink to <code>/opt/booklyn-<version>/data/log</code>)</td>
- <td><code>/etc/booklyn</code></td>
- <td><code>/var/lib/booklyn</code></td>
- </tr>
- <tr>
- <td>Tarball Zip Package</td>
- <td><code>/path/of/untar/archive</code></td>
- <td><code>/path/of/untar/archive/data/log</code></td>
- <td><code>/path/of/untar/archive/etc</code></td>
- <td><code>~/.brooklyn/brooklyn-persisted-state</code></td>
- </tr>
- </tbody>
-</table>
\ No newline at end of file