brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ahgittin <...@git.apache.org>
Subject [GitHub] incubator-brooklyn pull request: Adds docs: security-guidelines an...
Date Wed, 25 Nov 2015 09:22:25 GMT
Github user ahgittin commented on a diff in the pull request:

    https://github.com/apache/incubator-brooklyn/pull/1064#discussion_r45844194
  
    --- Diff: docs/guide/yaml/blueprinting-tips.md ---
    @@ -0,0 +1,105 @@
    +---
    +title: Blueprinting Tips
    +layout: website-normal
    +---
    +
    +## YAML Recommended
    +
    +The recommended way to write a blueprint is as a YAML file. This is true both for building
    +an application out of existing blueprints, and for building new integrations.
    +
    +The use of Java is reserved for those use-cases where the provisioning or configuration
logic 
    +is very complicated.
    +
    +
    +## Faster Dev-Test
    +
    +Writing a blueprint is most efficient and simple when testing is fast, and when testing
is
    +done incrementally as features of the blueprint are written.
    +
    +The slowest stages of deploying a blueprint are usually VM provisioning and downloading/installing
    +of artifacts (e.g. RPMs, zip files, etc).
    +
    +Options for speeding up provisioning include those below.
    +
    +### Deploying to the "localhost" location
    +
    +This is fast and simple, but has some obvious downsides:
    +
    +* Artifacts are installed directly on your desktop/server.
    +
    +* The artifacts installed during previous runs can interfere with subsequent runs.
    +
    +* Some entities require `sudo` rights, which must be granted to the user running Brooklyn.
    +
    +
    +### Deploying to Bring Your Own Nodes (BYON)
    +
    +A BYON location can be defined, which avoids the time required to provision VMs. This
is fast,
    +but has the downside that artifacts installed during a previous run can interfere with
subsequent 
    +runs.
    +
    +A variant of this is to use Vagrant (e.g. with VirtualBox) to create VMs on your local
machine,
    --- End diff --
    
    In fact we should reference the Getting Started Guide improvements @johnmccabe on joining
which uses this, i believe?


---
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

Mime
View raw message