brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aled Sage (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (BROOKLYN-503) Shell.env should work with SaltEntity
Date Fri, 26 May 2017 10:03:04 GMT

    [ 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)

Mime
View raw message