brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aled Sage <aled.s...@gmail.com>
Subject Re: YAML blueprint: install package utility
Date Tue, 03 May 2016 11:05:38 GMT
I lean towards Andrew's approach, rather than a special 
$brooklyn.installPackage. Note that different distros use different 
package names sometimes, so the parameters to such a function can get 
annoying.

I've been hesitant about us going down the road of 
`brooklyn-commands.sh` for achieving portable blueprints. It feels like 
we are increasing the overlap with things like Chef, Salt, Ansible and 
Puppet (which we can build on top of with Brooklyn).

However, if we keep brooklyn-commands.sh small and focused, then maybe 
it's a good idea.

Aled

p.s. I want to decrease the use of `BashCommands.installExecutable()`. 
The bash command it generates, with all the alternatives and 
parentheses, does not look like nice Bash. A brooklyn-commands.sh could 
do it much cleaner, with a properly structured multi-line if...elif... 
(or whatever).


On 03/05/2016 11:43, Andrew Kennedy wrote:
> How about an alternative approach - for all SoftwareProcess entities,
> Brooklyn will copy over a script file called `brooklyn-commands.sh` and the
> entity commands will soutce this script before running the rest of their
> configured commands. The script will contain OS agnostic functions written
> in Bash that do things like install packages, download Curl, get a file
> from a URL etc. Then, the install config might look like this:
>
> ```
> install.commands: |
>    brooklyn-installPackages apt:openjdk-1.8.0 yum:java-1.8.0-openjdk-devel
> java-1.8.0
>    brooklyn-installPackages curl
>    brooklyn-runAsRoot cp /tmp/whatever /etc/hosts
> ```
>
> Andrew.
>
> On Tue, 3 May 2016 at 11:24 Andrea Turli <andrea.turli@cloudsoftcorp.com>
> wrote:
>
>> hi,
>>
>> I’ve been thinking about an utility to simplify the YAML blueprint
>> creation: from my experience when using VanillaSoftwareProcess is annoying
>> to write a portable script just to install a package (say, java) valid for
>> apt, yum, etc so I usually write it (multiple times) just for an OS.
>>
>> To increase the portability of the YAML blueprint I’d like to suggest we
>> extend the brooklyn DSL with something like:
>> ```
>> $brooklyn.installPackage(“curl”)
>> $brooklyn:installPackage({"apt", "openjdk-1.8.0", "yum",
>> "java-1.8.0-openjdk-devel"}, "java-1.8.0")
>> ```
>> instead of things like
>> ```
>> which curl || \
>>          { sudo apt-get update && sudo apt-get install curl ; } || \
>>          { sudo yum update && sudo yum install curl ; } || \
>>          { echo WARNING: cannot install curl && exit 1 ; }
>> ```
>> I’m not entirely sure this feature fits well on the DSL.
>>
>> Alternatively, we could add a configKey to VanillaSoftwareProcess called
>> requiredPackages for a more declarative approach (@googlielmo's idea)
>>
>> Wdyt?
>>


Mime
View raw message