Mailing-List: contact dev-help@brooklyn.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@brooklyn.apache.org
From: Alex Heneveld <alex.heneveld@cloudsoftcorp.com>
To: dev@brooklyn.apache.org
Subject: Making blueprint upgrades easier - feature proposal
Message-ID: <0d209a84-7081-39aa-25a5-8f750967066b@cloudsoft.io>
Date: Wed, 29 Mar 2017 14:44:15 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0)
 Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="------------F1270D9FA3937C6E3BAD0D01"
archived-at: Wed, 29 Mar 2017 13:44:34 -0000

--------------F1270D9FA3937C6E3BAD0D01
Content-Type: multipart/alternative;
 boundary="------------7E02C655F3EF634B5618B980"


--------------7E02C655F3EF634B5618B980
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit


Hi All-

I've been working with a few others on how we can simplify the process 
writing new versions of blueprints and applying them to existing 
deployments.

* Imagine being able to do *cat blueprint.bom | * **br catalog add 
--upgrade --restart* to have deployments pick up a new version of a 
blueprint you're working *on (and an editor in the UI)** * Move towards 
a pure infrastructure as code ideal where all changes are done by 
redeploying blueprints (as opposed to changing config programmatically)

Let us know what you think -- whether general, you like the idea, or a 
super-specific question on some subtle implication of a network config 
change.

The doc is attached as PDF and at [1].

Best
Alex

[1] 
https://docs.google.com/document/d/1Lm47Kx-cXPLe8BO34-qrL3ZMPosuUHJILYVQUswEH6Y


--------------7E02C655F3EF634B5618B980
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=utf-8">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    Hi All-<br>
    <br>
    I've been working with a few others on how we can simplify the
    process writing new versions of blueprints and applying them to
    existing deployments.<br>
    <br>
    * Imagine being able to do  <b>cat blueprint.bom | </b>
    <meta charset="utf-8">
    <b style="font-weight:normal;"
      id="docs-internal-guid-06b94770-1a4a-3a30-1750-7d5d49553f6e"><span style="font-size:11pt;font-family:Arial;color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap;"><b>br catalog add --upgrade --restart</b>  to have deployments pick up a new version of a blueprint you're working </span></b><span
      style="font-weight:normal;"><span style="font-size:11pt;font-family:Arial;color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap;">on (and an editor in the UI)</span></span><b
      style="font-weight:normal;"
      id="docs-internal-guid-06b94770-1a4a-3a30-1750-7d5d49553f6e"><span style="font-size:11pt;font-family:Arial;color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap;">
</span></b>
    <meta charset="utf-8">
    * Move towards a pure infrastructure as code ideal where all changes
    are done by redeploying blueprints (as opposed to changing config
    programmatically)<br>
    <br>
    Let us know what you think -- whether general, you like the idea, or
    a super-specific question on some subtle implication of a network
    config change.<br>
    <br>
    The doc is attached as PDF and at [1].<br>
    <br>
    Best<br>
    Alex<br>
    <br>
    [1] 
<a class="moz-txt-link-freetext" href="https://docs.google.com/document/d/1Lm47Kx-cXPLe8BO34-qrL3ZMPosuUHJILYVQUswEH6Y">https://docs.google.com/document/d/1Lm47Kx-cXPLe8BO34-qrL3ZMPosuUHJILYVQUswEH6Y</a><br>
    <br>
  </body>
</html>

--------------7E02C655F3EF634B5618B980--

--------------F1270D9FA3937C6E3BAD0D01--