Github user rdowner commented on a diff in the pull request:
https://github.com/apache/incubator-brooklyn/pull/966#discussion_r42393703
--- Diff: docs/guide/start/concept-quickstart.md ---
@@ -0,0 +1,35 @@
+---
+title: Brooklyn Concepts Quickstart
+layout: website-normal
+menu_parent: index.md
+---
+
+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]({{site.path.website}}/learnmore/theory.html), and the detailed
description in [Brooklyn Concepts]({{site.path.guide}}/concepts/).
+
+Having examined the concepts below, get started by **[installing and
launching](running.html)** Brooklyn.
+
+
+***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/brooklyn.properties``). 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.
--- End diff --
..."with tasks."
---
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 [email protected] or file a JIRA ticket
with INFRA.
---
