Brooklyn Service Broker - new features part 2

In Part 1, we demonstrated the new features introduced to the Service Broker API that have been implemented by the Brooklyn Service Broker. In this post, we demonstrate new features that allow greater control of the services offered by setting config in the catalog YAML.

Plan configuration in catalog YAML

To set configuration to be picked up by the service broker in the YAML, under brooklyn.config, we set a broker.config section:



In this section, we can configure which sensors will be used to populate the credentials object returned to Cloud Foundry, or define different plans which configure the basic service differently.

We will now walk through how to create a service that uses these features. Let’s start with a simple catalog service for RabbitMQ:

    id: com.cloudsoft.development.rabbitmq
    version: 1.0
    description:  RabbitMQ is a message broker that implements the Advanced Message Queuing Protocol (AMQP)
    displayName: CF RabbitMQ
    iconUrl: classpath:///RabbitMQLogo.png
    itemType: template
    - type: org.apache.brooklyn.entity.messaging.rabbit.RabbitBroker

Sensor whitelist for credentials

Rather than pass the entire set of sensors to VCAP_SERVICES when the service is bound, it is now possible to whitelist the sensors required for the credentials map, preventing the clutter caused by passing all sensors:

            - host
            - port
            - version
            - virtual-host
            - uri

Brooklyn’s sensor names don’t match what application developers using Cloud Foundry typically expect in their credentials block, so we use an enricher to map these to those named in the sensor.whitelist above:

    - enricherType: brooklyn.enricher.basic.Propagator
            $brooklyn:sensor(""): $brooklyn:sensor("host")
            $brooklyn:sensor("amqp.virtualHost"): $brooklyn:sensor("virtual-host")
            $brooklyn:sensor("amqp.port"): $brooklyn:sensor("port")
            $brooklyn:sensor("broker.url"): $brooklyn:sensor("uri")
            $brooklyn:sensor("amqp.version"): $brooklyn:sensor("version")

This ensures that these values are passed to VCAP_SERVICES.

Plan strategies

Plan Strategies are a new feature in the Brooklyn Broker that allow you to choose how Cloud Foundry plans are made from the catalog entries. There are currently three such strategies: location-plan, which was the original mode making plans based on locations in the Brooklyn Catalog; size-plan, which allows plan definitions to be specified in the YAML; and user-defined-plan, which allows only one plan and expects blueprints to be submitted as a parameter. The type of plan strategy used is configured in the broker configuration by setting the variable SPRING_PROFILES_ACTIVE to the required strategy.

We’re going to choose size-plan so that we can define plans in the catalog yaml, setting the location to which it will be deployed in the BROOKLYN_LOCATION variable of the broker configuration.

Next, we define each of our plans under a plans section in broker.config:

        - host
        - port
        - version
        - virtual-host
        - uri
            - name: small
            description: Single Core, 1GB RAM
                    minCores: 1
                    minRam: 1024
            - name: medium
            description: Dual Core, 2GB RAM
                    minCores: 2
                    minRam: 2048
            - name: large
            description: Quad Core, 4GB RAM
                    minCores: 4
                    minRam: 4096

Here we have defined a small, medium and large which sets the size of the VM on which the service is deployed. When a plan is instantiated, the selected plan is put into the brooklyn.config section of a generated blueprint, e.g. the large plan would produce:

    "locations": ["aws-california"], 
            "minCores": "4"
            "minRam": "4096"

Our catalog blueprint is now ready to be added to the Brooklyn Catalog and imported into the marketplace:

$ cf update-service-broker brooklyn username password http://brooklyn-service-broker

$ cf enable-service-access br_cf_rabbitmq

$ cf marketplace
Getting services from marketplace in org me / space development as admin...

service            plans                     description     
br_cf_rabbitmq     small*, medium*, large*   RabbitMQ is a message broker that implements the Advanced Message Queuing Protocol (AMQP)

where we can see our small, medium and large plans.

Sample application

To test this we can use the rabbitmq-cloudfoundry-samples sample node.js application. First create an instance of the rabbitmq service:

$ cf create-service br_cf_rabbitmq small rabbit

Modify the manifest to use this service:

    - name: rabbitmq-node
    memory: 256M
    instances: 1
    host: rabbitmq-node-${random-word}
    path: .
        - rabbit

And push the application:

$ cf push

We can take a look at the VCAP_SERVICES variable to check we have the credentials we expect:

$cf env rabbitmq-node
Getting env variables for app rabbitmq-node in org me / space development as admin...

        "br_cf_rabbitmq": [
                "credentials": {
                    "host": "x.x.x.x",
                    "host.address": "x.x.x.x",
                    "": "x.x.x.x",
                    "host.sshAddress": "amp@x.x.x.x:22",
                    "port": 5672,
                    "uri": "amqp://guest:guest@x.x.x.x:5672/localhost",
                    "version": "0-9-1",
                    "virtual-host": "localhost"
                "label": "br_cf_rabbitmq",
                "name": "rabbit",
                "plan": "small",
                "tags": []

And test out the running application in our browser.


There we have it, a new RabbitMQ service with individual plans defined completely in YAML using the Brooklyn Service Broker, ready to use on existing Cloud Foundry Applications. And this was a very simple example, Brooklyn really begins to shine when you add autonomic policies to your services e.g. Auto-scaler. Take a look at the range of options available on the Brooklyn website.

Next time

In the final part of this blog series describing updates to the Brooklyn Service Broker, we take a look at rapid development using user-defined-plan by passing in whole blueprints via the parameters API. Stay tuned.