You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@brooklyn.apache.org by ri...@apache.org on 2017/02/10 17:04:26 UTC
svn commit: r1782490 [4/4] - in /brooklyn/site: ./ community/
community/security/ contributing/ developers/ developers/code/
developers/committers/ developers/committers/release-process/
documentation/ download/ learnmore/ learnmore/catalog/ learnmore/...
Modified: brooklyn/site/zoneMergeManual.html
URL: http://svn.apache.org/viewvc/brooklyn/site/zoneMergeManual.html?rev=1782490&r1=1782489&r2=1782490&view=diff
==============================================================================
--- brooklyn/site/zoneMergeManual.html (original)
+++ brooklyn/site/zoneMergeManual.html Fri Feb 10 17:04:25 2017
@@ -1495,7 +1495,7 @@
<li>
- Broooklyn YAML Blueprint Reference
+ YAML Blueprint Reference
@@ -3065,7 +3065,7 @@
<li>
- Google Compute Engine
+ Azure Compute ARM
@@ -3091,7 +3091,7 @@
<li>
- IBM Softlayer
+ Azure Compute Classic
@@ -3143,7 +3143,33 @@
<li>
- OpenStack
+ Google Compute Engine
+
+
+
+ </li>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ <a id="" name="" href="javascript:void(0);"></a>
+
+ <li>
+
+
+ IBM Softlayer
@@ -3190,6 +3216,32 @@
+ <a id="" name="" href="javascript:void(0);"></a>
+
+ <li>
+
+
+ OpenStack
+
+
+
+ </li>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
<a id="guide/ops/locations/location-customizers.md" name="guide/ops/locations/location-customizers.md" href="javascript:void(0);"></a>
<li>
@@ -7428,13 +7480,13 @@ At runtime you can restart and stop thes
individually. You can resize the cluster, attach enrichers which aggregate sensors across the cluster,
and attach policies which, for example, replace failed members or resize the cluster dynamically.
-The specification is defined in the `memberSpec` key. As you can see it looks very much like the
+The specification is defined in the `dynamiccluster.memberspec` key. As you can see it looks very much like the
previous blueprint, with one extra line. Entries in the blueprint which start with `$brooklyn:`
refer to the Brooklyn DSL and allow a small amount of logic to be embedded
(if there's a lot of logic, it's recommended to write a blueprint YAML plugin or write the blueprint itself
as a plugin, in Java or a JVM-supported language).
-In this case we want to indicate that the parameter to `memberSpec` is an entity specification
+In this case we want to indicate that the parameter to `dynamiccluster.memberspec` is an entity specification
(`EntitySpec` in the underlying type system); the `entitySpec` DSL command will do this for us.
The example above thus gives us 5 VMs identical to the one we created in the previous section.
@@ -7734,7 +7786,7 @@ services:
- type: org.apache.brooklyn.entity.group.DynamicCluster
brooklyn.config:
wars.root: http://search.maven.org/remotecontent?filepath=org/apache/brooklyn/example/brooklyn-example-hello-world-webapp/0.9.0/brooklyn-example-hello-world-webapp-0.9.0.war
- memberSpec:
+ dynamiccluster.memberspec:
$brooklyn:entitySpec:
type: org.apache.brooklyn.entity.webapp.tomcat.TomcatServer
{% endhighlight %}
@@ -8085,7 +8137,7 @@ inheritance from the runtime management
We could wrap our appserver in the same `DynamicCluster` we used earlier,
although then we'd need to define and configure the load balancer.
But another blueprint, the `ControlledDynamicWebAppCluster`, does this for us.
-It takes the same `memberSpec`, so we can build a fully functional elastic 3-tier
+It takes the same `dynamiccluster.memberspec`, so we can build a fully functional elastic 3-tier
deployment of our `hello-world-sql` application as follows:
{% highlight yaml %}
@@ -9154,13 +9206,15 @@ Additional logs may be created by some W
Known Limitations
-----------------
-### Use of Unencrypted HTTP
+WinRM 2.0 supports encryption mechanisms on top of HTTP. However those are not supported in Apache Brooklyn.
+For production adoptions please make sure you follow Microsoft Guidelines https://msdn.microsoft.com/en-us/library/ee309366(v=vs.85).aspx
-Brooklyn is currently using unencrypted HTTP for WinRM communication. This means that the login credentials will be
-transmitted in clear text.
+### Apache Brooklyn limitations on using WinRM over HTTP and HTTPS
-In future we aim to improve Brooklyn to support HTTPS. However this requires adding support to the underlying
-WinRM library, and also involves certificate creation and verification.
+By default Apache Brooklyn is currently using unencrypted HTTP for WinRM communication. It does not support encrypted HTTP for WinRM.
+
+HTTPS is supported but there is no mechanism of specifying which certificates to trust.
+Currently Apache Brooklyn will accept any certificate used in a HTTPS WinRM connection.
### Incorrect Exit Codes
@@ -10964,83 +11018,109 @@ For more about the ELK stack, please see
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)
+* [Elasticsearch](https://github.com/brooklyncentral/brooklyn-elk/blob/master/brooklyn-elasticsearch-catalog.bom)
+* [Logstash](https://github.com/brooklyncentral/brooklyn-elk/blob/master/brooklyn-logstash-catalog.bom)
+* [Kibana](https://github.com/brooklyncentral/brooklyn-elk/blob/master/brooklyn-kibana-catalog.bom)
+* [ELK](https://github.com/brooklyncentral/brooklyn-elk/blob/master/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.
+First, add all four blueprints to the Brooklyn Catalog. This can be done by clicking the 'Catalog' tab, clicking the '+'
+ symbol and pasting the YAML. Once this is done, click the 'Application' tab, then the '+' button to bring up the add
+application wizard. A new Catalog application will be available called 'ELK Stack'. Using the add application wizard,
+you should be able to deploy an ELK stack to a location of your choosing. Alternatively use the `br` Brooklyn
+command line tool and add the files with `br catalog add`.
#### Exploring the example
After the application has been deployed, you can ensure it is working as expected by checking the following:
-* There is a Kibana sensor called `main.uri`, the value of which points to the Kibana front end. You can explore this front end, and observe the logs stored in Elasticsearch. Many Brooklyn applications have a `main.uri` set to point you in the right direction.
-* You can also use the Elasticsearch REST API to explore further. The Elasticsearch Cluster entity has a `urls.http.list` sensor. Using a host:port from that list you will be able to access the REST API. The following URL will give you the state of the cluster `http://<host:port>/_cluster/health?pretty=true`. As you can see the `number_of_nodes` is currently 2, indicating that the Elasticsearch nodes are communicating with each other.
+* 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]({{site.path.guide}}/yaml/clusters.html).
+We will mainly focus on the Elasticsearch blueprint, and will be clear when another blueprint is being discussed. This blueprint describes a cluster of Elasticsearch nodes.
#### Provisioning Properties
-Our Elasticsearch blueprint has a few requirements of the location in which it is run. Firstly, it must be run on an Ubuntu machine as the example has been written specifically for this OS. Secondly, two ports must opened to ensure that the entities can be accessed from the outside world. Both of these requirements are configured via provisioning.properties as follows:
+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: 9220
+ elasticsearch.tcp.port: 9330
+ provisioning.properties:
+ osFamily: ubuntu
+ inboundPorts:
- $brooklyn:config("elasticsearch.http.port")
- $brooklyn:config("elasticsearch.tcp.port")
~~~
#### VanillaSoftwareProcess
-When composing a YAML blueprint, the VanillaSoftwareProcess is a very useful entity to be aware of. A VanillaSoftwareProcess will instruct Brooklyn to provision an instance, and run a series of shell commands to setup, run, monitor and teardown your program. The commands are specified as configuration on the VanillaSoftwareProcess and there are several available. We will spotlight a few now. To simplify this blueprint, we have specified ubuntu only installs so that our commands can be tailored to this system (e.g. use apt-get rather than yum).
+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:
+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")
- )
+ sudo rm -fr sudo tee /etc/elasticsearch/elasticsearch.yml
+ echo discovery.zen.ping.multicast.enabled: false | sudo tee -a /etc/elasticsearch/elasticsearch.yml
+ echo discovery.zen.ping.unicast.enabled: true | sudo tee -a /etc/elasticsearch/elasticsearch.yml
+ echo discovery.zen.ping.unicast.hosts: ${URLS_WITH_BRACKETS} | sudo tee -a /etc/elasticsearch/elasticsearch.yml
+ echo http.port: ${ES_HTTP_PORT} | sudo tee -a /etc/elasticsearch/elasticsearch.yml
+ echo transport.tcp.port: ${ES_TCP_PORT} | sudo tee -a /etc/elasticsearch/elasticsearch.yml
+ echo network.host: ${IP_ADDRESS} | sudo tee -a /etc/elasticsearch/elasticsearch.yml
~~~
-The purpose of this section is to create a YAML file with all of the required configuration. We use the YAML literal style `|` indicator to write a multi line command. We 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.
+
+The purpose of this section is to create a YAML file with all of the required configuration. We use the YAML
+literal style `|` indicator to write a multi line command. We start our series of commands by using the `rm` command to remove the
+previous config file. We then use `echo` and `tee` to create the new config file and insert the config. Part
+of the configuration is a list of all hosts that is set on the parent entity- this is done by using a combination
+ of the `component` and `attributeWhenReady` DSL commands. More on how this is generated later.
##### Check running
-After an app is installed and run, this command is scheduled to run regularly and used to populate the `service.isUp` sensor. If this command is not specified, or returns an exit code of anything other than zero, then Brooklyn will assume that your entity has failed and will display the fire status symbol. Please refer to the following section of the Elasticsearch blueprint:
+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"))
+checkRunning.command: sudo systemctl status kibana.service
~~~
-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.
+
+There are many different ways to implement this command. For this example, we are simply using the systemctl status
+of the appropriate service.
#### Enrichers
##### Elasticsearch URLS
-To ensure that all Elasticsearch nodes can communicate with each other they need to be configured with the TCP URL of all other nodes. Similarly, the Logstash instances need to be configured with all the HTTP URLs of the Elasticsearch nodes. The mechanism for doing this is the same, and involves using Transformers, Aggregators and Joiners, as follows:
+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.sourceSensor: $brooklyn:sensor("host.subnet.address")
enricher.targetSensor: $brooklyn:sensor("url.tcp")
- enricher.targetValue: $brooklyn:formatString("%s:%s", $brooklyn:attributeWhenReady("host.address"), $brooklyn:config("elasticsearch.tcp.port"))
+ enricher.targetValue: $brooklyn:formatString("%s:%s", $brooklyn:attributeWhenReady("host.subnet.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:
+In this example, we take the host.subnet.address and append the TCP port, outputting the result as `url.tcp`.
+After this has been done, we now need to collect all the URLs into a list in the Cluster entity, as follows:
~~~yaml
brooklyn.enrichers:
@@ -11051,7 +11131,9 @@ brooklyn.enrichers:
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:
+
+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
@@ -11074,12 +11156,14 @@ Finally, the string has brackets added t
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:
+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.sourceSensor: $brooklyn:sensor("host.subnet.address")
enricher.targetSensor: $brooklyn:sensor("host.address.first")
enricher.aggregating.fromMembers: true
enricher.transformation:
@@ -11087,19 +11171,55 @@ Kibana also needs to be configured such
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.
+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:
+In the ELK blueprint, there is a good example of a latch. Latches are used to force an entity to wait until
+certain conditions are met before continuing. For example:
~~~yaml
- type: kibana-standalone
- ...
+ id: kibana
name: Kibana Server
- customize.latch: $brooklyn:entity("es").attributeWhenReady("service.isUp")
+ 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.
+This latch is used to stop Kibana customizing until the Elasticsearch cluster is up. We do this to ensure
+that the URL sensors have been setup, so that they can be passed into Kibana during the customization phase.
+
+Latches can also be used to control how many entities can execute the same step at any given moment. When
+a latch is given the value of a `MaxConcurrencySensor` it will unblock execution only when there are
+available "slots" to execute (think of it as a semaphore). For example to let a single entity execute the
+launch step of the start effector:
+
+~~~yaml
+services:
+- type: cluster
+
+ brooklyn.initializers:
+ - type: org.apache.brooklyn.core.sensor.MaxConcurrencySensor
+ brooklyn.config:
+ name: single-executor
+ latch.concurrency.max: 1
+
+ brooklyn.config:
+ initialSize: 10
+ memberSpec:
+ $brooklyn:entitySpec:
+ type: vanilla-bash-server
+ brooklyn.config:
+ launch.command: sleep 2
+ checkRunning.command: true
+ launch.latch: $brooklyn:parent().attributeWhenReady("single-executor")
+~~~
+
+It's important to note that the above setup is not reentrant. This means that users should be careful to
+avoid deadlocks. For example having a start and launch latches against the `single-executor` from above.
+The launch latch will block forever since the start latch already would've acquired the free slot.
#### Child entities
The ELK blueprint also contains a good example of a child entity.
@@ -11113,8 +11233,44 @@ The ELK blueprint also contains a good e
- 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.
+In this example, a logstash-child is started as a child of the parent Tomcat server. The Tomcat server needs
+to be configured with a `children.startable.mode` to inform Brooklyn when to bring up the child. In this case
+ we have selected background so that the child is disassociated from the parent entity, and late to specify that
+ the parent entity should start before we start the child.
+
+The example also shows how to configure Logstash inputs and filters, if necessary, for a particular application,
+in this case Tomcat.
+~~~yaml
+- type: logstash-child
+ name: Logstash
+ brooklyn.config:
+ logstash.elasticsearch.hosts: $brooklyn:entity("es").attributeWhenReady("urls.http.withBrackets")
+ logstash.config.input:
+ $brooklyn:formatString:
+ - |
+ input {
+ file {
+ path => "%s/logs/localhost_access_log.*"
+ start_position => "beginning"
+ }
+ }
+ - $brooklyn:entity("tomcat").attributeWhenReady("run.dir")
+ logstash.config.filter: |
+ filter {
+ grok {
+ match => { "message" => "%{COMBINEDAPACHELOG}" }
+ }
+ date {
+ match => [ "timestamp" , "dd/MMM/yyyy:HH:mm:ss Z" ]
+ }
+ }
+~~~
+
+Configuring an appropriate visualisation on the Kibana server (access it via the URL on the summary tab for
+that entity) allows a dashboard to be created such as
+
+
</div>
@@ -13315,9 +13471,9 @@ To launch Brooklyn, from the directory w
% bin/brooklyn launch > /dev/null 2>&1 & disown
{% endhighlight %}
-With no configuration, this will launch the Brooklyn web console and REST API on [`http://localhost:8081/`](http://localhost:8081/).
-No password is set, but the server is listening only on the loopback network interface for security.
-Once [security is configured](brooklyn_properties.html), Brooklyn will listen on all network interfaces by default.
+With no configuration, this will launch the Brooklyn web console and REST API on [`http://localhost:8081/`](http://localhost:8081/),
+listening on all network interfaces. No credentials are required by default. It is strongly
+recommended to [configure security](brooklyn_properties.html).
See the [Server CLI Reference](server-cli-reference.html) for more information
about the Brooklyn server process.
@@ -13413,9 +13569,11 @@ To launch Brooklyn, from the directory w
% nohup bin/brooklyn launch > /dev/null 2>&1 &
{% endhighlight %}
-With no configuration, this will launch the Brooklyn web console and REST API on [`http://localhost:8081/`](http://localhost:8081/).
-No password is set, but the server is listening only on the loopback network interface for security.
-Once [security is configured](brooklyn_properties.html), Brooklyn will listen on all network interfaces by default.
+With no configuration, this will launch the Brooklyn web console and REST API on [`http://localhost:8081/`](http://localhost:8081/),
+listening on all network interfaces. No credentials are required by default. For a production
+system, or if Apache Brooklyn is publicly reachable, it is strongly recommended to
+[configure security](brooklyn_properties.html).
+
By default, Brooklyn will write log messages at the INFO level or above to `brooklyn.info.log` and messgages at the
DEBUG level or above to `brooklyn.debug.log`. Redirecting the output to `/dev/null` prevents the default console output
being written to `nohup.out`.
@@ -14982,10 +15140,11 @@ Please refer to the [Server CLI Referenc
Brooklyn will output the address of the management interface:
<pre>
-INFO No security provider options specified. ...
-INFO Starting Brooklyn web-console with passwordless access on localhost ...
-INFO Starting brooklyn web-console on loopback interface because no security config is set
-INFO Started Brooklyn console at http://127.0.0.1:8081/, running classpath://brooklyn.war
+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.
@@ -15364,10 +15523,11 @@ with abundant comments.
## Quick Setup
-The most common properties set in this file are for access control.
-Without this, Brooklyn will bind only to localhost or will create a random
-password written to the log for use on other networks.
-The simplest way to specify users and passwords is:
+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
@@ -15379,8 +15539,7 @@ The properties file *must* have permissi
(i.e. readable and writable only by the file's owner),
for some security.
-In many cases, it is preferable instead to use an external credentials store such as LDAP
-or at least to have passwords in this file.
+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`.
@@ -15952,6 +16111,42 @@ See also:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -16073,7 +16268,7 @@ Object Store Persistence
Brooklyn can persist its state to any Object Store API that jclouds supports including
S3, Swift and Azure. This gives access to any compatible Object Store product or cloud provider
-including AWS-S3, SoftLayer, Rackspace, HP and Microsoft Azure. For a complete list of supported
+including AWS-S3, SoftLayer, Rackspace and Microsoft Azure. For a complete list of supported
providers, see [jclouds](http://jclouds.apache.org/reference/providers/#blobstore).
To configure the Object Store, add the credentials to `~/.brooklyn/brooklyn.properties` such as:
@@ -16087,9 +16282,10 @@ brooklyn.location.named.aws-s3-eu-west-1
or:
{% highlight properties %}
-brooklyn.location.named.softlayer-swift-ams01=jclouds:swift:https://ams01.objectstorage.softlayer.net/auth/v1.0
+brooklyn.location.named.softlayer-swift-ams01=jclouds:openstack-swift:https://ams01.objectstorage.softlayer.net/auth/v1.0
brooklyn.location.named.softlayer-swift-ams01.identity=ABCDEFGHIJKLM:myname
brooklyn.location.named.softlayer-swift-ams01.credential=abcdefghijklmnopqrstuvwxyz1234567890abcdefghijklmnopqrstuvwxyz12
+brooklyn.location.named.softlayer-swift-ams01.jclouds.keystone.credential-type=tempAuthCredentials
{% endhighlight %}
Start Brooklyn pointing at this target object store, e.g.:
@@ -16101,15 +16297,15 @@ nohup brooklyn launch --persist auto --p
The following `brooklyn.properties` options can also be used:
- # Location spec string for an object store (e.g. jclouds:swift:URL) where persisted state
+ # Location spec string for an object store (e.g. jclouds:openstack-swift:URL) where persisted state
# should be kept; if blank or not supplied, the file system is used.
brooklyn.persistence.location.spec=<location>
# Container name for writing persisted state
brooklyn.persistence.dir=/path/to/dataContainer
- # Location spec string for an object store (e.g. jclouds:swift:URL) where backups of persisted
- # state should be kept; defaults to the local file system.
+ # Location spec string for an object store (e.g. jclouds:openstack-swift:URL) where backups of
+ # persisted state should be kept; defaults to the local file system.
brooklyn.persistence.backups.location.spec=<location>
# Container name for writing backups of persisted state;
@@ -21124,6 +21320,7 @@ keep the authorship of the commit, so we
<ol>
+ <li><a href="http://brooklyn.apache.org/v/0.10.0/developers/committers/release-process/prepare-for-release.html">Preparing for a release</a> - How to prepare the project for a release</li>
<li><a href="#contentsLink-release-prerequisites">Prerequisites</a> - steps that a new release manager must do (but which only need to be done once)</li>
<li><a href="#contentsLink-environment-variables-for-the-release">Set environment variables</a> - many example snippets here use environment variables to
avoid repetition - this page describes what they are</li>
@@ -21131,11 +21328,8 @@ avoid repetition - this page describes w
<li><a href="#contentsLink-make-the-release-artifacts">Make the release artifacts</a></li>
<li><a href="#contentsLink-verify-the-release-artifacts">Verify the release artifacts</a></li>
<li><a href="#contentsLink-publish-to-the-staging-area">Publish the release artifacts to the staging area</a></li>
- <li><a href="#contentsLink-vote-on-dev@brooklyn">Vote on the dev@brooklyn list</a>
- <ol>
- <li>If the vote fails - <a href="#contentsLink-fix-on-the-release-branch">fix the release branch</a> and resume from step 3</li>
- </ol>
- </li>
+ <li><a href="#contentsLink-vote-on-dev@brooklyn">Vote on the dev@brooklyn list</a></li>
+ <li>If the vote fails - <a href="#contentsLink-fix-on-the-release-branch">fix the release branch</a> and resume from step 4</li>
<li><a href="#contentsLink-publish-to-the-public">Publish the release artifacts to the public location</a></li>
<li><a href="#contentsLink-announce-the-release">Announce the release</a></li>
</ol>
@@ -21224,8 +21418,9 @@ recommended; building on a mac, <code>po
(with a <code>gpg</code> alias). The steps here also assume you have the following set
(not using <code>whoami</code> if that’s not appropriate):</p>
-<div class="highlight"><pre><code class="language-bash" data-lang="bash"><span class="nv">GPG_KEY</span><span class="o">=</span><span class="sb">`</span>whoami<span class="sb">`</span>@apache.org
-<span class="nv">SVN_USERNAME</span><span class="o">=</span><span class="sb">`</span>whoami<span class="sb">`</span></code></pre></div>
+<div class="highlight"><pre><code class="language-bash" data-lang="bash"><span class="nv">ASF_USERNAME</span><span class="o">=</span><span class="sb">`</span>whoami<span class="sb">`</span>
+<span class="nv">GPG_KEY</span><span class="o">=</span><span class="nv">$ASF_USERNAME</span>@apache.org
+<span class="nv">SVN_USERNAME</span><span class="o">=</span><span class="nv">$ASF_USERNAME</span></code></pre></div>
<p>If you have an existing GPG key, but it does not include your Apache email address, you can add your email address as
described <a href="https://superuser.com/a/293283">in this Superuser.com posting</a>. Otherwise, create a new GPG key giving your
@@ -21242,8 +21437,8 @@ separated by spaces. Log in to <a href="
<p>Now add your key to the <code>apache-dist-release-brooklyn/KEYS</code> file:</p>
<div class="highlight"><pre><code class="language-bash" data-lang="bash"><span class="nb">cd </span>apache-dist-release-brooklyn
-<span class="o">(</span>gpg2 --list-sigs richard@apache.org <span class="o">&&</span> gpg2 --armor --export richard@apache.org<span class="o">)</span> >> KEYS
-svn --username <span class="nv">$SVN_USERNAME</span> commit -m <span class="s1">'Update brooklyn/KEYS for $GPG_KEY'</span></code></pre></div>
+<span class="o">(</span>gpg2 --list-sigs <span class="nv">$ASF_USERNAME</span>@apache.org <span class="o">&&</span> gpg2 --armor --export <span class="nv">$ASF_USERNAME</span>@apache.org<span class="o">)</span> >> KEYS
+svn --username <span class="nv">$SVN_USERNAME</span> --no-auth-cache commit -m <span class="s2">"Update brooklyn/KEYS for $GPG_KEY"</span></code></pre></div>
<p>References:</p>
@@ -21435,7 +21630,7 @@ git add . <span class="o">&&</sp
<p>If you are happy with the changes, push them:</p>
-<div class="highlight"><pre><code class="language-bash" data-lang="bash"><span class="k">for</span> m in <span class="nv">$MODULES</span><span class="p">;</span> <span class="k">do</span> <span class="o">(</span> <span class="nb">cd</span> <span class="nv">$m</span> <span class="o">&&</span> git push apache-git <span class="nv">$VERSION</span> <span class="o">)</span><span class="p">;</span> <span class="k">done</span></code></pre></div>
+<div class="highlight"><pre><code class="language-bash" data-lang="bash"><span class="k">for</span> m in <span class="nv">$MODULES</span><span class="p">;</span> <span class="k">do</span> <span class="o">(</span> <span class="nb">cd</span> <span class="nv">$m</span> <span class="o">&&</span> git push apache-git <span class="nv">$VERSION_NAME</span> <span class="o">)</span><span class="p">;</span> <span class="k">done</span></code></pre></div>
<h2 id="internalLink_release-branch-and-set-version_update-the-version-on-master">Update the version on master</h2>
@@ -21599,7 +21794,7 @@ they have the GnuPG and md5sum/sha1sum i
release. You should determine the following information and set your environment:</p>
<div class="highlight"><pre><code class="language-bash" data-lang="bash"><span class="c"># The version we are releasing now.</span>
-<span class="nv">VERSION_NAME</span><span class="o">=</span>0.9.0
+<span class="nv">VERSION_NAME</span><span class="o">=</span>0.10.0
<span class="c"># The release candidate number we are making now.</span>
<span class="nv">RC_NUMBER</span><span class="o">=</span>1
@@ -21622,30 +21817,58 @@ release. You should determine the follow
<div class="highlight"><pre><code class="language-bash" data-lang="bash"><span class="nv">TEMP_DIR</span><span class="o">=</span>~/tmp/brooklyn/release/<span class="k">${</span><span class="nv">VERSION_NAME</span><span class="k">}</span>-rc<span class="k">${</span><span class="nv">RC_NUMBER</span><span class="k">}</span>
<span class="nv">BASE_NAME</span><span class="o">=</span>apache-brooklyn-<span class="k">${</span><span class="nv">VERSION_NAME</span><span class="k">}</span>-rc<span class="k">${</span><span class="nv">RC_NUMBER</span><span class="k">}</span>
-<span class="nv">BASE_URL</span><span class="o">=</span>https://dist.apache.org/repos/dist/dev/brooklyn/<span class="k">${</span><span class="nv">BASE_NAME</span><span class="k">}</span>
+<span class="nv">BASE_URL</span><span class="o">=</span>https://dist.apache.org/repos/dist/dev/brooklyn/<span class="k">${</span><span class="nv">BASE_NAME</span><span class="k">}</span>/
mkdir -p <span class="k">${</span><span class="nv">TEMP_DIR</span><span class="k">}</span>
<span class="nb">cd</span> <span class="k">${</span><span class="nv">TEMP_DIR</span><span class="k">}</span>
-<span class="k">for</span> ext in -src.tar.gz -src.zip -bin.tar.gz -bin.zip<span class="p">;</span> <span class="k">do</span>
- <span class="nv">artifact</span><span class="o">=</span><span class="k">${</span><span class="nv">BASE_NAME</span><span class="k">}${</span><span class="nv">ext</span><span class="k">}</span>
- <span class="k">for</span> i in <span class="k">${</span><span class="nv">artifact</span><span class="k">}</span> <span class="k">${</span><span class="nv">artifact</span><span class="k">}</span>.asc <span class="k">${</span><span class="nv">artifact</span><span class="k">}</span>.md5 <span class="k">${</span><span class="nv">artifact</span><span class="k">}</span>.sha1 <span class="k">${</span><span class="nv">artifact</span><span class="k">}</span>.sha256<span class="p">;</span> <span class="k">do</span>
- curl <span class="k">${</span><span class="nv">BASE_URL</span><span class="k">}</span>/<span class="nv">$i</span> -O
- <span class="k">done</span>
-<span class="k">done</span></code></pre></div>
+curl -s <span class="nv">$BASE_URL</span> <span class="p">|</span> <span class="se">\</span>
+ grep href <span class="p">|</span> grep -v <span class="s1">'\.\.'</span> <span class="p">|</span> <span class="se">\</span>
+ sed -e <span class="s1">'s@.*href="@'</span><span class="nv">$BASE_URL</span><span class="s1">'@'</span> <span class="p">|</span> <span class="se">\</span>
+ sed -e <span class="s1">'s@">.*@@'</span> <span class="p">|</span> <span class="se">\</span>
+ xargs -n <span class="m">1</span> curl -O</code></pre></div>
<p>(Alternatively if you have <code>apache-dist-dev-repo</code> checked out,
you can do an <code>svn up</code> in there and <code>cd apache-brooklyn-${VERSION_NAME}-rc${RC_NUMBER}</code>.)</p>
+<h2 id="internalLink_verify-the-release-artifacts_verify-presence-of-notice--license">Verify presence of NOTICE & LICENSE</h2>
+<p>Check that all archives are correctly annotated with license information.
+Check NOTICE is included:</p>
+
+<div class="highlight"><pre><code class="language-bash" data-lang="bash"><span class="k">for</span> ARCHIVE in <span class="k">$(</span>find * -type f ! <span class="se">\(</span> -name <span class="s1">'*.asc'</span> -o -name <span class="s1">'*.md5'</span> -o -name <span class="s1">'*.sha1'</span> -o -name <span class="s1">'*.sha256'</span> <span class="se">\)</span> <span class="k">)</span><span class="p">;</span> <span class="k">do</span>
+ <span class="nv">REL_ARCHIVE</span><span class="o">=</span><span class="k">${</span><span class="nv">ARCHIVE</span><span class="p">/-rc?</span><span class="k">}</span>
+ <span class="k">case</span> <span class="nv">$ARCHIVE</span> in
+ *.tar.gz<span class="o">)</span>
+ <span class="nv">LIST</span><span class="o">=</span><span class="s2">"tar -tvf"</span>
+ <span class="nv">PREFIX</span><span class="o">=</span><span class="k">${</span><span class="nv">REL_ARCHIVE</span><span class="p">%.tar.gz</span><span class="k">}</span>
+ <span class="p">;;</span>
+ *.zip<span class="o">)</span>
+ <span class="nv">LIST</span><span class="o">=</span><span class="s2">"unzip -Zl"</span>
+ <span class="nv">PREFIX</span><span class="o">=</span><span class="k">${</span><span class="nv">REL_ARCHIVE</span><span class="p">%.zip</span><span class="k">}</span>
+ <span class="p">;;</span>
+ *.rpm<span class="o">)</span>
+ <span class="nv">LIST</span><span class="o">=</span><span class="s2">"rpm -qlp"</span>
+ <span class="nv">PREFIX</span><span class="o">=</span><span class="s2">"/opt/brooklyn"</span>
+ <span class="p">;;</span>
+ *<span class="o">)</span>
+ <span class="nb">echo</span> <span class="s2">"Unrecognized file type $ARCHIVE. Aborting!"</span>
+ <span class="nb">exit </span>1
+ <span class="p">;;</span>
+ <span class="k">esac</span>
+ <span class="nv">$LIST</span> <span class="nv">$ARCHIVE</span> <span class="p">|</span> grep <span class="s2">"$PREFIX/NOTICE"</span> <span class="o">&&</span> <span class="se">\</span>
+ <span class="nv">$LIST</span> <span class="nv">$ARCHIVE</span> <span class="p">|</span> grep <span class="s2">"$PREFIX/LICENSE"</span> <span class="se">\</span>
+ <span class="o">||</span> <span class="o">{</span> <span class="nb">echo</span> <span class="s2">"Missing LICENSE or NOTICE in $ARCHIVE. Aborting!"</span><span class="p">;</span> <span class="nb">break</span><span class="p">;</span> <span class="o">}</span>
+<span class="k">done</span></code></pre></div>
+
<h2 id="internalLink_verify-the-release-artifacts_verify-the-hashes-and-signatures-of-artifacts">Verify the hashes and signatures of artifacts</h2>
<p>Then check the hashes and signatures, ensuring you get a positive message from each one:</p>
-<div class="highlight"><pre><code class="language-bash" data-lang="bash"><span class="k">for</span> ext in -src.tar.gz -src.zip -bin.tar.gz -bin.zip<span class="p">;</span> <span class="k">do</span>
- <span class="nv">artifact</span><span class="o">=</span>apache-brooklyn-<span class="k">${</span><span class="nv">VERSION_NAME</span><span class="k">}</span>-rc<span class="k">${</span><span class="nv">RC_NUMBER</span><span class="k">}${</span><span class="nv">ext</span><span class="k">}</span>
- md5sum -c <span class="k">${</span><span class="nv">artifact</span><span class="k">}</span>.md5
- shasum -a1 -c <span class="k">${</span><span class="nv">artifact</span><span class="k">}</span>.sha1
- shasum -a256 -c <span class="k">${</span><span class="nv">artifact</span><span class="k">}</span>.sha256
- gpg2 --verify <span class="k">${</span><span class="nv">artifact</span><span class="k">}</span>.asc <span class="k">${</span><span class="nv">artifact</span><span class="k">}</span>
+<div class="highlight"><pre><code class="language-bash" data-lang="bash"><span class="k">for</span> artifact in <span class="k">$(</span>find * -type f ! <span class="se">\(</span> -name <span class="s1">'*.asc'</span> -o -name <span class="s1">'*.md5'</span> -o -name <span class="s1">'*.sha1'</span> -o -name <span class="s1">'*.sha256'</span> <span class="se">\)</span> <span class="k">)</span><span class="p">;</span> <span class="k">do</span>
+ md5sum -c <span class="k">${</span><span class="nv">artifact</span><span class="k">}</span>.md5 <span class="o">&&</span> <span class="se">\</span>
+ shasum -a1 -c <span class="k">${</span><span class="nv">artifact</span><span class="k">}</span>.sha1 <span class="o">&&</span> <span class="se">\</span>
+ shasum -a256 -c <span class="k">${</span><span class="nv">artifact</span><span class="k">}</span>.sha256 <span class="o">&&</span> <span class="se">\</span>
+ gpg2 --verify <span class="k">${</span><span class="nv">artifact</span><span class="k">}</span>.asc <span class="k">${</span><span class="nv">artifact</span><span class="k">}</span> <span class="se">\</span>
+ <span class="o">||</span> <span class="o">{</span> <span class="nb">echo</span> <span class="s2">"Invalid signature for $artifact. Aborting!"</span><span class="p">;</span> <span class="nb">break</span><span class="p">;</span> <span class="o">}</span>
<span class="k">done</span></code></pre></div>
<h2 id="internalLink_verify-the-release-artifacts_verify-expanded-source-archive-matches-contents-of-rc-tag">Verify expanded source archive matches contents of RC tag</h2>
@@ -21668,6 +21891,17 @@ unzip <span class="k">${</span><span cla
<span class="c"># (or preferably both!)</span>
diff -qr unpacked-src/<span class="nv">$BASE_NAME</span> <span class="nv">$BASE_REPO</span></code></pre></div>
+<h2 id="internalLink_verify-the-release-artifacts_check-for-files-with-invalid-headers-in-source-archive">Check for files with invalid headers in source archive</h2>
+
+<div class="highlight"><pre><code class="language-bash" data-lang="bash">grep -rL <span class="s2">"Licensed to the Apache Software Foundation"</span> * <span class="p">|</span> less</code></pre></div>
+
+<h2 id="internalLink_verify-the-release-artifacts_check-for-binary-files-in-source-archive">Check for binary files in source archive</h2>
+
+<p>Look for files which are created/compiled based on other source files in the distribution.
+“Primary” binary files like images are acceptable.</p>
+
+<div class="highlight"><pre><code class="language-bash" data-lang="bash">find . <span class="p">|</span> xargs -n1 file <span class="p">|</span> awk -F <span class="s1">$':'</span> <span class="s1">' { t = $1; $1 = $2; $2 = t; print; } '</span> <span class="p">|</span> sort <span class="p">|</span> less</code></pre></div>
+
<h2 id="internalLink_verify-the-release-artifacts_verify-the-operation-of-the-binary-distribution">Verify the operation of the binary distribution</h2>
<div class="highlight"><pre><code class="language-bash" data-lang="bash"><span class="nb">cd</span> <span class="nv">$TEMP_DIR</span>
@@ -21708,6 +21942,8 @@ artifact.</li>
made with voting open. This is then the point for the RM and the community to perform more detailed testing on the RC
artifacts and submit bug reports and votes.</p>
+<p>Automated sanity check script available at brooklyn-dist/release/verity_brooklyn_rc.sh</p>
+
<h2 id="internalLink_verify-the-release-artifacts_if-the-sanity-check-fails">If the sanity check fails</h2>
<p>Note the problems causing the failure, and file bug reports, start mailing list discussions etc., as appropriate.</p>
@@ -21779,7 +22015,7 @@ information.</p>
and all associated <code>.md5</code>, <code>.sha1</code>, <code>.sha256</code> and <code>.asc</code> signatures. Then commit:</p>
<div class="highlight"><pre><code class="language-bash" data-lang="bash">svn add apache-brooklyn-<span class="k">${</span><span class="nv">VERSION_NAME</span><span class="k">}</span>-rc<span class="k">${</span><span class="nv">RC_NUMBER</span><span class="k">}</span>
-svn commit --message <span class="s2">"Add apache-brooklyn-${VERSION_NAME}-rc${RC_NUMBER} to dist/dev/brooklyn"</span></code></pre></div>
+svn commit --username <span class="nv">$SVN_USERNAME</span> --no-auth-cache --message <span class="s2">"Add apache-brooklyn-${VERSION_NAME}-rc${RC_NUMBER} to dist/dev/brooklyn"</span></code></pre></div>
<p>These steps can be performed as part of the <code>make-release-artifacts.sh</code> script used earlier
if <code>${APACHE_DIST_SVN_DIR}</code> points to the appropriate subversion directory.</p>
@@ -21792,7 +22028,7 @@ be used for downloading the artifacts.</
<p>Go to the Apache Nexus server at <a href="https://repository.apache.org/">https://repository.apache.org/</a> and log in using the
link in the top right (the credentials are the same as your Git and Jenkins credentials). Go to the “Staging
Repositories” page, and tick the repository with the name starting <code>orgapachebrooklyn</code>. Click the <strong>Close</strong> button.
-Provide a description which includes the version and release candidate, e.g. <code>Apache Brooklyn 0.7.0-incubating-rc1</code>.</p>
+Provide a description which includes the version and release candidate, e.g. <code>Apache Brooklyn 0.10.0-rc1</code>.</p>
</div>
@@ -21831,7 +22067,7 @@ Provide a description which includes the
<h2 id="internalLink_vote-on-dev@brooklyn_start-the-vote">Start the vote</h2>
<p>A script to generate the voting email can be found in <code>brooklyn-dist/release/print-vote-email.sh</code>,
-taking a single argument being the staging repo link. For example:</p>
+taking a single argument being the staging repo ID. For example:</p>
<pre><code>brooklyn-dist/release/print-vote-email.sh orgapachebrooklyn-1234 | pbcopy
</code></pre>
@@ -21891,6 +22127,54 @@ The vote will be open for at least 72 ho
Thanks,
[Release manager name]</code></pre></div>
+<h2 id="internalLink_vote-on-dev@brooklyn_discuss-the-vote">Discuss the vote</h2>
+<p>Open a parallel thread for a place to discuss the vote. Name it [DISCUSS]<subject of="" the="" voting="" email="">, replying
+to the vote email. Here's an example body for the email.</subject></p>
+
+<div class="highlight"><pre><code class="language-text" data-lang="text">This thread is for discussions related to the release vote.
+
+I should clarify what we are looking for in a release vote. Particularly,
+we are looking for people to download,validate, and test the release.
+Only if you are satisfied that the artifacts are correct and the quality is
+high enough, should you make a "+1" vote. Alongside your vote you should list
+the checks that you made.
+
+Here is a good example: http://markmail.org/message/gevsz2pdciraw6jw
+
+The vote is not simply about "the master branch contains the features I wanted" -
+it is about making sure that *these* artifacts are *correct* (e.g. they are
+not corrupted, hashes and signatures pass) and are of *sufficiently high
+quality* to be stamped as an official release of The Apache Software Foundation.
+
+Why test the artifacts when master is looking good? Here are some reasons:
+
+- somebody could have made a commit that broke it, since you last git pulled
+- the release branch could have been made at the wrong point, or inconsistently
+ between all of the submodules
+- something in the release process could have broken it
+- I could have made a mistake and corrupted the files
+- a problem with the Apache infrastructure could mean that the release files are
+ unobtainable or corrupted
+
+This is why the release manager needs you to download the actual release
+artifacts and try them out.
+
+The way Apache works can be a bit arcane sometimes, but it's all done with
+a reason. If the vote passes then the contents of the email and its links
+become "endorsed" by The Apache Software Foundation, and the Foundation will
+take on legal liability for them, forever.
+
+And of course we want the best possible experience for our users - so we need
+the actual release files to be tested manually to make sure that a mistake does
+not ruin the experience for users.
+
+So if you can spare an hour or more to download some of the artifacts and try
+them out, then it will be *very* useful! The vote lasts for three days so
+there's no need to rush to get a vote in.
+
+Thanks!
+[Release manager name]</code></pre></div>
+
<h2 id="internalLink_vote-on-dev@brooklyn_reply-to-vote">Reply to vote</h2>
<p>Here is an example checklist (thanks Andrew Phillips for your thoroughness on jclouds!)</p>
@@ -22055,10 +22339,9 @@ information.</p>
the release candidate artifacts - <code>-src</code> and <code>-bin</code>, <code>.tar.gz</code> and <code>.zip</code>, and all associated <code>.md5</code>, <code>.sha1</code>, <code>.sha256</code>
and <code>.asc</code> signatures - into this new folder.</p>
-<p>Rename all of the files to remove the <code>-rcN</code> designation. If you have the <code>mmv</code> tool installed, this can be done with
-this command:</p>
+<p>Rename all of the files to remove the <code>-rcN</code> designation:</p>
-<div class="highlight"><pre><code class="language-bash" data-lang="bash">mmv -v <span class="s1">'*-rc'</span><span class="nv">$RC_NUMBER</span><span class="s1">'-*'</span> <span class="s1">'#1-#2'</span></code></pre></div>
+<div class="highlight"><pre><code class="language-bash" data-lang="bash"><span class="k">for</span> f in *<span class="p">;</span> <span class="k">do</span> mv <span class="nv">$f</span> <span class="k">${</span><span class="nv">f</span><span class="p">//-rc</span><span class="k">${</span><span class="nv">RC_NUMBER</span><span class="k">}</span><span class="p">/</span><span class="k">}</span><span class="p">;</span> <span class="k">done</span></code></pre></div>
<p>The hash files will need patching to refer to the filenames without the <code>-rcN</code> designation:</p>
@@ -22069,11 +22352,12 @@ rm -f *.bak</code></pre></div>
<p>As a final check, re-test the hashes and signatures:</p>
-<div class="highlight"><pre><code class="language-bash" data-lang="bash"><span class="k">for</span> artifact in *.tar.gz *.zip *.rpm<span class="p">;</span> <span class="k">do</span>
- md5sum -c <span class="k">${</span><span class="nv">artifact</span><span class="k">}</span>.md5
- shasum -a1 -c <span class="k">${</span><span class="nv">artifact</span><span class="k">}</span>.sha1
- shasum -a256 -c <span class="k">${</span><span class="nv">artifact</span><span class="k">}</span>.sha256
- gpg2 --verify <span class="k">${</span><span class="nv">artifact</span><span class="k">}</span>.asc <span class="k">${</span><span class="nv">artifact</span><span class="k">}</span>
+<div class="highlight"><pre><code class="language-bash" data-lang="bash"><span class="k">for</span> artifact in <span class="k">$(</span>find * -type f ! <span class="se">\(</span> -name <span class="s1">'*.asc'</span> -o -name <span class="s1">'*.md5'</span> -o -name <span class="s1">'*.sha1'</span> -o -name <span class="s1">'*.sha256'</span> <span class="se">\)</span> <span class="k">)</span><span class="p">;</span> <span class="k">do</span>
+ md5sum -c <span class="k">${</span><span class="nv">artifact</span><span class="k">}</span>.md5 <span class="o">&&</span> <span class="se">\</span>
+ shasum -a1 -c <span class="k">${</span><span class="nv">artifact</span><span class="k">}</span>.sha1 <span class="o">&&</span> <span class="se">\</span>
+ shasum -a256 -c <span class="k">${</span><span class="nv">artifact</span><span class="k">}</span>.sha256 <span class="o">&&</span> <span class="se">\</span>
+ gpg2 --verify <span class="k">${</span><span class="nv">artifact</span><span class="k">}</span>.asc <span class="k">${</span><span class="nv">artifact</span><span class="k">}</span> <span class="se">\</span>
+ <span class="o">||</span> <span class="o">{</span> <span class="nb">echo</span> <span class="s2">"Invalid signature for $artifact. Aborting!"</span><span class="p">;</span> <span class="nb">break</span><span class="p">;</span> <span class="o">}</span>
<span class="k">done</span></code></pre></div>
<p>(You may get warnings such as: <code>gpg: WARNING: This key is not certified with a trusted signature!</code>
Modified: brooklyn/site/zoneMergeStarted.html
URL: http://svn.apache.org/viewvc/brooklyn/site/zoneMergeStarted.html?rev=1782490&r1=1782489&r2=1782490&view=diff
==============================================================================
--- brooklyn/site/zoneMergeStarted.html (original)
+++ brooklyn/site/zoneMergeStarted.html Fri Feb 10 17:04:25 2017
@@ -541,13 +541,15 @@ Extract this zip file to a directory on
---
-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:
+By default, no authentication is required and the web-console will listen on all network interfaces.
+For a production system, or if Apache Brooklyn is publicly reachable, it is strongly recommended
+to configure security. Documentation of configuration options include:
* [Security]({{ site.path.guide }}/ops/brooklyn_properties.html)
* [Persistence]({{ site.path.guide }}/ops/persistence/)
* [Cloud credentials]({{ site.path.guide }}/ops/locations/)
+
## Launch Apache Brooklyn
<ul class="nav nav-tabs">
@@ -594,7 +596,7 @@ The application should then output its l
<strong class="hidden started-pdf-include">c) Ubuntu / Debian</strong>
-Apache Brooklyn should now have been installed and be running as a system service. It can stopped and started with the standard service commands:
+Apache Brooklyn should now have been installed and be running as a system service. It can be stopped and started with the standard service commands:
{% highlight bash %}
$ sudo service brooklyn start|stop|restart|status
@@ -1500,8 +1502,8 @@ services:
name: Cluster
id: cluster
brooklyn.config:
- initialSize: 1
- memberSpec:
+ cluster.initial.size: 1
+ dynamiccluster.memberspec:
$brooklyn:entitySpec:
type: org.apache.brooklyn.entity.webapp.tomcat.TomcatServer
name: Tomcat Server
@@ -1609,8 +1611,8 @@ services:
name: Cluster
id: cluster
brooklyn.config:
- initialSize: 1
- memberSpec:
+ cluster.initial.size: 1
+ dynamiccluster.memberspec:
$brooklyn:entitySpec:
type: org.apache.brooklyn.entity.webapp.tomcat.TomcatServer
name: Tomcat Server
@@ -1748,7 +1750,7 @@ The `DynamicCluster` can dynamically inc
cluster can either be carried out manually via effectors or automatically by attaching an
`AutoScalerPolicy`.
-It is configured with a `memberSpec`, which defines the type and configurtion of members
+It is configured with a `dynamiccluster.memberspec`, which defines the type and configurtion of members
in the cluster. In our example, each is a Tomcat server with a WAR deployed at the root URL.
Deploy the app: