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?
