You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@brooklyn.apache.org by "ASF GitHub Bot (JIRA)" <ji...@apache.org> on 2017/08/29 16:31:02 UTC

[jira] [Commented] (BROOKLYN-503) Shell.env should work with SaltEntity

    [ https://issues.apache.org/jira/browse/BROOKLYN-503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16145603#comment-16145603 ] 

ASF GitHub Bot commented on BROOKLYN-503:
-----------------------------------------

GitHub user tbouron opened a pull request:

    https://github.com/apache/brooklyn-library/pull/123

    Convert AnsibleEntity and SaltEntity to be real SoftwareProcess

    # Background
    
    Salt and Ansible are currently installed by Brooklyn and:
    - are used in masterless mode
    - use SSH to check their health
    - but more importantly, are used to install and manage software. For instance, using Salt, one can install and start/stop Apache or Nginx (or any other software). The same applies to Ansible.
    They are effectively software processes as they manage software lifecycle but are not considered as such based on their current implementation.
    
    # Issue
    
    The current implementation uses `EffectorStartableImpl` instead of `SoftwareProcessImpl`. This has some side effects which might be surprising for users, such as:
    - the inboundPort (`provisioning.properties`) are not applied when the SG is created (on supported clouds)
    - the auto-opening port on SG by creating config keys finishing by `.port` does not works
    - the `shell.env` are also not applied ([BROOKLYN-503](https://issues.apache.org/jira/browse/BROOKLYN-503))
    - if the location is using a machine name customiser, this will throw a NPE as the `CALLER_CONTEXT` is not set
    
    _This list is not exhaustive, I just wanted to illustrate the most common issues a user will bump into by using those entities._
    
    # Solution
    
    Make those 2 entities real `SoftwareProcess`es, this PR is doing just that. I simply moved around the existing code to make it match the phases of `SoftwareProcess`.
    
    This has been tested with YAML test available [here for Ansible](https://github.com/brooklyncentral/brooklyn-ansibleentity/blob/master/tests/ansible.tests.bom) and [here for Salt](https://github.com/brooklyncentral/brooklyn-saltentity/blob/master/tests/salt.tests.bom)

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/tbouron/brooklyn-library update/ansible-salt-conversion

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/brooklyn-library/pull/123.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #123
    
----
commit 38a9f780299678d706a690fcca8a2de28a4d0ed7
Author: Thomas Bouron <th...@cloudsoftcorp.com>
Date:   2017-08-29T15:05:58Z

    Convert AnsibleEntity to a SoftwareProcess entity

commit ac837bcaba844ffe203edb957630896a48094d54
Author: Thomas Bouron <th...@cloudsoftcorp.com>
Date:   2017-08-29T16:07:30Z

    Convert SaltEntity to a SoftwareProcess entity

----


> 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.4.14#64029)