brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Taylor <>
Subject Re: Apache Brooklyn Architecture
Date Fri, 15 Sep 2017 03:12:06 GMT
Hi Aled,

Thanks for writing. It took some time to digest / compare with my notes from reading the source

I still have some remaining questions. Ultimatly once resolved I would like yo put together
some docs/diagrams.

Does anyone know who I could contact for further deep dive discussion? Possibly a skype call?



From: Aled Sage <>
Sent: Thursday, August 24, 2017 9:40 AM
To:; Taylor
Subject: Re: Apache Brooklyn Architecture

Hi Taylor, thanks for getting in touch.

Improving the docs would be awesome!

Is there a use-case you have in mind as well, or is it to just get a better understanding
of how Brooklyn works?

for a description of the steps.

The description at that page could do with updating - e.g. it is missing the "latches".

Also, the pages could do with a re-vamp to ensure people are pointed to the yaml way whenever
possible, with the underlying Java being described for those who want to look under the covers
or write entities in Java for whatever reason.

Note that those using YAML don't need to know most of this, but they do need to know the order
in which their commands will be executed.

I can give you some additional pointers/info now.

Let's start with a simpler entity type - e.g. org.apache.brooklyn.entity.stock.BasicStartable
- which will illustrate how things wire up.
location: localhost
  - type: org.apache.brooklyn.entity.stock.BasicStartable
      foo: bar
      - type: org.apache.brooklyn.enricher.stock.Transformer
Brooklyn looks up "org.apache.brooklyn.entity.stock.BasicStartable" in the catalog, and instantiates
that entity. Under the covers, the YAML parser creates an EntitySpec, then calls managementContext.getEntityManager().createEntity(spec).

The keys and values under brooklyn.config get turned into org.apache.brooklyn.config.ConfigKeys
(which are set via the spec). In the subsequent entity, these values are then available in
the Java model via entity.config().get(...).

When the entity is instantiated (after its config has been populated etc), the entity.init()
method is called. After that, the entity is offiically "managed" by the management context.

The enrichers listed above are instantiated in a similar way (i.e. the yaml parser creates
an EnricherSpec, and then calls managementContext.getEntityManager().createEnricher(spec).
The enricher then has its enricher.setEntity(entity) method called automatically, which is
where it wires itself up (e.g. subscribes to sensors, etc).

The location is instantiated (see the code org.apache.brooklyn.api.location.LocationRegistry,
LocationSpec, and managementContext.getLocationManager().createLocation(spec)).

When this yaml blueprint is deployed, it automatically calls the start(locations) effector,
if it exists. Effectors can either be declared in Java entities or can be defined in the YAML.
Where the given effector is a simple annotated method, that method will be called (wrapped
in a "task" so that it is shown in the activity view).

Now let's switch to your VanillaSoftwareProcess. e.g.:
location: localhost
  - type:
      install.command: echo installing
      launch.command: echo launching
      checkRunning.command: echo checking
As with the simpler entity example, the start(locations) effector is called. This delegates
to softwareProcessDriverLifecycleEffectorTasks.start(), which executes a sequence the sequence
of actions as sub-tasks (based on the config you have supplied).

You asked above the choice of driver. See

In hindsight, this is definitely architectural/plugability overkill! Almost everything uses
just one driver implementation. One can configure it explicitly, but the "convention over
configuration" is to implement getDriverInterface() to return the driver interface (e.g. VanillaSoftwareProcessDriver.class),
and then for it to reflectively instantiate the expected driver class name by changing he
suffix to SshDriver (e.g. VanillaSoftwareProcessSshDriver).


On 23/08/2017 16:49, Taylor wrote:


For the last few weeks I have been reading the documentation and source code trying to build
a mental model for how brooklyn works. This started when I began looking at writing a custom
entity and the VanillaSoftwareService. I want to understand how the tiny bit of YAML gets
translated into the java objects on the brooklyn host or remote host. For example, where is
the main entry point, how is the driver selected for an entity, when an enricher is invoked
how does that reach a method on the driver.

>From looking at the source code I have discovered various objects and processes but do
not yet have a "start to finish" idea of what goes on. I have read through the CAMP specs
and the brooklyn site and not found a diagram or comments in code.

I would like to work with some experienced developers to fill in my blanks and possibly add
some comments/content/diagrams to the site.

Is anyone knowledgeable in this subject?



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message