http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/example_yaml/vanilla-bash-netcat-w-client.yaml ---------------------------------------------------------------------- diff --git a/brooklyn-docs/guide/yaml/example_yaml/vanilla-bash-netcat-w-client.yaml b/brooklyn-docs/guide/yaml/example_yaml/vanilla-bash-netcat-w-client.yaml deleted file mode 100644 index 78ed99e..0000000 --- a/brooklyn-docs/guide/yaml/example_yaml/vanilla-bash-netcat-w-client.yaml +++ /dev/null @@ -1,78 +0,0 @@ -name: Netcat Example with Client - -location: localhost - -services: - -# the netcat server instance, running in listener mode (-l) -- type: org.apache.brooklyn.entity.software.base.VanillaSoftwareProcess - id: netcat-server - name: Simple Netcat Server - launch.command: | - echo hello | nc -l 4321 >> server-input & - echo $! > $PID_FILE - - # a failure detector and a service restarter work together - brooklyn.enrichers: - - type: org.apache.brooklyn.policy.ha.ServiceFailureDetector - brooklyn.config: - # wait 15s after service fails before propagating failure - serviceFailedStabilizationDelay: 15s - - brooklyn.policies: - - type: org.apache.brooklyn.policy.ha.ServiceRestarter - brooklyn.config: - # repeated failures in a time window can cause the restarter to abort, - # propagating the failure; a time window of 0 will mean it always restarts! - failOnRecurringFailuresInThisDuration: 0 - - brooklyn.initializers: - # two sensors, recording the data sent to this netcat server: - - - type: org.apache.brooklyn.core.sensor.ssh.SshCommandSensor - brooklyn.config: - name: output.last - period: 1s - command: tail -1 server-input - - - type: org.apache.brooklyn.core.sensor.ssh.SshCommandSensor - brooklyn.config: - name: output.all - period: 1s - command: cat server-input - -# a client to hit netcat -- type: org.apache.brooklyn.entity.software.base.VanillaSoftwareProcess - name: Simple Pinger - - # set the hostname of the netcat instance as an env var for the scripts - env: - TARGET_HOSTNAME: - $brooklyn:component("netcat-server"). - attributeWhenReady("host.name") - - # start/check/stop are no-op - launch.command: "" - checkRunning.command: "" - stop.command: "" - - brooklyn.initializers: - # but there is a sample effector which runs nc in client mode - - - type: org.apache.brooklyn.core.effector.ssh.SshCommandEffector - brooklyn.config: - name: sayHiNetcat - description: Echo a small hello string to the netcat entity - command: | - echo $message | nc $TARGET_HOSTNAME 4321 - parameters: - message: - description: The string to pass to netcat - defaultValue: hi netcat - -# and add an enricher at the root so all sensors from netcat-server are visible on the root -brooklyn.enrichers: -- enricherType: org.apache.brooklyn.enricher.stock.Propagator - brooklyn.config: - enricher.producer: $brooklyn:component("netcat-server") - enricher.propagating.propagatingAll: true
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/example_yaml/vanilla-bash-netcat.yaml ---------------------------------------------------------------------- diff --git a/brooklyn-docs/guide/yaml/example_yaml/vanilla-bash-netcat.yaml b/brooklyn-docs/guide/yaml/example_yaml/vanilla-bash-netcat.yaml deleted file mode 100644 index df616af..0000000 --- a/brooklyn-docs/guide/yaml/example_yaml/vanilla-bash-netcat.yaml +++ /dev/null @@ -1,8 +0,0 @@ -name: Simple Netcat Server Example -location: localhost -services: -- type: org.apache.brooklyn.entity.software.base.VanillaSoftwareProcess - name: Simple Netcat Server - launch.command: | - echo hello | nc -l 4321 & - echo $! > $PID_FILE http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/index.md ---------------------------------------------------------------------- diff --git a/brooklyn-docs/guide/yaml/index.md b/brooklyn-docs/guide/yaml/index.md deleted file mode 100644 index 792d9a0..0000000 --- a/brooklyn-docs/guide/yaml/index.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: YAML Blueprints -layout: website-normal -children: -- creating-yaml.md -- setting-locations.md -- configuring-vms.md -- clusters.md -- multiple-services.md -- clusters-and-policies.md -- blueprinting-tips.md -- custom-entities.md -- winrm/ -- chef/ -- test/ -- advanced-example.md -- { path: yaml-reference.md, title: YAML Blueprint Reference } -- { link: 'https://github.com/brooklyncentral/blueprint-library', title: 'GitHub Blueprint Library' } ---- - - -{% include list-children.html %} http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/multiple-services.md ---------------------------------------------------------------------- diff --git a/brooklyn-docs/guide/yaml/multiple-services.md b/brooklyn-docs/guide/yaml/multiple-services.md deleted file mode 100644 index 81ddf07..0000000 --- a/brooklyn-docs/guide/yaml/multiple-services.md +++ /dev/null @@ -1,97 +0,0 @@ ---- -title: Multiple Services and Dependency Injection -layout: website-normal ---- - -We've seen the configuration of machines and how to build up clusters. -Now let's return to our app-server example and explore how more interesting -services can be configured, composed, and combined. - - -### Service Configuration - -We'll begin by using more key-value pairs to configure the JBoss server to run a real app: - -{% highlight yaml %} -{% readj example_yaml/appserver-configured.yaml %} -{% endhighlight %} - -(As before, you'll need to add the `location` info; `localhost` will work for these and subsequent examples.) - -When this is deployed, you can see management information in the Brooklyn Web Console, -including a link to the deployed application (downloaded to the target machine from the `hello-world` URL), -running on port 8080. - -**Tip**: If port 8080 might be in use, you can specify `8080+` to take the first available port >= 8080; -the actual port will be reported as a sensor by Brooklyn. - -It's also worth indicating an alternate, more formal syntax. -Not all configuration on entities is supported at the top level of the service specification -(only those which are defined as "flags" in the underlying blueprint, -e.g. the `@SetFromFlag("war")` in the `WebAppServiceConstants` parent of `JBoss7Server`). -All configuration has a formal qualified name, and this can be supplied even where flags or config keys are not -explicitly defined, by placing it into a `brooklyn.config` section: - -{% highlight yaml %} -{% readj example_yaml/appserver-configured-in-config.yaml %} -{% endhighlight %} - - -### Multiple Services - -If you explored the `hello-world-sql` application we just deployed, -you'll have noticed it tries to access a database. -And it fails, because we have not set one up. Let's do that now: - -{% highlight yaml %} -{% readj example_yaml/appserver-w-db.yaml %} -{% endhighlight %} - -Here there are a few things going on: - -* We've added a second service, which will be the database; - you'll note the database has been configured to run a custom setup script -* We've injected the URL of the second service into the appserver as a Java system property - (so our app knows where to find the database) - -**Caution: Be careful if you write your YAML in an editor which attempts to put "smart-quotes" in. -All quote characters must be plain ASCII, not fancy left-double-quotes and right-double-quotes!** - -There are as many ways to do dependency injection as there are developers, -it sometimes seems; our aim in Brooklyn is not to say this has to be done one way, -but to support the various mechanisms people might need, for whatever reasons. -(We each have our opinions about what works well, of course; -the one thing we do want to call out is that being able to dynamically update -the injection is useful in a modern agile application -- so we are definitively **not** -recommending this Java system property approach ... but it is an easy one to demo!) - -The way the dependency injection works is again by using the `$brooklyn:` DSL, -this time referring to the `component("db")` (looked up by the `id` field on our DB component), -and then to a sensor emitted by that component. -All the database entities emit a `database.url` sensor when they are up and running; -the `attributeWhenReady` DSL method will store a pointer to that sensor (a Java Future under the covers) -in the Java system properties map which the JBoss entity reads at launch time, blocking if needed. - -This means that the deployment occurs in parallel, and if the database comes up first, -there is no blocking; but if the JBoss entity completes its installation and -downloading the WAR, it will wait for the database before it launches. -At that point the URL is injected, first passing it through `formatString` -to include the credentials for the database (which are defined in the database creation script). - - -### An Aside: Substitutability - -Don't like JBoss? Is there something about Maria? -One of the modular principles we follow in Brooklyn is substitutability: -in many cases, the config keys, sensors, and effectors are defined -in superclasses and are portable across multiple implementations. - -Here's an example deploying the same application but with different flavors of the components: - -{% highlight yaml %} -{% readj example_yaml/appserver-w-db-other-flavor.yaml %} -{% endhighlight %} - -We've also brought in the `provisioning.properties` from the VM example earlier -so our database has 8GB RAM. -Any of those properties, including `imageId` and `user`, can be defined on a per-entity basis. http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/setting-locations.md ---------------------------------------------------------------------- diff --git a/brooklyn-docs/guide/yaml/setting-locations.md b/brooklyn-docs/guide/yaml/setting-locations.md deleted file mode 100644 index ab92369..0000000 --- a/brooklyn-docs/guide/yaml/setting-locations.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -title: Setting Locations -layout: website-normal -toc: ../guide_toc.json -categories: [use, guide, defining-applications] ---- - -{% include fields.md %} - -Brooklyn supports a very wide range of target locations -- localhost is mainly a convenience for testing. -With deep integration to [Apache jclouds](http://jclouds.org), most well-known clouds and cloud platforms are supported. -The following example is for Amazon EC2: - -{% highlight yaml %} -{% readj example_yaml/simple-appserver-with-location.yaml %} -{% endhighlight %} - -(You'll need to replace the `identity` and `credential` with the -"Access Key ID" and "Secret Access Key" for your account, -as configured in the [AWS Console](https://console.aws.amazon.com/iam/home?#security_credential).) - -Other popular public clouds include `softlayer`, `google-compute-engine`, and `rackspace-cloudservers-us`. -Private cloud systems including `openstack-nova` and `cloudstack` are also supported, -although for these you'll supply an `endpoint: https://9.9.9.9:9999/v2.0/` -(or `client/api/` in the case of CloudStack) instead of the `region`. - -You can also specify pre-existing servers to use -- "bring-your-own-nodes". -These can be a global pool or specific to a service. -Both styles are shown here (though normally only one will be selected, -<!-- TODO see #1377, currently it is *parent* location which is preferred typically --> -depending on the blueprint): - -{% highlight yaml %} -{% readj example_yaml/simple-appserver-with-location-byon.yaml %} -{% endhighlight %} - -Note in this example that we've used JSON-style notation in the second `location` block. -YAML supports this, and sometimes that makes more readable plans. -(Although in this case a simple `location: localhost` is equivalent and even more succinct, -but this is a tutorial.) - -For more information see the [Operations: Locations]({{ site.path.guide }}/ops/locations) section of the User Guide. -This includes support for defining locations externally in a [brooklyn.properties]({{ brooklyn_properties_url_path }}) file, -after which you can deploy to clouds or bring-your-own-nodes -simply as `location: jclouds:aws-ec2:eu-west-1` or `location: named:my_cloudstack`. http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/test/example_yaml/entities/infrastructuredeploymenttestcase-entity.yaml ---------------------------------------------------------------------- diff --git a/brooklyn-docs/guide/yaml/test/example_yaml/entities/infrastructuredeploymenttestcase-entity.yaml b/brooklyn-docs/guide/yaml/test/example_yaml/entities/infrastructuredeploymenttestcase-entity.yaml deleted file mode 100644 index 6b344da..0000000 --- a/brooklyn-docs/guide/yaml/test/example_yaml/entities/infrastructuredeploymenttestcase-entity.yaml +++ /dev/null @@ -1,11 +0,0 @@ -- type: org.apache.brooklyn.test.framework.InfrastructureDeploymentTestCase - brooklyn.config: - infrastructure.deployment.location.sensor: entity.dynamicLocation - infrastructure.deployment.spec: - $brooklyn:entitySpec: - - type: docker-cloud-calico - ... - infrastructure.deployment.entity.specs: - - $brooklyn:entitySpec: - type: org.apache.brooklyn.entity.software.base.VanillaSoftwareProcess - ... \ No newline at end of file http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/test/example_yaml/entities/loopovergroupmembers-entity.yaml ---------------------------------------------------------------------- diff --git a/brooklyn-docs/guide/yaml/test/example_yaml/entities/loopovergroupmembers-entity.yaml b/brooklyn-docs/guide/yaml/test/example_yaml/entities/loopovergroupmembers-entity.yaml deleted file mode 100644 index e97ab4c..0000000 --- a/brooklyn-docs/guide/yaml/test/example_yaml/entities/loopovergroupmembers-entity.yaml +++ /dev/null @@ -1,6 +0,0 @@ -- type: org.apache.brooklyn.test.framework.LoopOverGroupMembersTestCase - target: $brooklyn:component("infrastructure").component("child", "DockerHosts") - testSpec: - $brooklyn:entitySpec: - type: org.apache.brooklyn.test.framework.TestSensor - ... \ No newline at end of file http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/test/example_yaml/entities/paralleltestcase-entity.yaml ---------------------------------------------------------------------- diff --git a/brooklyn-docs/guide/yaml/test/example_yaml/entities/paralleltestcase-entity.yaml b/brooklyn-docs/guide/yaml/test/example_yaml/entities/paralleltestcase-entity.yaml deleted file mode 100644 index ccd0c0b..0000000 --- a/brooklyn-docs/guide/yaml/test/example_yaml/entities/paralleltestcase-entity.yaml +++ /dev/null @@ -1,6 +0,0 @@ -- type: org.apache.brooklyn.test.framework.ParallelTestCase - brooklyn.children: - - type: org.apache.brooklyn.entity.database.mysql.MySqlNode - ... - - type: org.apache.brooklyn.entity.webapp.ControlledDynamicWebAppCluster - ... \ No newline at end of file http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/test/example_yaml/entities/script1.sh ---------------------------------------------------------------------- diff --git a/brooklyn-docs/guide/yaml/test/example_yaml/entities/script1.sh b/brooklyn-docs/guide/yaml/test/example_yaml/entities/script1.sh deleted file mode 100644 index 2a98304..0000000 --- a/brooklyn-docs/guide/yaml/test/example_yaml/entities/script1.sh +++ /dev/null @@ -1,2 +0,0 @@ -#!/bin/sh -echo hello world \ No newline at end of file http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/test/example_yaml/entities/simpleshellcommandtest-entity.yaml ---------------------------------------------------------------------- diff --git a/brooklyn-docs/guide/yaml/test/example_yaml/entities/simpleshellcommandtest-entity.yaml b/brooklyn-docs/guide/yaml/test/example_yaml/entities/simpleshellcommandtest-entity.yaml deleted file mode 100644 index 3e14aa5..0000000 --- a/brooklyn-docs/guide/yaml/test/example_yaml/entities/simpleshellcommandtest-entity.yaml +++ /dev/null @@ -1,24 +0,0 @@ -- type: org.apache.brooklyn.test.framework.TestCase - name: testcase1 - targetId: testprocess - brooklyn.children: - - type: org.apache.brooklyn.entity.webapp.tomcat.TomcatServer - id: testprocess - - - type: org.apache.brooklyn.test.framework.SimpleShellCommandTest - command: ps -ef - assertStatus: - equals: 0 - assertOut: - contains: tomcat - assertErr: - isEmpty: true - - - type: org.apache.brooklyn.test.framework.SimpleShellCommandTest - downloadUrl: https://raw.githubusercontent.com/apache/incubator-brooklyn/master/docs/guide/yaml/test/entities/script1.sh - assertStatus: - equals: 0 - assertOut: - equals: hello world - assertErr: - isEmpty: true http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/test/example_yaml/entities/testcase-entity.yaml ---------------------------------------------------------------------- diff --git a/brooklyn-docs/guide/yaml/test/example_yaml/entities/testcase-entity.yaml b/brooklyn-docs/guide/yaml/test/example_yaml/entities/testcase-entity.yaml deleted file mode 100644 index 0e1aa00..0000000 --- a/brooklyn-docs/guide/yaml/test/example_yaml/entities/testcase-entity.yaml +++ /dev/null @@ -1,6 +0,0 @@ -- type: org.apache.brooklyn.test.framework.TestCase - brooklyn.children: - - type: org.apache.brooklyn.entity.database.mysql.MySqlNode - ... - - type: org.apache.brooklyn.test.framework.TestSensor - ... \ No newline at end of file http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/test/example_yaml/entities/testeffector-entity.yaml ---------------------------------------------------------------------- diff --git a/brooklyn-docs/guide/yaml/test/example_yaml/entities/testeffector-entity.yaml b/brooklyn-docs/guide/yaml/test/example_yaml/entities/testeffector-entity.yaml deleted file mode 100644 index d86fe54..0000000 --- a/brooklyn-docs/guide/yaml/test/example_yaml/entities/testeffector-entity.yaml +++ /dev/null @@ -1,8 +0,0 @@ -- type: org.apache.brooklyn.test.framework.TestEffector - name: Invoke Deploy Effector - target: $brooklyn:component("tomcat") - effector: deploy - timeout: 5m - params: - url: http://search.maven.org/remotecontent?filepath=io/brooklyn/example/brooklyn-example-hello-world-sql-webapp/0.6.0/brooklyn-example-hello-world-sql-webapp-0.6.0.war - targetName: newcontext \ No newline at end of file http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/test/example_yaml/entities/testhttpcall-entity.yaml ---------------------------------------------------------------------- diff --git a/brooklyn-docs/guide/yaml/test/example_yaml/entities/testhttpcall-entity.yaml b/brooklyn-docs/guide/yaml/test/example_yaml/entities/testhttpcall-entity.yaml deleted file mode 100644 index bdb3347..0000000 --- a/brooklyn-docs/guide/yaml/test/example_yaml/entities/testhttpcall-entity.yaml +++ /dev/null @@ -1,7 +0,0 @@ -- type: org.apache.brooklyn.test.framework.TestHttpCall - name: Check HTTP Response Status Code - url: $brooklyn:component("tomcat").attributeWhenReady("webapp.url") - timeout: 60s - applyAssertionTo: status - assert: - - isEqualTo: 200 \ No newline at end of file http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/test/example_yaml/entities/testsensor-entity.yaml ---------------------------------------------------------------------- diff --git a/brooklyn-docs/guide/yaml/test/example_yaml/entities/testsensor-entity.yaml b/brooklyn-docs/guide/yaml/test/example_yaml/entities/testsensor-entity.yaml deleted file mode 100644 index e781d0d..0000000 --- a/brooklyn-docs/guide/yaml/test/example_yaml/entities/testsensor-entity.yaml +++ /dev/null @@ -1,7 +0,0 @@ -- type: org.apache.brooklyn.test.framework.TestSensor - name: Check tomcat isUp - target: $brooklyn:component("tomcat") - sensor: service.isUp - timeout: 10m - assert: - - equals: true \ No newline at end of file http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/test/example_yaml/testcases/effector-test-snippet.yaml ---------------------------------------------------------------------- diff --git a/brooklyn-docs/guide/yaml/test/example_yaml/testcases/effector-test-snippet.yaml b/brooklyn-docs/guide/yaml/test/example_yaml/testcases/effector-test-snippet.yaml deleted file mode 100644 index 469b54b..0000000 --- a/brooklyn-docs/guide/yaml/test/example_yaml/testcases/effector-test-snippet.yaml +++ /dev/null @@ -1,28 +0,0 @@ -- type: org.apache.brooklyn.test.framework.TestCase - name: Check Deploy Effector - brooklyn.children: - - type: org.apache.brooklyn.test.framework.TestSensor - name: Check webappcluster isUp - targetId: webappcluster - sensor: service.isUp - timeout: 10m - assert: - - equals: true - - type: org.apache.brooklyn.test.framework.TestEffector - name: Invoke Deploy Effector - targetId: webappcluster - effector: deploy - timeout: 5m - params: - url: http://search.maven.org/remotecontent?filepath=io/brooklyn/example/brooklyn-example-hello-world-sql-webapp/0.6.0/brooklyn-example-hello-world-sql-webapp-0.6.0.war - targetName: newcontext - - type: org.apache.brooklyn.test.framework.TestHttpCall - name: Check Deployed Webapp Status Code - timeout: 5m - url: > - $brooklyn:formatString("http://%s:%s/newcontext/";, - $brooklyn:component("webappcluster").attributeWhenReady("host.address"), - $brooklyn:component("webappcluster").attributeWhenReady("proxy.http.port")) - applyAssertionTo: status - assert: - - isEqualTo: 200 \ No newline at end of file http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/test/example_yaml/testcases/getting-started-test-example.yaml ---------------------------------------------------------------------- diff --git a/brooklyn-docs/guide/yaml/test/example_yaml/testcases/getting-started-test-example.yaml b/brooklyn-docs/guide/yaml/test/example_yaml/testcases/getting-started-test-example.yaml deleted file mode 100644 index 25296e6..0000000 --- a/brooklyn-docs/guide/yaml/test/example_yaml/testcases/getting-started-test-example.yaml +++ /dev/null @@ -1,71 +0,0 @@ -name: Getting Started Blueprint Test - -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=io/brooklyn/example/brooklyn-example-hello-world-sql-webapp/0.6.0/brooklyn-example-hello-world-sql-webapp-0.6.0.war - java.sysprops: - brooklyn.example.db.url: > - $brooklyn:formatString("jdbc:%s%s?user=%s&password=%s", - component("db").attributeWhenReady("datastore.url"), - "visitors", "brooklyn", "br00k11n") -- type: org.apache.brooklyn.entity.database.mysql.MySqlNode - id: db - name: My DB - brooklyn.config: - creationScriptUrl: https://bit.ly/brooklyn-visitors-creation-script -- type: org.apache.brooklyn.test.framework.TestHttpCall - name: Check HTTP Response Status Code - url: > - $brooklyn:formatString("http://%s:%s";, - $brooklyn:component("webappcluster").attributeWhenReady("host.address"), - $brooklyn:component("webappcluster").attributeWhenReady("proxy.http.port")) - timeout: 10m - applyAssertionTo: status - assert: - - isEqualTo: 200 -- type: org.apache.brooklyn.test.framework.TestHttpCall - name: Check HTTP Response Body - url: > - $brooklyn:formatString("http://%s:%s";, - $brooklyn:component("webappcluster").attributeWhenReady("host.address"), - $brooklyn:component("webappcluster").attributeWhenReady("proxy.http.port")) - timeout: 10m - applyAssertionTo: body - assert: - - matches: "(?s).*Br[o]{2}klyn Deployed.*" -- type: org.apache.brooklyn.test.framework.TestCase - name: Check Deploy Effector - brooklyn.children: - - type: org.apache.brooklyn.test.framework.TestSensor - name: Check webappcluster isUp - targetId: webappcluster - sensor: service.isUp - timeout: 10m - assert: - - equals: true - - type: org.apache.brooklyn.test.framework.TestEffector - name: Invoke Deploy Effector - targetId: webappcluster - effector: deploy - timeout: 5m - params: - url: http://search.maven.org/remotecontent?filepath=io/brooklyn/example/brooklyn-example-hello-world-sql-webapp/0.6.0/brooklyn-example-hello-world-sql-webapp-0.6.0.war - targetName: newcontext - - type: org.apache.brooklyn.test.framework.TestHttpCall - name: Check Deployed Webapp Status Code - timeout: 5m - url: > - $brooklyn:formatString("http://%s:%s/newcontext/";, - $brooklyn:component("webappcluster").attributeWhenReady("host.address"), - $brooklyn:component("webappcluster").attributeWhenReady("proxy.http.port")) - applyAssertionTo: status - assert: - - isEqualTo: 200 \ No newline at end of file http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/test/example_yaml/testcases/http-test-snippet.yaml ---------------------------------------------------------------------- diff --git a/brooklyn-docs/guide/yaml/test/example_yaml/testcases/http-test-snippet.yaml b/brooklyn-docs/guide/yaml/test/example_yaml/testcases/http-test-snippet.yaml deleted file mode 100644 index 0a7a953..0000000 --- a/brooklyn-docs/guide/yaml/test/example_yaml/testcases/http-test-snippet.yaml +++ /dev/null @@ -1,20 +0,0 @@ -- type: org.apache.brooklyn.test.framework.TestHttpCall - name: Check HTTP Response Status Code - url: > - $brooklyn:formatString("http://%s:%s/newcontext/";, - $brooklyn:component("webappcluster").attributeWhenReady("host.address"), - $brooklyn:component("webappcluster").attributeWhenReady("proxy.http.port")) - timeout: 10m - applyAssertionTo: status - assert: - - equals: 200 -- type: org.apache.brooklyn.test.framework.TestHttpCall - name: Check HTTP Response Body - url: > - $brooklyn:formatString("http://%s:%s/newcontext/";, - $brooklyn:component("webappcluster").attributeWhenReady("host.address"), - $brooklyn:component("webappcluster").attributeWhenReady("proxy.http.port")) - timeout: 10m - applyAssertionTo: body - assert: - - matches: "(?s).*Br[o]{2}klyn Deployed.*" \ No newline at end of file http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/test/example_yaml/testcases/sensor-test-snippet.yaml ---------------------------------------------------------------------- diff --git a/brooklyn-docs/guide/yaml/test/example_yaml/testcases/sensor-test-snippet.yaml b/brooklyn-docs/guide/yaml/test/example_yaml/testcases/sensor-test-snippet.yaml deleted file mode 100644 index da58cd1..0000000 --- a/brooklyn-docs/guide/yaml/test/example_yaml/testcases/sensor-test-snippet.yaml +++ /dev/null @@ -1,7 +0,0 @@ -- type: org.apache.brooklyn.test.framework.TestSensor - name: Check webappcluster isUp - targetId: webappcluster - sensor: service.isUp - timeout: 10m - assert: - - equals: true \ No newline at end of file http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/test/images/getting-started-blueprint-test-large.png ---------------------------------------------------------------------- diff --git a/brooklyn-docs/guide/yaml/test/images/getting-started-blueprint-test-large.png b/brooklyn-docs/guide/yaml/test/images/getting-started-blueprint-test-large.png deleted file mode 100644 index 655e4f0..0000000 Binary files a/brooklyn-docs/guide/yaml/test/images/getting-started-blueprint-test-large.png and /dev/null differ http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/test/images/getting-started-blueprint-test.png ---------------------------------------------------------------------- diff --git a/brooklyn-docs/guide/yaml/test/images/getting-started-blueprint-test.png b/brooklyn-docs/guide/yaml/test/images/getting-started-blueprint-test.png deleted file mode 100644 index 09d23e8..0000000 Binary files a/brooklyn-docs/guide/yaml/test/images/getting-started-blueprint-test.png and /dev/null differ http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/test/index.md ---------------------------------------------------------------------- diff --git a/brooklyn-docs/guide/yaml/test/index.md b/brooklyn-docs/guide/yaml/test/index.md deleted file mode 100644 index 02482b7..0000000 --- a/brooklyn-docs/guide/yaml/test/index.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: Testing YAML Blueprints -layout: website-normal -children: -- test-entities.md -- usage-examples.md ---- - -Brooklyn provides a selection of test entities which can be used to validate Blueprints via YAML. The basic building block is a TargetableTestComponent, which is used to resolve a target. There are two different groups of entities that inherit from TargetableTestComponent. The first is structural, which effects how the tests are run, for example by affecting the order they are run in. The second group is validation, which is used to confirm the application is deployed as intended, for example by checking some sensor value. - -Structural test entities include: - -- `TestCase` - starts child entities sequentially. -- `ParallelTestCase` - starts child entities in parallel. -- `LoopOverGroupMembersTestCase` - creates a TargetableTestComponent for each member of a group. -- `InfrastructureDeploymentTestCase` - will create the specified Infrastructure and then deploy the target entity specifications there. - -Validation test entities include: - -- `TestSensor` - perform assertion on a specified sensor. -- `TestEffector` - perform assertion on response to effector call. -- `TestHttpCall` - perform assertion on response to specified HTTP GET Request. -- `SimpleShellCommandTest` - test assertions on the result of a shell command on the same node as the target entity. - -TargetableTestComponents can be chained together, with the target being inherited by the components children. For example, a ParallelTestCase could be created that has a TestHttpCall as a child. As long as the TestHttpCall itself does not have a target, it will use the target of it's parent, ParallelTestCase. Using this technique, we can build up complex test scenarios. - -The following sections provide details on each test entity along with examples of their use. - -{% include list-children.html %} http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/test/test-entities.md ---------------------------------------------------------------------- diff --git a/brooklyn-docs/guide/yaml/test/test-entities.md b/brooklyn-docs/guide/yaml/test/test-entities.md deleted file mode 100644 index a81a3d6..0000000 --- a/brooklyn-docs/guide/yaml/test/test-entities.md +++ /dev/null @@ -1,156 +0,0 @@ ---- -title: Blueprint Test Entities -title_in_menu: Test Entities -layout: website-normal ---- - -{% include fields.md %} - - -## Structural Test Entities - -### TestCase -The `TestCase` entity acts as a container for a list of child entities which are started *sequentially*. - -{% highlight yaml %} -{% readj example_yaml/entities/testcase-entity.yaml %} -{% endhighlight %} - -This can be used to enforce a strict ordering, for example ensuring a sensor has a certain value before attempting to invoke an effector. - -Timeouts on child entities should be set relative to the completion of the preceding entity. - -The `ParallelTestCase` entity can be added as a child to run a subset of entities in parallel as a single step. - -### ParallelTestCase -The `ParallelTestCase` entity acts as a container for a list of child entities which are started in *parallel*. - -{% highlight yaml %} -{% readj example_yaml/entities/paralleltestcase-entity.yaml %} -{% endhighlight %} - -This can be used to run a subset of entities in parallel as a single step when nested under a `TestCase` entity. - -Timeouts on child entities should be set relative to the start of the `ParallelTestCase`. - -### LoopOverGroupMembersTestCase -The `LoopOverGroupMembersTestCase` entity is configured with a target group and a test specification. For each member of the targeted group, the test case will create a TargetableTestComponent entity from the supplied test specification and set the components target to be the group member. - -{% highlight yaml %} -{% readj example_yaml/entities/loopovergroupmembers-entity.yaml %} -{% endhighlight %} - -#### Parameters -- `target` - group who's members are to be tested, specified via DSL. For example, `$brooklyn:component("tomcat")`. See also the `targetId` parameter. -- `targetId` - alternative to the `target` parameter which wraps the DSL component lookup requiring only the `id` be supplied. For example, `tomcat`. Please note, this must point to a group. -- `test.spec` - The TargetableTestComponent to create for each child. - - -### InfrastructureDeploymentTestCase -The `InfrastructureDeploymentTestCase` will first create and deploy an infrastructure from the `infrastructure.deployment.spec` config. It will then retrieve a deployment location by getting the value of the infrastructures `infrastructure.deployment.location.sensor` sensor. It will then create and deploy all entities from the `infrastructure.deployment.spec` config to the deployment location. - -{% highlight yaml %} -{% readj example_yaml/entities/infrastructuredeploymenttestcase-entity.yaml %} -{% endhighlight %} - -#### Parameters - -- `infrastructure.deployment.spec` - the infrastructure to be deployed. -- `infrastructure.deployment.entity.specs` - the entities to be deployed to the infrastructure -- `infrastructure.deployment.location.sensor` - the name of the sensor on the infrastructure to retrieve the deployment location - -## Validation Test Entities - -### TestSensor -The `TestSensor` entity performs an assertion on a specified sensors value. - -{% highlight yaml %} -{% readj example_yaml/entities/testsensor-entity.yaml %} -{% endhighlight %} - -#### Parameters -- `target` - entity whose sensor will be tested, specified via DSL. For example, `$brooklyn:component("tomcat")`. See also the `targetId` parameter. -- `targetId` - alternative to the `target` parameter which wraps the DSL component lookup requiring only the `id` be supplied. For example, `tomcat`. -- `sensor` - sensor to evaluate. For example `service.isUp`. -- `timeout` - duration to wait on assertion to return a result. For example `10s`, `10m`, etc -- `assert` - assertion to perform on the specified sensor value. See section on assertions below. - -### TestEffector -The `TestEffector` entity invokes the specified effector on a target entity. If the result of the effector is a String, it will then perform assertions on the result. -{% highlight yaml %} -{% readj example_yaml/entities/testeffector-entity.yaml %} -{% endhighlight %} - -#### Parameters -- `target` - entity whose effector will be invoked, specified via DSL. For example, `$brooklyn:component("tomcat")`. See also the `targetId` parameter. -- `targetId` - alternative to the `target` parameter which wraps the DSL component lookup requiring only the `id` be supplied. For example, `tomcat`. -- `timeout` - duration to wait on the effector task to complete. For example `10s`, `10m`, etc -- `effector` - effector to invoke, for example `deploy`. -- `params` - parameters to pass to the effector, these will depend on the entity and effector being tested. The example above shows the `url` and `targetName` parameters being passed to Tomcats `deploy` effector. -- `assert` - assertion to perform on the returned result. See section on assertions below. - -### TestHttpCall -The `TestHttpCall` entity performs a HTTP GET on the specified URL and performs an assertion on the response. -{% highlight yaml %} -{% readj example_yaml/entities/testhttpcall-entity.yaml %} -{% endhighlight %} - -#### Parameters -- `url` - URL to perform GET request on, this can use DSL for example `$brooklyn:component("tomcat").attributeWhenReady("webapp.url")`. -- `timeout` - duration to wait on a HTTP response. For example `10s`, `10m`, etc -- `applyAssertionTo` - The filed to apply the assertion to. For example `status`, `body` -- `assert` - assertion to perform on the response. See section on assertions below. - -### SimpleShellCommandTest - -The SimpleShellCommandTest runs a command on the host of the target entity. -The script is expected not to run indefinitely, but to return a result (process exit code), along with its -standard out and error streams, which can then be tested using assertions. -If no assertions are explicitly configured, the default is to assert a non-zero exit code. - -Either a shell command may be provided in the YAML, or a URL for a script which will be executed. - -{% highlight yaml %} -{% readj example_yaml/entities/simpleshellcommandtest-entity.yaml %} -{% endhighlight %} - -#### Parameters -- `command` - The shell command to execute. (This and `downloadUrl` are mutually exclusive.) -- `downloadUrl` - URL for a script to download and execute. (This and `command` are mutually exclusive.) -- `scriptDir` - if `downloadUrl` is used. The directory on the target host where downloaded scripts should be copied to. -- `runDir` - the working directory where the command or script will be executed on the target host. -- `assertStatus` - Assertions on the exit code of the command or script. See section on assertions below. -- `assertOut` - Assertions on the standard output of the command as a String. -- `assertErr` - Assertions on the standard error of the command as a String. - -## Assertions - -The following conditions are provided by those test entities above that include assertions - -- `isNull` - asserts that the actual value is `null`. -- `notNull` - asserts that the actual value is NOT `null`. -- `isEqualTo` - asserts that the actual value equals an expected value. -- `equalTo` - a synonym for `isEqualTo` -- `equals` - a synonym for `isEqualTo` -- `matches` - asserts that the actual value matches a [regex pattern](http://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html?is-external=true), for example `".*hello.*"`. -- `contains` - asserts that the actual value contains the supplied value -- `isEmpty` - asserts that the actual value is an empty string -- `notEmpty` - asserts that the actual value is a non empty string -- `hasTruthValue` - asserts that the actual value has the expected interpretation as a boolean - -Assertions may be provided as a simple map: - -```yaml - assert: - contains: 2 users - matches: .*[\d]* days.* -``` - -If there is the need to make multiple assertions with the same key, the assertions can be specified -as a list of such maps: - -```yaml - assert: - - contains: 2 users - - contains: 2 days -``` http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/test/usage-examples.md ---------------------------------------------------------------------- diff --git a/brooklyn-docs/guide/yaml/test/usage-examples.md b/brooklyn-docs/guide/yaml/test/usage-examples.md deleted file mode 100644 index 086d1fb..0000000 --- a/brooklyn-docs/guide/yaml/test/usage-examples.md +++ /dev/null @@ -1,58 +0,0 @@ ---- -title: Example Blueprint Tests -title_in_menu: Example Tests -layout: website-normal ---- - -{% include fields.md %} - -## Introduction -This section describes some simple tests based on the [Getting Started](../../start/blueprints.html#launching-from-a-blueprint) example blueprint: - -{% highlight yaml %} -{% readj ../../start/_my-web-cluster.yaml %} -{% endhighlight %} - -The following sections contain yaml snippets that be appended to the list of services in the blueprint above, a complete blueprint is also provided [below](#full-example). - -Note that unless otherwise specified the following tests are executed in parallel with the deployment of the application services, all `timeout` values are set accordingly. - -### Sensor Test - -Demonstrates the following sensor assertion: - -- asserts that the `webappcluster` entity `service.isUp` sensor is `true` within 10 minutes of blueprint being deployed. - -{% highlight yaml %} -{% read example_yaml/testcases/sensor-test-snippet.yaml %} -{% endhighlight %} - -### HTTP Call Tests -Demonstrates the following HTTP Call assertions against the specified `url`, which in these examples are being built from the `webappcluster` entities `host.address` and `proxy.http.port` sensors (the tester having flexibility in how the test URL is to be constructed): - -- asserts the response status code is 200 within 10 minutes of the blueprint being deployed. -- asserts the response body matches the regex `(?s).*Br[o]{2}klyn Deployed.*` within 10 minutes of the blueprint being deployed. Note the presence of the `(?s)` dotall flag to test a multiline response. - -{% highlight yaml %} -{% readj example_yaml/testcases/http-test-snippet.yaml %} -{% endhighlight %} - -### Effector Test (via TestCase entity) - -This `TestEffector` example demonstrates the use of the `TestCase` and `TestSensor` entities to ensure the service has started before invoking an effector using the `TestEffector` entity. - -- `TestCase` entity starts its children sequentially - - asserts that the `webappcluster` entity `service.isUp` sensor is `true` within 10 minutes of the parent `TestCase` entity starting. Blocks start of the next child until it obtains a result (or times out). - - `deploy` effector invoked to deploy war to a `newcontext` with a 5 minute timeout to allow completion of the deploy task. - - asserts `/newcontext` url returns a HTTP status code 200 within 5 minutes of the effector being invoked (Note that this timeout is relative to the preceding test entity as they are being sequentially run as children of a `TestCase` entity). - -{% highlight yaml %} -{% readj example_yaml/testcases/effector-test-snippet.yaml %} -{% endhighlight %} - -### Full Example -A sample blueprint containing all the tests described above is available [here](./example_yaml/testcases/getting-started-test-example.yaml). - -This blueprint will deploy the [Getting Started](../../start/blueprints.html#launching-from-a-blueprint) application and run all of the test entities, which if successful should appear in the web console as follows. - -[](images/getting-started-blueprint-test-large.png) http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/web-console-yaml-700.png ---------------------------------------------------------------------- diff --git a/brooklyn-docs/guide/yaml/web-console-yaml-700.png b/brooklyn-docs/guide/yaml/web-console-yaml-700.png deleted file mode 100644 index d6a2249..0000000 Binary files a/brooklyn-docs/guide/yaml/web-console-yaml-700.png and /dev/null differ http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/web-console-yaml.png ---------------------------------------------------------------------- diff --git a/brooklyn-docs/guide/yaml/web-console-yaml.png b/brooklyn-docs/guide/yaml/web-console-yaml.png deleted file mode 100644 index 3d65a99..0000000 Binary files a/brooklyn-docs/guide/yaml/web-console-yaml.png and /dev/null differ http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/winrm/index.md ---------------------------------------------------------------------- diff --git a/brooklyn-docs/guide/yaml/winrm/index.md b/brooklyn-docs/guide/yaml/winrm/index.md deleted file mode 100644 index a787aa0..0000000 --- a/brooklyn-docs/guide/yaml/winrm/index.md +++ /dev/null @@ -1,526 +0,0 @@ ---- -title: Windows Blueprints -layout: website-normal ---- - -Brooklyn can deploy to Windows servers using WinRM to run commands. These deployments can be -expressed in pure YAML, and utilise Powershell to install and manage the software process. -This approach is similar to the use of SSH for UNIX-like servers. - - -About WinRM ------------ - -WinRM - or *Windows Remote Management* to give its full title - is a system administration service provided in all -recent Windows Server operating systems. It allows remote access to system information (provided via WMI) and the -ability to execute commands. For more information refer to [Microsoft's MSDN article on Windows Remote -Management](https://msdn.microsoft.com/en-us/library/aa384426(v=vs.85).aspx). - -WinRM is available by default in Windows Server, but is not enabled by default. Brooklyn will, in most cases, be able -to switch on WinRM support, but this is dependent on your cloud provider supporting a user metadata service with script -execution (see [below](#user-metadata-service-requirement)). - - -Locations for Windows ---------------------- - -You must define a new location in Brooklyn for Windows deployments. Windows deployments require a different VM image -ID to Linux, as well as some other special configuration, so you must have separate Brooklyn locations for Windows and -Linux deployments. - -In particular, you will most likely want to set these properties on your location: - -* `imageId` or `imageNameRegex` - select your preferred Windows Server image from your cloud provider. -* `hardwareId` or `minRam`/`minCores` - since Windows machines generally require more powerful servers, ensure you get - a machine with the required specification. -* `useJcloudsSshInit` - this must be set to `false`. Without this setting, jclouds will attempt to connect to the new - VMs using SSH, which will fail on Windows Server. -* `templateOptions` - you may also wish to request a larger disk size. This setting is cloud specific; on AWS, you can - request a 100GB disk by setting this property to `{mapNewVolumeToDeviceName: ["/dev/sda1", 100, true]}`. - -In your YAML blueprint: - - ... - location: - jclouds:aws-ec2: - region: us-west-2 - identity: AKA_YOUR_ACCESS_KEY_ID - credential: <access-key-hex-digits> - imageNameRegex: Windows_Server-2012-R2_RTM-English-64Bit-Base-.* - imageOwner: 801119661308 - hardwareId: m3.medium - useJcloudsSshInit: false - templateOptions: {mapNewVolumeToDeviceName: ["/dev/sda1", 100, true]} - ... - -Alternatively, you can define a new named location in `brooklyn.properties`: - - brooklyn.location.named.AWS\ Oregon\ Win = jclouds:aws-ec2:us-west-2 - brooklyn.location.named.AWS\ Oregon\ Win.displayName = AWS Oregon (Windows) - brooklyn.location.named.AWS\ Oregon\ Win.imageNameRegex = Windows_Server-2012-R2_RTM-English-64Bit-Base-.* - brooklyn.location.named.AWS\ Oregon\ Win.imageOwner = 801119661308 - brooklyn.location.named.AWS\ Oregon\ Win.hardwareId = m3.medium - brooklyn.location.named.AWS\ Oregon\ Win.useJcloudsSshInit = false - brooklyn.location.named.AWS\ Oregon\ Win.templateOptions = {mapNewVolumeToDeviceName: ["/dev/sda1", 100, true]} - - - -A Sample Blueprint ------------------- - -Creating a Windows VM is done using the `org.apache.brooklyn.entity.software.base.VanillaWindowsProcess` entity type. This is very similar -to `VanillaSoftwareProcess`, but adapted to work for Windows and WinRM instead of Linux. We suggest you read the -[documentation for VanillaSoftwareProcess](../custom-entities.html#vanilla-software-using-bash) to find out what you -can do with this entity. - -Entity authors are strongly encouraged to write Windows Powershell or Batch scripts as separate -files, to configure these to be uploaded, and then to configure the appropriate command as a -single line that executes given script. - -For example - here is a simplified blueprint (but see [Tips and Tricks](#tips-and-tricks) below!): - - name: Server with 7-Zip - - location: - jclouds:aws-ec2: - region: us-west-2 - identity: AKA_YOUR_ACCESS_KEY_ID - credential: <access-key-hex-digits> - imageNameRegex: Windows_Server-2012-R2_RTM-English-64Bit-Base-.* - imageOwner: 801119661308 - hardwareId: m3.medium - useJcloudsSshInit: false - templateOptions: {mapNewVolumeToDeviceName: ["/dev/sda1", 100, true]} - - services: - - type: org.apache.brooklyn.entity.software.base.VanillaWindowsProcess - brooklyn.config: - templates.preinstall: - file:///Users/richard/install7zip.ps1: "C:\\install7zip.ps1" - install.command: powershell -command "C:\\install7zip.ps1" - customize.command: echo true - launch.command: echo true - stop.command: echo true - checkRunning.command: echo true - installer.download.url: http://www.7-zip.org/a/7z938-x64.msi - -The installation script - referred to as `/Users/richard/install7zip.ps1` in the example above - is: - - $Path = "C:\InstallTemp" - New-Item -ItemType Directory -Force -Path $Path - - $Url = "${config['installer.download.url']}" - $Dl = [System.IO.Path]::Combine($Path, "installer.msi") - $WebClient = New-Object System.Net.WebClient - $WebClient.DownloadFile( $Url, $Dl ) - - Start-Process "msiexec" -ArgumentList '/qn','/i',$Dl -RedirectStandardOutput ( [System.IO.Path]::Combine($Path, "stdout.txt") ) -RedirectStandardError ( [System.IO.Path]::Combine($Path, "stderr.txt") ) -Wait - -This is only a very simple example. A more complex example can be found in the [Microsoft SQL Server blueprint in the -Brooklyn source code]({{ site.brooklyn.url.git }}/software/database/src/main/resources/org/apache/brooklyn/entity/database/mssql). - - -Tips and Tricks ---------------- - -The best practices for other entities (e.g. using [VanillaSoftwareProcess](../custom-entities.html#vanilla-software-using-bash)) -apply for WinRM as well. - -### Execution Phases - -Blueprint authors are strongly encouraged to provide an implementation for install, launch, stop -and checkRunning. These are vital for the generic effectors such as stopping and restarting the -process. - -### Powershell - -Powershell commands can be supplied using config options such as `launch.powershell.command`. - -This is an alternative to supplying a standard batch command using config such as `launch.command`. -For a given phase, only one of the commands (Powershell or Batch) should be supplied. - -### Getting the Right Exit Codes - -WinRM (or at least the chosen WinRM client!) can return a zero exit code even on error in certain -circumstances. It is therefore advisable to follow the guidelines below. - -*For a given command, write the Powershell or Batch script as a separate multi-command file. -Upload this (e.g. by including it in the `files.preinstall` configuration). For the configuration -of the given command, execute the file.* - -When you have a command inside the powershell script which want to report its non zero exiting, -please consider adding a check for its exit code after it. -Example: - - & "C:\install.exe" - If ($lastexitcode -ne 0) { - exit $lastexitcode - } - -For Powershell files, consider including - - $ErrorActionPreference = "Stop" - -at the start of the file. -`$ErrorActionPreference` Determines how Windows PowerShell responds to a non-terminating -error (an error that does not stop the cmdlet processing) at the -command line or in a script, cmdlet, or provider, such as the -errors generated by the Write-Error cmdlet. -https://technet.microsoft.com/en-us/library/hh847796.aspx - -See [Incorrect Exit Codes](#incorrect-exit-codes) under Known Limitations below. - -### Executing Scripts From Batch Commands - -In a batch command, you can execute a batch file or Powershell file. For example: - - install.command: powershell -NonInteractive -NoProfile -Command "C:\\install7zip.ps1" - -Or alternatively: - - install.command: C:\\install7zip.bat - -### Executing Scripts From Powershell - -In a Powershell command, you can execute a batch file or Powershell file. There are many ways -to do this (see official Powershell docs). For example: - - install.powershell.command: "& C:\\install7zip.ps1" - -Or alternatively: - - install.powershell.command: "& C:\\install7zip.bat" - -Note the quotes around the command. This is because the "&" has special meaning in a YAML value. - -### Uploading Script and Configuration Files - -Often, blueprints will require that (parameterized) scripts and configuration files are available to be copied to the -target VM. These must be URLs resolvable from the Brooklyn instance, or on the Brooklyn classpath. One simple way -to achieve this is to compile the support files into a .jar, which is then added to AMP's 'dropins' folder. Alternatively, -an OSGi bundle can be used, referenced from the catalog item. - -Ensure that these scripts end each line with "\r\n", rather than just "\n". - -There are two types of file that can be uploaded: plain files and templated files. A plain -file is uploaded unmodified. A templated file is interpreted as a [FreeMarker](http://freemarker.org) -template. This supports a powerful set of substitutions. In brief, anything (unescaped) of the form -`${name}` will be substituted, in this case looking up "name" for the value to use. - -Templated files (be they configuration files or scripts) gives a powerful way to inject dependent -configuration when installing an entity (e.g. for customising the install, or for referencing the -connection details of another entity). A common substitution is of the form `${config['mykey']}`. -This looks up a config key (in this case named "mykey") and will insert the value into the file. -Another common substitution is is of the form `${attribute['myattribute']}` - this looks up the -attribute named "myattribute" of this entity. - -Files can be referenced as URLs. This includes support for things like `classpath://mypath/myfile.bat`. -This looks for the given (fully qualified) resource on the Brooklyn classpath. - -The destination for the file upload is specified in the entity's configuration. Note that "\" must -be escaped. For example `"C:\\install7zip.ps1"`. - -A list of plain files to be uploaded can be configured under `files.preinstall`, `files.install` and -`files.runtime`. These are uploaded respectively prior to executing the `pre.install.command`, -prior to `install.command` and prior to `pre.launch.command`. - -A list of templated files to be uploaded can be configured under `templates.preinstall`, `templates.install` -and `templates.runtime`. The times these are uploaded is as for the plain files. The templates -substitutions will be resolved only at the point when the file is to be uploaded. - -For example: - - files.preinstall: - - classpath://com/acme/installAcme.ps1 - - classpath://com/acme/acme.conf - -### Parameterised Scripts - -Calling parameterised Batch and Powershell scripts is done in the normal Windows way - see -offical Microsoft docs. For example: - - install.command: "c:\\myscript.bat myarg1 myarg2" - -Or as a Powershell example: - - install.powershell.command: "& c:\\myscript.ps1 -key1 myarg1 -key2 myarg2" - -It is also possible to construct the script parameters by referencing attributes of this or -other entities using the standard `attributeWhenReady` mechanism. For example: - - install.command: $brooklyn:formatString("c:\\myscript.bat %s", component("db").attributeWhenReady("datastore.url")) - -### Powershell - Using Start-Process - -When you are invoking a command from a powershell script with `Start-Process` cmdlet, -please use the `-Wait` and the `-PassThru` arguments. -Example `Start-Process C:\mycommand -Wait -PassThru` - -Using `-Wait` guarantees that the script process and its children and thus the winrm session won't be terminated until it is finished. -`-PassThru` Returns a process object for each process that the cmdlet started. By default, this cmdlet does not generate any output. -See https://technet.microsoft.com/en-us/library/hh849848.aspx - -### Rebooting - -Where a reboot is required as part of the entity setup, this can be configured using -config like `pre.install.reboot.required` and `install.reboot.required`. If required, the -installation commands can be split between the pre-install, install and post-install phases -in order to do a reboot at the appropriate point of the VM setup. - -### Install Location - -Blueprint authors are encouraged to explicitly specify the full path for file uploads, and -for paths in their Powershell scripts (e.g. for installation, configuration files, log files, etc). - -### How and Why to re-authenticate within a powershell script - -Brooklyn will run powershell scripts by making a WinRM call over HTTP. For most scripts this will work, however for -some scripts (e.g. MSSQL installation), this will fail even if the script can be run locally (e.g. by using RDP to -connect to the machine and running the script manually) - -For example in the case of MS SQL server installation, there was no clear indication of why this would not work. -The only clue was a security exception in the installation log. - -When a script is run over WinRM over HTTP, the credentials under which the script are run are marked as -'remote' credentials, which are prohibited from running certain security-related operations. The solution was to obtain -a new set of credentials within the script and use those credentials to execute the installer, so this: - - ( $driveLetter + "setup.exe") /ConfigurationFile=C:\ConfigurationFile.ini - -became this: - - $pass = '${attribute['windows.password']}' - $secpasswd = ConvertTo-SecureString $pass -AsPlainText -Force - $mycreds = New-Object System.Management.Automation.PSCredential ($($env:COMPUTERNAME + "\Administrator"), $secpasswd) - - Start-Process ( $driveLetter + "setup.exe") -ArgumentList "/ConfigurationFile=C:\ConfigurationFile.ini" -Credential $mycreds -RedirectStandardOutput "C:\sqlout.txt" -RedirectStandardError "C:\sqlerr.txt" -Wait - -The `$pass=` line simply reads the Windows password from the entity before the script is copied to the server. This is -then encrypted on the next line before being used to create a new credential object. Then, rather than calling the executable -directly, the `Start-Process` scriptlet is used. This allows us to pass in the newly created credentials, under which -the process will be run. - -Certain registry keys must be reconfigured in order to support re-authentication. Brooklyn will take care of this at -instance boot time, as part of the setup script. Please ensure that Brooklyn's changes are compatible with your -organisation's security policy. - -Re-authentication also requires that the password credentials are passed in plain text in the blueprint's script files. -Please be aware that it is normal for script files - and therefore the plaintext password - to be saved to the VM's -disk. - -### Windows AMIs on AWS - -Windows AMIs in AWS change regularly (to include the latest Windows updates). If using the community -AMI, it is recommended to use an AMI name regex, rather than an image id, so that the latest AMI is -always picked up. If an image id is used, it may fail as Amazon will delete their old Windows AMIs. - -If using an image regex, it is recommended to include the image owner in case someone else uploads -a similarly named AMI. For example: - - brooklyn.location.named.AWS\ Oregon\ Win = jclouds:aws-ec2:us-west-2 - brooklyn.location.named.AWS\ Oregon\ Win.imageNameRegex = Windows_Server-2012-R2_RTM-English-64Bit-Base-.* - brooklyn.location.named.AWS\ Oregon\ Win.imageOwner = 801119661308 - ... - -## stdout and stderr in a Powershell script - -When calling an executable in a Powershell script, the stdout and stderr will usually be output to the console. -This is captured by Brooklyn, and shown in the activities view under the specific tasks. - -An alternative is to redirect stdout and stderr to a file on the VM, which can be helpful if one expects sys admins -to log into the VM. However, be warned that this would hide the stdout/stderr from Brooklyn's activities view. - -For example, instead of running the following: - - D:\setup.exe /ConfigurationFile=C:\ConfigurationFile.ini - - The redirect can be achieved by using the `Start-Process` scriptlet: - - Start-Process D:\setup.exe -ArgumentList "/ConfigurationFile=C:\ConfigurationFile.ini" -RedirectStandardOutput "C:\sqlout.txt" -RedirectStandardError "C:\sqlerr.txt" -PassThru -Wait - -The `-ArgumentList` is simply the arguments that are to be passed to the executable, `-RedirectStandardOutput` and -`RedirectStandardError` take file locations for the output (if the file already exists, it will be overwritten). The -`-PassThru` argument indicates that Powershell should write to the file *in addition* to the console, rather than -*instead* of the console. The `-Wait` argument will cause the scriptlet to block until the process is complete. - -Further details can be found on the [Start-Process documentation page](https://technet.microsoft.com/en-us/library/hh849848.aspx) -on the Microsoft TechNet site. - - -Troubleshooting ---------------- - -Much of the [operations troubleshooting guide](../../ops/troubleshooting/) is applicable for Windows blueprints. - -### User metadata service requirement - -WinRM requires activation and configuration before it will work in a standard Windows Server deployment. To automate -this, Brooklyn will place a setup script in the user metadata blob. Services such as Amazon EC2's `Ec2ConfigService` -will automatically load and execute this script. If your chosen cloud provider does not support `Ec2ConfigService` or -a similar package, or if your cloud provider does not support user metadata, then you must pre-configure a Windows image -with the required WinRM setup and make Brooklyn use this image. - -If the configuration options `userMetadata` or `userMetadataString` are used on the location, then this will override -the default setup script. This allows one to supply a custom setup script. However, if userMetadata contains something -else then the setup will not be done and the VM may not not be accessible remotely over WinRM. - -### Credentials issue requiring special configuration - -When a script is run over WinRM over HTTP, the credentials under which the script are run are marked as -'remote' credentials, which are prohibited from running certain security-related operations. This may prevent certain -operations. The installer from Microsoft SQL Server is known to fail in this case, for example. For a workaround, please -refer to [How and Why to re-authenticate withing a powershell script](#how-and-why-to-re-authenticate-within-a-powershell-script) above. - -### AMIs not found - -If using the imageId of a Windows community AMI, you may find that the AMI is deleted after a few weeks. -See [Windows AMIs on AWS](#windows-amis-on-aws) above. - -### VM Provisioning Times Out - -In some environments, provisioning of Windows VMs can take a very long time to return a usable VM. -If the image is old, it may install many security updates (and reboot several times) before it is -usable. - -On a VMware vCloud Director environment, the guest customizations can cause the VM to reboot (sometimes -several times) before the VM is usable. - -This could cause the WinRM connection attempts to timeout. The location configuration option -`waitForWinRmAvailable` defaults to `30m` (i.e. 30 minutes). This can be increased if required. - -Incorrectly prepared Windows template can cause the deployment to time-out expecting an interaction by the user. -You can verify if this is the case by RDP to the deployment which is taking to much time to complete. -It is recommended to manually deploy a single VM for every newly created Windows template to verify that it can be -used for unattended installations and it doesn't wait and/or require an input by the user. -See [Windows template settings for an Unattended Installation](#windows-template-settings-for-an-unattended-installation) under Known Limitations below. - -### Windows log files - -Details of the commands executed, and their results, can be found in the Brooklyn log and in the Brooklyn -web-console's activity view. - -There will also be log files on the Windows Server. System errors in Windows are usually reported in the Windows Event Log - -see [https://technet.microsoft.com/en-us/library/cc766042.aspx](https://technet.microsoft.com/en-us/library/cc766042.aspx) -for more information. - -Additional logs may be created by some Windows programs. For example, MSSQL creates a log in -`%programfiles%\Microsoft SQL Server\130\Setup Bootstrap\Log\` - for more information see -[https://msdn.microsoft.com/en-us/library/ms143702.aspx](https://msdn.microsoft.com/en-us/library/ms143702.aspx). - - -Known Limitations ------------------ - -### Use of Unencrypted HTTP - -Brooklyn is currently using unencrypted HTTP for WinRM communication. This means that the login credentials will be -transmitted in clear text. - -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. - -### Incorrect Exit Codes - -Some limitations with WinRM (or at least the chosen WinRM Client!) are listed below: - -##### Single-line Powershell files - -When a Powershell file contains just a single command, the execution of that file over WinRM returns exit code 0 -even if the command fails! This is the case for even simple examples like `exit 1` or `thisFileDoesNotExist.exe`. - -A workaround is to add an initial command, for example: - - Write-Host dummy line for workaround - exit 1 - -##### Direct Configuration of Powershell commands - -If a command is directly configured with Powershell that includes `exit`, the return code over WinRM -is not respected. For example, the command below will receive an exit code of 0. - - launch.powershell.command: | - echo first - exit 1 - -##### Direct Configuration of Batch commands - -If a command is directly configured with a batch exit, the return code over WinRM -is not respected. For example, the command below will receive an exit code of 0. - - launch.command: exit /B 1 - -##### Non-zero Exit Code Returned as One - -If a batch or Powershell file exits with an exit code greater than one (or negative), this will -be reported as 1 over WinRM. - -We advise you to use native commands (non-powershell ones) since executing it as a native command -will return the exact exit code rather than 1. -For instance if you have installmssql.ps1 script use `install.command: powershell -command "C:\\installmssql.ps1"` -rather than using `install.powershell.command: "C:\\installmssql.ps1"` -The first will give you an exact exit code rather than 1 - -### PowerShell "Preparing modules for first use" - -The first command executed over WinRM has been observed to include stderr saying "Preparing -modules for first use", such as that below: - - < CLIXML - <Objs Version="1.1.0.1" xmlns="http://schemas.microsoft.com/powershell/2004/04";><Obj S="progress" RefId="0"><TN RefId="0"><T>System.Management.Automation.PSCustomObject</T><T>System.Object</T></TN><MS><I64 N="SourceId">1</I64><PR N="Record"><AV>Preparing modules for first use.</AV><AI>0</AI><Nil /><PI>-1</PI><PC>-1</PC><T>Completed</T><SR>-1</SR><SD> </SD></PR></MS></Obj><Obj S="progress" RefId="1"><TNRef RefId="0" /><MS><I64 N="SourceId">2</I64><PR N="Record"><AV>Preparing modules for first use.</AV><AI>0</AI><Nil /><PI>-1</PI><PC>-1</PC><T>Completed</T><SR>-1</SR><SD> </SD></PR></MS></Obj></Objs> - -The command still succeeded. This has only been observed on private clouds (e.g. not on -AWS). It could be related to the specific Windows images in use. It is recommended that -VM images are prepared carefully, e.g. so that security patches are up-to-date and the -VM is suitably initialised. - -### WinRM executeScript failed: httplib.BadStatusLine: '' - -As described in https://issues.apache.org/jira/browse/BROOKLYN-173, a failure has been -observed where the 10 attempts to execute the command over WinRM failed with: - - httplib.BadStatusLine: '' - -Subsequently retrying the command worked. It is unclear what caused the failure, but could -have been that the Windows VM was not yet in the right state. - -One possible workaround is to ensure the Windows VM is in a good state for immediate use (e.g. -security updates are up-to-date). Another option is to increase the number of retries, -which defaults to 10. This is a configuration option on the machine location, so can be set on -the location's brooklyn.properties or in the YAML: - - execTries: 20 - -### Direct Configuration of Multi-line Batch Commands Not Executed - -If a command is directly configured with multi-line batch commands, then only the first line -will be executed. For example the command below will only output "first": - - launch.command: | - echo first - echo second - -The workaround is to write a file with the batch commands, have that file uploaded, and execute it. - -Note this is not done automatically because that could affect the capture and returning -of the exit code for the commands executed. - -### Install location - -Work is required to better configure a default install location on the VM (e.g. so that -environment variables are set). The installation pattern for linux-based blueprints, -of using brooklyn-managed-processes/installs, is not used or recommended on Windows. -Files will be uploaded to C:\ if no explicit directory is supplied, which is untidy, -unnecessarily exposes the scripts to the user, and could cause conflicts if multiple -entities are installed. - -Blueprint authors are strongly encourages to explicitly specific directories for file -uploads and in their Powershell scripts. - -### Windows template settings for an Unattended Installation - -Windows template needs certain configuration to be applied to prevent windows setup UI from being displayed. -The default behavior is to display it if there are incorrect or empty settings. Showing Setup UI will prevent the proper -deployment, because it will expect interaction by the user such as agreeing on the license agreement or some of the setup dialogs. - -Detailed instruction how to prepare an Unattended installation are provided at [https://technet.microsoft.com/en-us/library/cc722411%28v=ws.10%29.aspx](https://technet.microsoft.com/en-us/library/cc722411%28v=ws.10%29.aspx). - http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/guide/yaml/yaml-reference.md ---------------------------------------------------------------------- diff --git a/brooklyn-docs/guide/yaml/yaml-reference.md b/brooklyn-docs/guide/yaml/yaml-reference.md deleted file mode 100644 index 7a628a0..0000000 --- a/brooklyn-docs/guide/yaml/yaml-reference.md +++ /dev/null @@ -1,239 +0,0 @@ ---- -title: Broooklyn YAML Blueprint Reference -layout: website-normal ---- - -## Root Elements - -* `name`: human readable names -* `services`: a list of `ServiceSpecification` elements -* `location` (or `locations` taking a list): a `LocationSpecification` element as a string or a map - - -## Service Specification Elements - -Within the `services` block, a list of maps should be supplied, with each map -defining a `ServiceSpecification`. Each `ServiceSpecification` should declare the -service `type` (synonyms `serviceType` and `service_type`), indicating what type of -service is being specified there. The following formats are supported for -defining types: - -* `com.acme.brooklyn.package.JavaEntityClass` -* `java:com.acme.brooklyn.package.JavaEntityClass` -* `java-entity-class` (where this has been added to the [catalog](../ops/catalog/)) - -A reference of some of the common service `type` instances used is included in a section below. - -Within the `ServiceSpecification`, other key-value pairs can be supplied to customize -the entity being defined, with these being the most common: - -* `id`: an ID string, used to refer to this service - -* `location` (or `locations`): as defined in the root element - -* `brooklyn.config`: configuration key-value pairs passed to the service entity being created - -* `brooklyn.children`: a list of `ServiceSpecifications` which will be configured as children of this entity - -* `brooklyn.policies`: a list of policies, each as a map described with their `type` and their `brooklyn.config` as keys - -* `brooklyn.enrichers`: a list of enrichers, each as a map described with their `type` and their `brooklyn.config` as keys; - see the keys declared on individual enrichers; - also see [this enricher example](example_yaml/test-app-with-enrichers-slightly-simpler.yaml) for a detailed and commented illustration - <!-- TODO assert that this yaml maches the yaml we test against --> - -* `brooklyn.initializers`: a list of `EntityInitializer` instances to be constructed and run against the entity, - each as a map described with their `type` and their `brooklyn.config` as keys. - An `EntityInitiailzer` can perform arbitrary customization to an entity whilst it is being constructed, - such as adding dynamic sensors and effectors. These classes must expose a public constructor taking - a single `Map` where the `brooklyn.config` is passed in. - Some common initializers are: - - * `org.apache.brooklyn.core.effector.ssh.SshCommandEffector`: takes a `name` and `command`, - and optionally a map of named `parameters` to their `description` and `defaultValue`, - to define an effector with the given name implemented by the given SSH command - (on an entity which as an ssh-able machine) - - * `org.apache.brooklyn.core.sensor.ssh.SshCommandSensor`: takes a `name` and `command`, - and optionally a `period`, to create a sensor feed which populates the sensor with - the given name by running the given command (on an entity which as an ssh-able machine) - -* `brooklyn.parameters`: documents a list of typed parameters the entity accepts. If none - are specified the config keys declared in the entity's class are used (including the - information from the `@CatalogConfig` annotation). The items have the following properties: - * `name` (required): identifier by which to reference the parameter when setting - or retrieving its value - * `label`: a value to present to the user, same as `name` if empty - * `description`: short text describing the parameter behaviour/usage, presented - to the user - * `type`: the type of the parameter, one of `string`, `integer`, `long`, `float`, - `double`, `timestamp`, `duration`, `port`, or a fully qualified Java type name; - the default is `string`; - obvious coercion is supported so - `timestamp` accepts most common ISO date formats, `duration` accepts `5m`, and port accepts `8080+` - * `default`: a default value; this will be coerced to the declared `type` - * `constraints`: a list of constraints the parameter should meet; - currently `required` is supported, with the default being not required - - A shorthand notation is also supported where just the name of the parameter is supplied - as an item in the list, with the other values being unset or the default. - See `displayName` in the following example for an illustration of this: - -~~~ yaml -brooklyn.parameters: -# user.age parameter is required, and fully specified -- name: user.age - type: integer - label: Age - description: the age of the user - constraints: - - required -# user.name is optional, and has a default -- name: user.name - default: You -# shorthand notation: displayName will be an optional config of type string with no default -- displayName -~~~ - -Entities, policies, and initializers may accept additional key-value pairs, -usually documented in their documentation (e.g. javadoc), or in the case of Java -often as static fields in the underlying Java class. -Often there are config keys or flags (indicated by `@SetFromFlag`) declared on the class; -these declared flags and config keys may be passed in at the root of the `ServiceSpecification` or in `brooklyn.config`. -(Undeclared config is only accepted in the `brooklyn.config` map.) -Referencing the parameters from within java classes is identical to using config keys. In yaml it's -usually referenced using `$brooklyn:scopeRoot().config("displayName")`. See below for more details on scopes. - - -## Location Specification Elements - -<!-- TODO - expand this, currently it's concise notes --> - -In brief, location specs are supplied as follows, either for the entire application (at the root) -or for a specific `ServiceSpecification`: - - location: - jclouds:aws-ec2: - region: us-east-1 - identity: AKA_YOUR_ACCESS_KEY_ID - credential: <access-key-hex-digits> - -Or in many cases it can be in-lined: - - location: localhost - location: named:my_openstack - location: aws-ec2:us-west-1 - -For the first immediately, you'll need password-less ssh access to localhost. -For the second, you'll need to define a named location in `brooklyn.properties`, -using `brooklyn.location.named.my_openstack....` properties. -For the third, you'll need to have the identity and credentials defined in -`brooklyn.properties`, using `brooklyn.location.jclouds.aws-ec2....` properties. - -If specifying multiple locations, e.g. for a fabric: - - locations: - - localhost - - named:my_openstack - - aws-ec2:us-east-2 # if credentials defined in `brooklyn.properties - - jclouds:aws-ec2: - region: us-east-1 - identity: AKA_YOUR_ACCESS_KEY_ID - credential: <access-key-hex-digits> - -If you have pre-existing nodes, you can use the `byon` provider, either in this format: - - location: - byon: - user: root - privateKeyFile: ~/.ssh/key.pem - hosts: - - 81.95.144.58 - - 81.95.144.59 - - [email protected] - - [email protected] - -or: - - location: - byon: - user: root - privateKeyFile: ~/.ssh/key.pem - hosts: "{81.95.144.{58,59},[email protected].{139-140}" - -You cannot use glob expansions with the list notation, nor can you specify per-host -information apart from user within a single `byon` declaration. -However you can combine locations using `multi`: - - location: - multi: - targets: - - byon: - user: root - privateKeyFile: ~/.ssh/key.pem - hosts: - - 81.95.144.58 - - 81.95.144.59 - - byon: - privateKeyFile: ~/.ssh/brooklyn_key.pem - hosts: [email protected]{139-140} - - -## DSL Commands - -Dependency injection other powerful references and types can be built up within the YAML using the -concise DSL defined here: - -* `$brooklyn:attributeWhenReady("sensor")` will store a future which will be blocked when it is accessed, - until the given `sensor` from this entity "truthy" (i.e. non-trivial, non-empty, non-zero) value - (see below on `component` for looking up values on other sensors) -* `$brooklyn:config("key")` will insert the value set against the given key at this entity (or nearest ancestor); - can be used to supply config at the root which is used in multiple places in the plan -* `$brooklyn:sensor("sensor.name")` returns the given sensor on the current entity if found, or an untyped (Object) sensor; - `$brooklyn:sensor("com.acme.brooklyn.ContainingEntityClass", "sensor.name")` returns the strongly typed sensor defined in the given class -* `$brooklyn:component("ID")` refers to a Brooklyn component with the given ID; you can then access the following subfields, - using the same syntax as defined above but with a different reference entity, - e.g. `$brooklyn:component("ID").attributeWhenReady("sensor")`: - * `.attributeWhenReady("sensor")` - * `.config("key")` - * `.sensor("sensor.name")` -* `$brooklyn:component("scope", "ID")` is also supported, to limit scope to any of - * `global`: looks for the `ID` anywhere in the plan - * `child`: looks for the `ID` anywhere in the child only - * `descendant`: looks for the `ID` anywhere in children or their descendants - * `sibling`: looks for the `ID` anywhere among children of the parent entity - * `parent`: returns the parent entity (ignores the `ID`) - * `this`: returns this entity (ignores the `ID`) -* `$brooklyn:root()` will return the topmost entity (the application) -* `$broopklyn:scopeRoot()` will return the root entity in the current plan scope. - For catalog items it's the topmost entity in the plan, for application plans it is the same as - `$brooklyn:root()`. -* `$brooklyn:formatString("pattern e.g. %s %s", "field 1", "field 2")` returns a future which creates the formatted string - with the given parameters, where parameters may be strings *or* other tasks such as `attributeWhenReady` -* `$brooklyn:literal("string")` returns the given string as a literal (suppressing any `$brooklyn:` expansion) -* `$brooklyn:object(Map)` creates an object, using keys `type` to define the java type, - and either `object.fields` or `brooklyn.config` to supply bean/constructor/flags to create an instance -* `$brooklyn:entitySpec(Map)` returns a new `ServiceSpecification` as defined by the given `Map`, - but as an `EntitySpec` suitable for setting as the value of `ConfigKey<EntitySpec>` config items - (such as `memberSpec` in `DynamicCluster`) - -<!-- TODO examples for object and entitySpec --> - -Parameters above can be supplied either as strings or as lists and maps in YAML, -and the `$brooklyn:` syntax can be used within those parameters. - - -## Some Powerful YAML Entities - -All entities support configuration via YAML, but these entities in particular -have been designed for general purpose use from YAML. Consult the Javadoc for these -elements for more information: - -* **Vanilla Software** in `VanillaSoftwareProcess`: makes it very easy to build entities - which use `bash` commands to install and the PID to stop and restart -* **Chef** in `ChefSoftwareProcess`: makes it easy to use Chef cookbooks to build entities, - either with recipes following conventions or with configuration in the `ServiceSpecification` - to use artibitrary recipes -* `DynamicCluster`: provides resizable clusters given a `memberSpec` set with `$brooklyn.entitySpec(Map)` as described above -* `DynamicFabric`: provides a set of homogeneous instances started in different locations, - with an effector to `addLocation`, i.e. add a new instance in a given location, at runtime http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/index.md ---------------------------------------------------------------------- diff --git a/brooklyn-docs/index.md b/brooklyn-docs/index.md deleted file mode 100644 index 37015c5..0000000 --- a/brooklyn-docs/index.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -layout: website-normal -title: Brooklyn Website and Docs (dev build) ---- - -<i>This page is not copied into release builds. It is here as a convenience when doing dev builds.</i> - -Consider looking at: - -* <a href="{{ site.path.website }}/">the brooklyn website</a> -* <a href="{{ site.path.guide }}/">the brooklyn user guide (version 0.9.0-SNAPSHOT) <!-- BROOKLYN_VERSION --></a> - -Also see the file <code>README.md</code> in this directory. - -For reference, this build uses the following variables: - -* url root: `{{ site.url_root }}` -* path map: `{{ site.path }}` - http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/style/css/_archive_warning.scss ---------------------------------------------------------------------- diff --git a/brooklyn-docs/style/css/_archive_warning.scss b/brooklyn-docs/style/css/_archive_warning.scss deleted file mode 100644 index 5803458..0000000 --- a/brooklyn-docs/style/css/_archive_warning.scss +++ /dev/null @@ -1,31 +0,0 @@ -/* ARCHIVE PAGE WARNING - ----------------------------------------------------------------------- */ - -#page_notes { - display: none; - background-color: #4D9D3A; - border: 3px solid orange; - -moz-border-radius: 8px; - border-radius: 8px; - padding: 0.3em; - padding-left: 0.75em; - margin-top: 24px; - margin-bottom: -24px; - - div.warning { - background-color: #F8CB9C; - border: 1px solid #FFAB7C; - padding-left: 0.75em; - -moz-border-radius: 8px; - border-radius: 8px; - } - .warning_banner_image img { - width: 64px; padding-top: 8px; padding-right: 12px; - float: left; - } - p { line-height: 100%; color: white; } - p.warning_banner_buttons {padding-right: 24px; } - p.warning_banner_buttons a, #page_notes p.warning_banner_buttons a:visited { - color: orange; font-weight: bold; padding-right: 1em; text-decoration: none; } - p.warning_banner_buttons a:hover { color: #FFC31E; font-weight: bold; } -} \ No newline at end of file http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/6e86cb02/brooklyn-docs/style/css/_basic.scss ---------------------------------------------------------------------- diff --git a/brooklyn-docs/style/css/_basic.scss b/brooklyn-docs/style/css/_basic.scss deleted file mode 100644 index d8c9235..0000000 --- a/brooklyn-docs/style/css/_basic.scss +++ /dev/null @@ -1,62 +0,0 @@ -/* BASIC STYLES - ----------------------------------------------------------------------- */ -body { - margin: 0px; - padding: 60px 0px 20px 0px; - font-family: $fonts; - font-weight: 300; - font-size: 17px; - background-color: white; - color: $text_color; -} -h1, h2, h3, h4, h5, h6 { font-family: $header_fonts; } -input, select, textarea {} -p, li, label, td, th,input, select, textarea {} -p, input, label, li {} -p { margin: 0.75em 0; line-height: 1.4em;} -form {padding: 0; margin: 0;} -img {border: 0;} - -a {color: $a_color;} -a:hover {text-decoration: none; color: $a_hover_color;} - -.dropdown-menu > li > a { - font-weight: 300; -} -.btn-default, .btn-primary, .btn-success, .btn-info, .btn-warning, .btn-danger { - text-shadow: none; - font-weight: 300; -} -.btn-default { - color: $gray_66; -} -.panel-heading { - h4 { - padding-bottom: 0px; - margin-bottom: 0px; - padding-top: 8px; - margin-top: 0px; - } -} -.panel-body { - margin: 0px; - font-size: 95%; - color: $gray_66; - padding: 15px; - background-color: $white_fa; - border-radius: 5px; - p:first-child { - margin-top: 0px; - } - p:last-child { - margin-bottom: 0px; - } - > ul, > ol { - margin-left: -1em; - } -} -.table > thead > tr > th, .table > tbody > tr > th, .table > tfoot > tr > th, .table > thead > tr > td, .table > tbody > tr > td, .table > tfoot > tr > td { - // extend bootstrap with a bottom border on table items; - // these get collapsed so not sure why bootstrap does weirdness where there's no bottom border - border-bottom: 1px solid $white_dd; -} \ No newline at end of file
