I propose a declarative approach. For example we could add a configKey to VanillaSoftwareProcess called requiredPackages.
This way, one could just specify the prerequisite packages, sort of dependencies for the software process -- this would also open up interesting possibilities such as “stacks” as bundled dependencies. A declarative approach would also work for Windows (or non-bash environments). Cheers, Guglielmo On 3 May 2016 at 14:28, Andrea Turli <[email protected]> wrote: > 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? > >>> > >>> > > >
