Hi Guglielmo. I'm not sure to follow your idea of "stacks", could you elaborate on that please?
Best. On Tue, 3 May 2016, 13:38 Guglielmo Nigri, < [email protected]> wrote: > 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? > > >>> > > >>> > > > > > > -- Thomas Bouron • Software Engineer @ Cloudsoft Corporation • http://www.cloudsoftcorp.com/ Github: https://github.com/tbouron Twitter: https://twitter.com/eltibouron
