Great discussion guys! It seems that it is a shared need, and I wanted to discuss with you as I was not sure about my approach.
Andrew, I like your proposal, thanks! Thanks, Andrea On 3 May 2016 at 13:05, Aled Sage <[email protected]> wrote: > 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 <[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? >>> >>> >
