Mailing-List: contact dev-help@brooklyn.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@brooklyn.apache.org
From: shartzel <git@git.apache.org>
To: dev@brooklyn.incubator.apache.org
Reply-To: dev@brooklyn.incubator.apache.org
References: <git-pr-1116-incubator-brooklyn@git.apache.org>
In-Reply-To: <git-pr-1116-incubator-brooklyn@git.apache.org>
Subject: [GitHub] incubator-brooklyn pull request: DO NOT MERGE - "Getting
 Started" ...
Content-Type: text/plain
Message-Id: <20151221195637.15157E04AF@git1-us-west.apache.org>
Date: Mon, 21 Dec 2015 19:56:37 +0000 (UTC)

Github user shartzel commented on a diff in the pull request:

    https://github.com/apache/incubator-brooklyn/pull/1116#discussion_r48184016
  
    --- Diff: docs/guide/start/policies-cli.md ---
    @@ -0,0 +1,172 @@
    +---
    +title: Getting Started - Policies
    +title_in_menu: Policies
    +layout: website-normal
    +menu-parent: index-cli.md
    +---
    +
    +
    +
    +
    +## A Clustered Example
    +
    +We'll now look at a more complex example that better shows the capabilities of Brooklyn. 
    +
    +We'll start by deploying an application via YAML blueprint consisting of the following layers.
    +
    +- A dynamically scalable Web App Cluster
    +- A MySQL DB
    +
    +
    +Copy the blueprint below into a text file, "mycluster.yaml", in your workspace, but *before* you create an application 
    +with it, again modify the YAML to specify the location where the application will be deployed.  
    +You will need at least five machines for this example, one for the DB, and four for the tomcats 
    +(but you can reduce this by changing the "maxPoolSize" below.
    +
    +{% highlight yaml %}
    +name: cluster
    +
    +location:
    +  tbd
    +
    +services:
    +- serviceType: brooklyn.entity.webapp.ControlledDynamicWebAppCluster
    +  name: webcluster
    +  brooklyn.config:
    +    wars.root: http://search.maven.org/remotecontent?filepath=io/brooklyn/example/brooklyn-example-hello-world-sql-webapp/0.6.0-M2/brooklyn-example-hello-world-sql-webapp-0.6.0-M2.war
    +    http.port: 9280+
    +    proxy.http.port: 9210+
    +    java.sysprops: 
    +      brooklyn.example.db.url: $brooklyn:formatString("jdbc:%s%s?user=%s\\&password=%s",
    +         component("db").attributeWhenReady("datastore.url"), "visitors", "brooklyn", "br00k11n")
    +  brooklyn.policies:
    +  - policyType: brooklyn.policy.autoscaling.AutoScalerPolicy
    +    brooklyn.config:
    +      metric: $brooklyn:sensor("brooklyn.entity.webapp.DynamicWebAppCluster", "webapp.reqs.perSec.windowed.perNode")
    +      metricLowerBound: 10
    +      metricUpperBound: 100
    +      minPoolSize: 1
    +      maxPoolSize: 4
    +      
    +- serviceType: brooklyn.entity.database.mysql.MySqlNode
    +  id: db
    +  name: mysql
    +  location: localhost
    +  brooklyn.config:
    +    creationScriptUrl: https://bit.ly/brooklyn-visitors-creation-script
    +{% endhighlight %}
    +
    +Explore this app using the 'application' and other commands from the previous section.
    +
    +## Configuring Dependencies
    +The App above illustrates how one component in a blueprint can be configured with information relating to one of the other 
    +components in the blueprint.  In this example the web cluster is configured with a URL for JDBC connections to the database.
    +{% highlight yaml %}
    +java.sysprops: 
    +      brooklyn.example.db.url: $brooklyn:formatString("jdbc:%s%s?user=%s\\&password=%s",
    +         component("db").attributeWhenReady("datastore.url"), "visitors", "brooklyn", "br00k11n")
    +{% endhighlight %}
    +
    +the syntax ```$brooklyn:formatString(...)``` is an example of the Brooklyn DSL (Domain Specific Language) which 
    +allows expressions referring to Brooklyn's management information to be embedded in blueprints.  The line above also illustrates the use of Brooklyn's ```component(...)``` and ```attributeWhenReady(...)``` to get an identified component from a deployment, and to wait until the component is fully deployed before reading one of its sensors ("datastore.url" in this case). 
    +
    +## Managing with Policies
    +
    +
    +The app server cluster has an `AutoScalerPolicy`and the loadbalancer has a `Controller targets tracker` policy.
    +
    +For example
    +{% highlight yaml %}
    +$ br app cluster ent webcluster policy
    +Id         Name                                                      State   
    +mMZngBnb   org.apache.brooklyn.policy.autoscaling.AutoScalerPolicy   RUNNING   
    +{% endhighlight %}
    +
    +You can investigate the status of the `AutoScalerPolicy` with 
    +
    +{% highlight yaml %}
    +$ br app cluster ent webcluster policy org.apache.brooklyn.policy.autoscaling.AutoScalerPolicy
    +"RUNNING"
    +{% endhighlight %}
    +
    +A more detailed description of the parameters of the policy can be obtained with
    +{% highlight yaml %}
    +$ br app cluster ent webcluster policy org.apache.brooklyn.policy.autoscaling.AutoScalerPolicy
    --- End diff --
    
    should there be a PolicyID at the EOL here?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---