brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rdowner <>
Subject [GitHub] incubator-brooklyn pull request: Add a "quick overview of concepts...
Date Mon, 19 Oct 2015 16:35:07 GMT
Github user rdowner commented on a diff in the pull request:
    --- Diff: docs/guide/start/ ---
    @@ -0,0 +1,35 @@
    +title: Brooklyn Concepts Quickstart
    +layout: website-normal
    +The following section gives a quick summary of the main Brooklyn concepts you will encounter
in Getting Started.  For later investigation of these concepts see [The Theory Behind Brookln]({{}}/learnmore/theory.html),
and the detailed description in [Brooklyn Concepts]({{}}/concepts/).
    +Having examined the concepts below, get started by **[installing and launching](running.html)**
    +***Deployment and Management*** Brooklyn is built for agile deployment of applications
across cloud and other targets, and real-time autonomic management. "Autonomics" is the concept
of components looking after themselves where possible (self-healing, self-optimizing, etc).
    +***Blueprints***  A blueprint defines an application by specifying its components, such
as processes, or combinations of processes across multiple machines and services. The blueprint
also specifies the inter-relationships between the configurations of the components.
    +***Entities*** The central concept in a Brooklyn deployment is that of an entity. An
entity represents a resource under management (individual machines or software processes)
or logical collections of these. Entities are arranged hierarchically. They can have events,
operations, and processing logic associated with them, and it is through this mechanism that
the active management is delivered.
    +***Applications*** are the top level entities that are the parents of all other entities.
    +***Configuration*** Entities can have arbitrary configuration values, which get inherited
by their child entities. You can set global (Brooklyn-wide) properties in (``~/.brooklyn/``).
 Common configuration keys have convenient aliases called "flags".
    +***Sensors*** are the mechanism for entities to expose information for other entities
to see.  Sensors from an entity can be subscribed to by other entities to track changes in
the entity’s activity.
    +***Effectors*** are the mechanism for entities to expose the operations that can be invoked
on it by other entities.  The invoker is able to track the execution of that effector. 
    +***Lifecycle*** The management context of Brooklyn associates a "lifecycle" with Brooklyn
entities.  Common operations are start, stop, and restart (whose meaning differs slightly
for applications and processes; the details are in the concepts guide linked above).  Starting
an application results in the start() operation being performed recursively (typically in
parallel) on the application's children.
    +***Tasks*** Lifecycle and other operations in Brooklyn are tracked as tasks. This allows
current and past processing to be observed by operators, and processing to be managed across
multiple management nodes.
    +***Locations*** can be defined in order to specify where the processes of an application
will run.  Brooklyn supports different cloud providers and pre-prepared machines, known as
"BYON" (Bring Your Own Nodes).
    +***Policies*** Policies perform the active management enabled by Brooklyn. Entities can
have  Policy instances attached to them, which can subscribe to sensors from other entities
or run periodically.  When they run they can perform calculations, look up other values, invoke
effectors or emit sensor values from the entity with which they are associated.
    --- End diff --
    There's also *enrichers*, which subscribe to a sensor, or multiple sensors, and output
a new sensor. For example, the enricher which sums a sensor across multiple entities (used
to get the total requests-per-second for all the web servers in a cluster), and the enricher
which calculates a 60-second rolling average.

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

View raw message