[
https://issues.apache.org/jira/browse/BROOKLYN-503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026085#comment-16026085
]
Aled Sage commented on BROOKLYN-503:
------------------------------------
Thanks for reporting this - agreed the salt entity should support {{shell.env}}.
I had a look at what would be required to pass the {{shell.env}} through using
the current approach. As some starting points:
*
https://github.com/apache/brooklyn-library/blob/master/software/cm/salt/src/main/java/org/apache/brooklyn/entity/cm/salt/SaltEntity.java
is the entity interface
*
https://github.com/apache/brooklyn-library/blob/master/software/cm/salt/src/main/java/org/apache/brooklyn/entity/cm/salt/impl/SaltEntityImpl.java
is the entity implementation
*
https://github.com/apache/brooklyn-library/blob/master/software/cm/salt/src/main/java/org/apache/brooklyn/entity/cm/salt/impl/SaltLifecycleEffectorTasks.java#L122
is in the class where it defines the behaviour for start/stop
*
https://github.com/apache/brooklyn-library/blob/master/software/cm/salt/src/main/java/org/apache/brooklyn/entity/cm/salt/impl/SaltSshTasks.java#L164
is what it calls to generate the task for the actual ssh command (assuming you
are using salt masterless)
* {{saltCall}} can be configured with {{.environmentVariables(Map)}}.
It's therefore a case of passing those environment variables through. From the
entity, the env you configured can be retrieved with
{{entity.config().get(SHELL_ENVIRONMENT)}}.
However, the way {{LifecycleEffectorTasks}} and the {{SshEffectorTaskFactory}}
is used can be hard to get your head around, so when someone picks this up,
please shout out early for help (e.g. on IRC or mailing list) if you want it.
---
Interesting suggestion by Geoff that we could change {{SaltEntity}} to extend
{{SoftwareProcess}}. That does feel tempting, at a high-level. However, the way
{{SaltSshTasks}} etc has been written, I suspect it's not straight forward to
just re-use the existing code/structure of {{SoftwareProcess}}.
Also, my got feel is that we should just let Salt do its thing - we should pass
appropriate config through to salt (including environment variables etc). If we
extended {{VanillaSoftwareProcess}}, there's be a bunch of additional hooks for
executing scripts etc. It would be un-obvious what order those would execute
versus us executing Salt. Arguably if one wants to execute additional commands,
then change the salt recipe to do that.
---
Andres, do you fancy having a go adding support for this? If you do, we can
certainly support you on IRC and on dev@brooklyn.
> Shell.env should work with SaltEntity
> -------------------------------------
>
> Key: BROOKLYN-503
> URL: https://issues.apache.org/jira/browse/BROOKLYN-503
> Project: Brooklyn
> Issue Type: Improvement
> Affects Versions: 0.10.0
> Environment: Ubuntu 14.04
> Reporter: Andres Garcia Garcia
> Labels: env, salted
>
> I am using Brooklyn to deploy servers configured with Salt.
> I am trying to deploy one VM with a web server and another with MySQL, and
> link them together using env variables in the salt pillars.
> Based on the sample templates, this is my yaml.
> name: Salt LAMP deployment (Brooklyn Example)
> {code}
> services:
> - id: mysql
> name: mysql
> type: org.apache.brooklyn.entity.cm.salt.SaltEntity
> formulas:
> - https://github.com/saltstack-formulas/mysql-formula/archive/master.tar.gz
> start_states:
> - mysql
> pillars:
> - mysql
> pillarUrls:
> - ftp://xxx/wordpress-example.tar
> - id: wordpress
> name: wordpress
> type: org.apache.brooklyn.entity.cm.salt.SaltEntity
> formulas:
> - https://github.com/saltstack-formulas/php-formula/archive/master.tar.gz
> -
> https://github.com/saltstack-formulas/wordpress-formula/archive/master.tar.gz
> - https://github.com/saltstack-formulas/apache-formula/archive/master.tar.gz
> - https://github.com/saltstack-formulas/mysql-formula/archive/master.tar.gz
> start_states:
> - mysql.client
> - php.ng
> - php.ng.mysql
> - wordpress
> - apache
> - apache.config
> - apache.vhosts.standard
> pillars:
> - php
> - wordpress
> - apache
> - mysql
> pillarUrls:
> - ftp://xxx/filezilla.tar
> brooklyn.config:
> shell.env:
> MYSQL_URL: $brooklyn:entity("mysql").attributeWhenReady("host.name")
> location:
> jclouds:aws-ec2:
> identity: xxx
> credential: xxx
> region: us-west-2
> inboundPorts:
> - 22
> - 80
> - 3306
> hardwareId: t2.small
> {code}
> And then, inside the pillars, I configure them as follows
> {code}
> wordpress:
> sites:
> username: xxx
> password: xxx
> database: xxx
> dbhost: {{ salt['environ.get']('MYSQL_URL') }}
> {code}
> However, the MYSQL_URL env variable is resolved to none.
> I got word from svet in the IRC channel that SaltEntity doesn't support
> shell.env. I think it would be really helpful to make this option available
> in order to configure multinode deployments with Salt.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
