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 <[email protected]> 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? > -- Andrew Kennedy ; Founder clocker.io project ; @grkvlt ; Cloudsoft
