brooklyn-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From tbou...@apache.org
Subject [16/25] brooklyn-docs git commit: Move website content up a level and simplify config
Date Fri, 16 Feb 2018 10:26:55 GMT
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/5b360c27/website/learnmore/theory.md
----------------------------------------------------------------------
diff --git a/website/learnmore/theory.md b/website/learnmore/theory.md
deleted file mode 100644
index eddb2f8..0000000
--- a/website/learnmore/theory.md
+++ /dev/null
@@ -1,184 +0,0 @@
----
-layout: website-normal
-title: The Theory behind Brooklyn
-children:
-- { section: "Why Brooklyn?" }
-- { section: Blueprints }
-- { section: Benefits }
-- { section: Standards }
----
-
-<div class="jumobotron" markdown="1">
-
-Brooklyn is a framework for modeling, monitoring, and managing applications
-through autonomic blueprints.
-
-</div>
-
-## Why Brooklyn?
-
-Building and deploying applications in the cloud computing era has changed many
-things. Provision a bare server just-in-time, and use automated tools to install
-an application. Use APIs to add the server to a load balancer. When load goes
-up, provision another server; when load drops, kill a server to save money.
-
-Many new tools have appeared that take advantage of this new era. However each
-of them only solve part of the problem and don't consider the big picture. For
-example, configuration management tools such as Chef can, in a single command,
-provision a new cloud server then install and configure an application -- but
-they require extra programming to reconfigure an load balancer whenever the pool
-of web servers changes. Amazon Auto Scaling can provision new servers and update
-load balancers, but it is dependent on CloudWatch -- this means either using
-proxy metrics such as average response time, or writing more code to expose an
-application's real metrics. A dedicated monitoring tool may be able to easily
-monitor the key metrics with little effort, but its alerts will need to be
-integrated it into the server provisioning process.
-
-So all the tools are there to to create and manage a cloud-scale application
-that can adapt to demand to meet user expectations without wasting money on
-superfluous services - but you will need several such tools and it is up to you
-to integrate them into your deployment plan. Some of these tools -- such as the
-Amazon Web Services web of EC2, CloudWatch, AutoScaling and CloudFormation --
-mean that you may suffer from lock-in. Related projects in OpenStack (Heat,
-Ceilometer, Murano, Solum, etc) provide similar functionality but again for a
-restricted target. The most common policies (such as minimising request latency)
-may be easy, but less common policies such as follow-the-sun and follow-the-moon
-may be up to you to implement. Your scaling policies may understand that
-"high demand = add another server", but may not understand requirements such as
-some clustered services requiring an odd number of instances to prevent voting
-deadlocks.
-
-
-## How Brooklyn Can Help
-
-In this context the advantage of Brooklyn becomes apparent: a single tool is
-able to manage provisioning and application deployment, monitor an application's
-health and metrics, understand the dependencies between components (such as
-knowing that adding a new web server means that the load balancer needs
-reconfiguration) and apply complex policies to manage the application. The tool
-provides a REST API and a GUI, and allows the autonomic blueprints to be treated
-as an integral part of the application. With Brooklyn, these policies become
-modular components which can be reused and easily added to blueprints.
-
-Brooklyn is about deploying and managing applications: composing a full stack
-for an application; deploying to cloud and non-cloud targets; using monitoring
-tools to collect key health/performance metrics; responding to situations
-such as a failing node; and adding or removing capacity to match demand.
-
-
-## Blueprints
-
-A Brooklyn blueprint defines an application, using a declarative YAML syntax
-supporting JVM plugins. A basic blueprint might comprise a single process,
-such as a web-application server running a WAR file or a SQL database and
-its associated DDL scripts. More complex blueprints encompass combinations
-of processes across multiple machines and services, such as a load-balancing
-HTTP server or SDN controller fronting a cluster of J2EE application
-servers, in turn connected to a resilient cluster of SQL database servers.
-Even larger clustered application running in multiple regions can be
-described, with features such as message buses with resilient brokers,
-cacheing tiers of NoSQL key-value store servers, a high-availability
-database cluster and multiple application components connected across these
-layers.
-
-One main benefit of these blueprints is that they are composable:
-best-practice blueprints for one process or pattern (e.g. a Cassandra
-cluster) can be incorporated in other blueprints (e.g. an application with a
-Cassandra cluster as one component). Another major benefit is that the
-blueprints can be treated as source code as part of an applications
-codebase: tested, tracked, versioned, and hardened as an integral part of
-the devops process. In some ways, Brooklyn is to run-time what Maven is to
-build-time.
-
-
-### Blueprints Turn into Deployments
-
-Brooklyn knows about Chef, Salt, and similar tools, and APT and Yum and
-plain old shell scripts, for deploying application components. Blueprints
-are built from a mixture of both off-the-shelf packages such as Tomcat,
-MySQL, Cassandra, and many more from our library; and components that are
-bespoke to individual applications; together with policies that allow the
-application to be self-managing.
-
-Brooklyn is built for the cloud, and will take a blueprint and deploy it to
-one of many supported clouds or even to multiple different clouds, or to
-private infrastructure (bring-your-own-node), or to other platforms. It will
-dynamically configure and connect all the different components of an
-application, e.g. so load balancers know where the web servers are and the
-web applications know where the database is.
-
-Brooklyn collects key metrics to monitor the health of applications; for
-example, by sending a request and measuring latency, or installing
-monitoring tools and using those to read a server's management interface to
-determine the request queue length. These metrics can be fed into policies,
-which automatically take actions such as restarting a failed node, or
-scaling out the web tier if user demand exceeds capacity. This allows an
-application to be self-managing: to recover itself from simple failures, to
-scale out when demand increases and meet capacity; then scale in as demand
-drops and stop paying for spare capacity.
-
-In short, Brooklyn blueprints allow the best practices for deploying and
-managing complex software to be codified as part of the software development
-process.
-
-
-
-### <a id="benefits"></a> Agile and Flexible
-
-Brooklyn is a product built from the ground up for application agility. This
-includes portability across non-cloud, cloud, and PaaS targets; devops-style
-infrastructure-as-code applied to applications; and real-time autonomic
-management based on promise theory. Some introductions to these concepts,
-associated tools, and open specifications may be useful.
-
-Cloud computing at its core is about provisioning resources on-demand. The most
-widely known aspect is IaaS (infrastructure-as-a-service) such as Amazon EC2,
-Softlayer, Google Cloud Platform, Apache CloudStack, or OpenStack. By leveraging
-the Apache jclouds project (and contributing heavily to it), the Brooklyn
-project is able to work with a large number of such providers. Higher up the
-stack, however, there is an increasingly diverse set of platform targets, from
-PaaS (platform-as-a-service) such as Cloud Foundry and Apache Stratos, through
-to myriad containers and runtime fabrics such as LXC/Docker, Apache Mesos,
-Apache Karaf, Apache Hadoop, and Apache Usergrid and other backend-as-a-service
-environments. Brooklyn is based on the premise that applications may need to run
-in any or all of these, and the model must be flexible and open enough to
-support this.
-
-The buzzword-compliant trends of agile and devops have reinforced many important
-lessons:
-
-- The truth is in the code (not any ancillary documents)
-- If it isn't tested then assume it isn't working
-- Toolchain integration and APIs are key to a project's success
-- Even more critical is empowering all stakeholders to a project
-- Brooklyn's focus on blueprinting and modeling as code and APIs serves these
-principles.
-
-### Autonomic Computing
-
-Another major influence on the design of Brooklyn are the ideas of autonomic
-computing and promise theory. It is not necessary to have a thorough
-understanding of these to use Brooklyn, but contributors tend to become versed
-in these ideas quickly. Essentially, autonomics is based on the concept of
-components looking after themselves where possible (self-healing,
-self-optimizing, etc), and exposing a sensor (data outputs) and effector
-(operations) API where they may need to controlled by another element. Promise
-theory extends this approach by introducing the idea that communicating intent
-(through promises) is a more reliable basis for complex cooperating systems than
-obligation-based effectors. Tools such as CF Engine, Chef, Puppet, Ansible, and
-Salt apply promise theory to files and processes on machines; Brooklyn can
-leverage all of these tools, complementing it with an application-oriented
-model.
-
-### Standards
-
-Finally we note some emerging standards in this area. OASIS CAMP 
-(<a href="https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=camp#technical">Cloud
Application Management for Platforms</a>) 
-and TOSCA 
-(<a href="https://www.oasis-open.org/committees/tosca/">Topology and Orchestration
Specification for Cloud Applications</a>) 
-both define YAML application models similar to Brooklyn's. 
-CAMP focuses on the REST API for interacting with such a
-management layer, and TOSCA focuses on declarative support for more
-sophisticated orchestration. Currently Brooklyn uses a YAML which complies with
-CAMP's syntax and exposes many of the CAMP REST API endpoints. We would like to
-support the hot-off-the-press TOSCA YAML and expand the CAMP REST API coverage.

http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/5b360c27/website/meta/license.md
----------------------------------------------------------------------
diff --git a/website/meta/license.md b/website/meta/license.md
deleted file mode 100644
index 02d05f4..0000000
--- a/website/meta/license.md
+++ /dev/null
@@ -1,203 +0,0 @@
----
-layout: website-normal
-title: Legal
----
-
-## License
-
-Apache Brooklyn is released to the public as open source under the 
-terms of the [Apache License, v2.0](http://www.apache.org/licenses/LICENSE-2.0), a full copy
of
-which is included below for reference.
-
-Unless required by applicable law or agreed to in writing, software
-distributed under the License is distributed on an "AS IS" BASIS,
-WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-See the License for the specific language governing permissions and
-limitations under the License.
-
-
-## Trademark
-
-The Brooklyn name and logo are trademarks owned by the Apache Software Foundation.
-
-
-## Apache License, v2.0 (reference copy)
-
-
-{% highlight text %}
-
-                                 Apache License
-                           Version 2.0, January 2004
-                        http://www.apache.org/licenses/
-
-   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
-
-   1. Definitions.
-
-      "License" shall mean the terms and conditions for use, reproduction,
-      and distribution as defined by Sections 1 through 9 of this document.
-
-      "Licensor" shall mean the copyright owner or entity authorized by
-      the copyright owner that is granting the License.
-
-      "Legal Entity" shall mean the union of the acting entity and all
-      other entities that control, are controlled by, or are under common
-      control with that entity. For the purposes of this definition,
-      "control" means (i) the power, direct or indirect, to cause the
-      direction or management of such entity, whether by contract or
-      otherwise, or (ii) ownership of fifty percent (50%) or more of the
-      outstanding shares, or (iii) beneficial ownership of such entity.
-
-      "You" (or "Your") shall mean an individual or Legal Entity
-      exercising permissions granted by this License.
-
-      "Source" form shall mean the preferred form for making modifications,
-      including but not limited to software source code, documentation
-      source, and configuration files.
-
-      "Object" form shall mean any form resulting from mechanical
-      transformation or translation of a Source form, including but
-      not limited to compiled object code, generated documentation,
-      and conversions to other media types.
-
-      "Work" shall mean the work of authorship, whether in Source or
-      Object form, made available under the License, as indicated by a
-      copyright notice that is included in or attached to the work
-      (an example is provided in the Appendix below).
-
-      "Derivative Works" shall mean any work, whether in Source or Object
-      form, that is based on (or derived from) the Work and for which the
-      editorial revisions, annotations, elaborations, or other modifications
-      represent, as a whole, an original work of authorship. For the purposes
-      of this License, Derivative Works shall not include works that remain
-      separable from, or merely link (or bind by name) to the interfaces of,
-      the Work and Derivative Works thereof.
-
-      "Contribution" shall mean any work of authorship, including
-      the original version of the Work and any modifications or additions
-      to that Work or Derivative Works thereof, that is intentionally
-      submitted to Licensor for inclusion in the Work by the copyright owner
-      or by an individual or Legal Entity authorized to submit on behalf of
-      the copyright owner. For the purposes of this definition, "submitted"
-      means any form of electronic, verbal, or written communication sent
-      to the Licensor or its representatives, including but not limited to
-      communication on electronic mailing lists, source code control systems,
-      and issue tracking systems that are managed by, or on behalf of, the
-      Licensor for the purpose of discussing and improving the Work, but
-      excluding communication that is conspicuously marked or otherwise
-      designated in writing by the copyright owner as "Not a Contribution."
-
-      "Contributor" shall mean Licensor and any individual or Legal Entity
-      on behalf of whom a Contribution has been received by Licensor and
-      subsequently incorporated within the Work.
-
-   2. Grant of Copyright License. Subject to the terms and conditions of
-      this License, each Contributor hereby grants to You a perpetual,
-      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
-      copyright license to reproduce, prepare Derivative Works of,
-      publicly display, publicly perform, sublicense, and distribute the
-      Work and such Derivative Works in Source or Object form.
-
-   3. Grant of Patent License. Subject to the terms and conditions of
-      this License, each Contributor hereby grants to You a perpetual,
-      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
-      (except as stated in this section) patent license to make, have made,
-      use, offer to sell, sell, import, and otherwise transfer the Work,
-      where such license applies only to those patent claims licensable
-      by such Contributor that are necessarily infringed by their
-      Contribution(s) alone or by combination of their Contribution(s)
-      with the Work to which such Contribution(s) was submitted. If You
-      institute patent litigation against any entity (including a
-      cross-claim or counterclaim in a lawsuit) alleging that the Work
-      or a Contribution incorporated within the Work constitutes direct
-      or contributory patent infringement, then any patent licenses
-      granted to You under this License for that Work shall terminate
-      as of the date such litigation is filed.
-
-   4. Redistribution. You may reproduce and distribute copies of the
-      Work or Derivative Works thereof in any medium, with or without
-      modifications, and in Source or Object form, provided that You
-      meet the following conditions:
-
-      (a) You must give any other recipients of the Work or
-          Derivative Works a copy of this License; and
-
-      (b) You must cause any modified files to carry prominent notices
-          stating that You changed the files; and
-
-      (c) You must retain, in the Source form of any Derivative Works
-          that You distribute, all copyright, patent, trademark, and
-          attribution notices from the Source form of the Work,
-          excluding those notices that do not pertain to any part of
-          the Derivative Works; and
-
-      (d) If the Work includes a "NOTICE" text file as part of its
-          distribution, then any Derivative Works that You distribute must
-          include a readable copy of the attribution notices contained
-          within such NOTICE file, excluding those notices that do not
-          pertain to any part of the Derivative Works, in at least one
-          of the following places: within a NOTICE text file distributed
-          as part of the Derivative Works; within the Source form or
-          documentation, if provided along with the Derivative Works; or,
-          within a display generated by the Derivative Works, if and
-          wherever such third-party notices normally appear. The contents
-          of the NOTICE file are for informational purposes only and
-          do not modify the License. You may add Your own attribution
-          notices within Derivative Works that You distribute, alongside
-          or as an addendum to the NOTICE text from the Work, provided
-          that such additional attribution notices cannot be construed
-          as modifying the License.
-
-      You may add Your own copyright statement to Your modifications and
-      may provide additional or different license terms and conditions
-      for use, reproduction, or distribution of Your modifications, or
-      for any such Derivative Works as a whole, provided Your use,
-      reproduction, and distribution of the Work otherwise complies with
-      the conditions stated in this License.
-
-   5. Submission of Contributions. Unless You explicitly state otherwise,
-      any Contribution intentionally submitted for inclusion in the Work
-      by You to the Licensor shall be under the terms and conditions of
-      this License, without any additional terms or conditions.
-      Notwithstanding the above, nothing herein shall supersede or modify
-      the terms of any separate license agreement you may have executed
-      with Licensor regarding such Contributions.
-
-   6. Trademarks. This License does not grant permission to use the trade
-      names, trademarks, service marks, or product names of the Licensor,
-      except as required for reasonable and customary use in describing the
-      origin of the Work and reproducing the content of the NOTICE file.
-
-   7. Disclaimer of Warranty. Unless required by applicable law or
-      agreed to in writing, Licensor provides the Work (and each
-      Contributor provides its Contributions) on an "AS IS" BASIS,
-      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
-      implied, including, without limitation, any warranties or conditions
-      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
-      PARTICULAR PURPOSE. You are solely responsible for determining the
-      appropriateness of using or redistributing the Work and assume any
-      risks associated with Your exercise of permissions under this License.
-
-   8. Limitation of Liability. In no event and under no legal theory,
-      whether in tort (including negligence), contract, or otherwise,
-      unless required by applicable law (such as deliberate and grossly
-      negligent acts) or agreed to in writing, shall any Contributor be
-      liable to You for damages, including any direct, indirect, special,
-      incidental, or consequential damages of any character arising as a
-      result of this License or out of the use or inability to use the
-      Work (including but not limited to damages for loss of goodwill,
-      work stoppage, computer failure or malfunction, or any and all
-      other commercial damages or losses), even if such Contributor
-      has been advised of the possibility of such damages.
-
-   9. Accepting Warranty or Additional Liability. While redistributing
-      the Work or Derivative Works thereof, You may choose to offer,
-      and charge a fee for, acceptance of support, warranty, indemnity,
-      or other liability obligations and/or rights consistent with this
-      License. However, in accepting such obligations, You may act only
-      on Your own behalf and on Your sole responsibility, not on behalf
-      of any other Contributor, and only if You agree to indemnify,
-      defend, and hold each Contributor harmless for any liability
-      incurred by, or claims asserted against, such Contributor by reason
-      of your accepting any such warranty or additional liability.
-{% endhighlight %} 

http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/5b360c27/website/meta/sitemap.md
----------------------------------------------------------------------
diff --git a/website/meta/sitemap.md b/website/meta/sitemap.md
deleted file mode 100644
index 7411976..0000000
--- a/website/meta/sitemap.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-layout: website-normal
-title: Site Map
----
-
-<div class="sitemap">
-
-<div class="search_right">
-<form method="get" id="simple_google" class="searchform" action="http://www.google.com/search">
-                <input type="text" class="searchinput" name="brooklyn-search" placeholder="Google
site search: type &amp; hit enter">
-                <input type="hidden" name="q" value="">
-            </form>
-</div>
-
-{% assign visited = "" | split: "|" %}
-{% assign site_items = "" | split: "|" %}
-<ul>
-{% for item in site.data.menu %}
-  {% push site_items item %}
-  {% include sitemap-item.html %}
-{% endfor %}
-</ul>
-
-</div>
-

http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/5b360c27/website/meta/versions.md
----------------------------------------------------------------------
diff --git a/website/meta/versions.md b/website/meta/versions.md
deleted file mode 100644
index d9678cc..0000000
--- a/website/meta/versions.md
+++ /dev/null
@@ -1,90 +0,0 @@
----
-layout: website-normal
-title: Versions
----
-
-## Current Version: {{ site.brooklyn-stable-version }}
-
-The current stable version of Brooklyn is {{ site.brooklyn-stable-version }}:
-
-* [Download]({{ site.path.website }}/download/)
-* [User Guide]({{ site.path.guide }}/)
-* [Release Notes]({{ site.path.guide }}/misc/release-notes.html)
-
-This documentation was generated {{ site.time | date_to_string }}.
-
-
-## Version History
-
-Apache Brooklyn has made the following releases:
-
-* **[0.12.0](/v/0.12.0/)**: OSGI container runtime, improved catalog and bundle integration
(September 2017)
-
-* **[0.11.0](/v/0.11.0/)**: Improved cloud support, additional blueprinting features (May
2017)
-
-* **[0.10.0](/v/0.10.0/)**: Improved blueprints and CLI, new DSL features,
-  Karaf distribution. (December 2016)
-
-* **[0.9.0](/v/0.9.0/)**: Adds Brooklyn CLI client, RPM package, getting started
-  using Vagrant. First release as an Apache top-level project! (April 2016)
-
-* **[0.8.0-incubating](/v/0.8.0-incubating/)**: Package rename to org.apache.brooklyn, and
many other improvements. (September 2015)
-
-* **[0.7.0-incubating](/v/0.7.0-incubating/)**: New policies, more clouds, improved Windows
support and many other improvements. First Apache-endorsed binary release! (July 2015)
-
-* **[0.7.0-M2-incubating](/v/0.7.0-M2-incubating/)**: YAML, persistence, Chef, Windows, Docker.
The first Apache release! (December 2014)
-
-Note: These "Version History" links are to permanent versions in the archive,
-different to the "Current Version" links.
-To prevent accidentally referring to out-of-date information,
-a banner is displayed when accessing content from these.
-If you wish you can
-<a href="javascript:void(0);" onclick="set_user_versions_all();">disable all warnings</a>
or
-<a href="javascript:void(0);" onclick="clear_user_versions();">re-enable all warnings</a>.
-
-
-## Ancient Versions
-
-The versions below were made prior to joining The Apache Software Foundation, therefore **they
are not endorsed by
-Apache** and are not hosted by Apache or their mirrors. You can obtain the source code by
-[inspecting the branches of the pre-Apache GitHub repository](https://github.com/brooklyncentral/brooklyn/branches/stale)
-and binary releases by
-[querying Maven Central for io.brooklyn:brooklyn.dist](http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22io.brooklyn%22%20AND%20a%3A%22brooklyn-dist%22).
-
-* **[0.7.0-M1](/v/0.7.0-M1/)**: YAML, Chef, catalog, persistence (Apr 2014)
-
-* **[0.6.0](/v/0.6.0/)**: use of spec objects, chef and windows support, more clouds (Nov
2013)
-
-* **[0.5.0](/v/0.5.0/)**: includes new JS GUI and REST API, rebind/persistence support, cleaner
model and naming conventions, more entities (May 2013)
-
-* **[0.4.0](/v/0.4.0/)**: initial public GA release of Brooklyn to Maven Central, supporting
wide range of entities and examples (Jan 2013)
-
-
-### Versioning
-
-Brooklyn follows [semantic versioning](http://semver.org/) with a leading `0.` qualifier:
-
-    0.<major>.<minor>[.<patch>]-<qualifier>
-
-Breaking backward compatibility increments the `<major>` version.
-New additions without breaking backward compatibility ups the `<minor>` version.
-Bug fixes and misc changes bumps the `<patch>` version.
-New major and minor releases zero the less significant counters.
-
-From time to time, the Brooklyn project will make snapshots, milestone releases, and other
qualified versions available,
-using the following conventions:
-
-* Milestone versions (`-M<n>`) have been voted on and have been through some QA,
-  but have not had the extensive testing as is done on a release.
-
-* Snapshot (`-SNAPSHOT`) is the bleeding edge.
-  With good test coverage these builds are usually healthy, 
-  but they have not been through QA or voted on.
-
-* Nightly builds (`-N<date>`) represent a snapshot which has
-  been given a permanent version number, typically for use by other projects.
-  The same caveats as for snapshot releases apply (no QA or Apache vote). 
-
-* Release Candidate builds (`-RC<n>`) are made in the run-up to a release;
-  these should not normally be used except for deciding whether to cut a release.
-


Mime
View raw message