brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From johnmccabe <...@git.apache.org>
Subject [GitHub] incubator-brooklyn pull request: fix bash web cluster template in ...
Date Fri, 08 Jan 2016 17:40:36 GMT
GitHub user johnmccabe opened a pull request:

    https://github.com/apache/incubator-brooklyn/pull/1135

    fix bash web cluster template in default catalog

    the template `4-resilient-bash-web-cluster-template` did not deploy successfully in either
`0.8.0-incubating` or `0.9.0-SNAPSHOT` (not checked earlier releases), the following problems
are encountered if you try to deploy:
    
    - the cluster member Bash Web Server instances fail to deploy as they try to use the placeholder
location defined in the `2-bash-web-server-template` catalog entry. Have commented out the
location in template 2.
    
    The observed result for the next two points were that the balancer would never have any
Bash Web Server instances added to `proxy.serverpool.targets` and you would just get 404s
when browsing to the balancer endpoint.
    
    - the `app.port` sensor isn't populated as its trying to create a sensor on the `BasicApplication`
while the config exists on the `VanillaSoftwareProcess`.
    Added an id `bash-web-server` to the `vanilla-bash-server` in template 2 to allow us to
address the config when creating the `my-app` StaticSensor.
    
    - the balancer is unable to populate `member.sensor.hostname` as its attempting to pull
`host.subnet.hostname` from the  `BasicApplication` while this sensor is on the `VanillaSoftwareProcess`.
Added a `Propagator`.
    
    - moved the `SshCommandSensor` to template 2 so that it could access the `output.txt`
and added `enricher.producer` to the `YamlTimeWeightedDeltaEnricher` so it could pull from
the `VanillaSoftwareProcess` (id `bash-web-server`)
    - minor usability tweaks turning off sticky session and reducing the `maxPoolSize`
    
    Would appreciate someone having a look at the changes here, as its quite a change in the
structure of the template app and may be indicative of issues elsewhere?
    
    **Not** resolved - the `my.message` config in template 4 is not overriding that set in
template 2.


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

    $ git pull https://github.com/johnmccabe/incubator-brooklyn default-catalog-updates

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

    https://github.com/apache/incubator-brooklyn/pull/1135.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 #1135
    
----
commit b2330fe89c3d634429d045169e3ab3a28e187662
Author: John McCabe <john@johnmccabe.net>
Date:   2016-01-08T14:27:59Z

    replace placeholder location with a comment in template 2
    - template 2 is used as the memberSpec in template 4, if the placeholder location is left
in place then deployments of template 4 fail as that placeholder is used when deploying the
Bash Web Nodes

commit 56b03bbbb9d790cdf0d46858dcfb7a12e96a1187
Author: John McCabe <john@johnmccabe.net>
Date:   2016-01-08T17:32:43Z

    fix bash web cluster template in default catalog
    
    the template `4-resilient-bash-web-cluster-template` did not deploy successfully in either
`0.8.0-incubating` or `0.9.0-SNAPSHOT` (not checked earlier releases), the following problems
are encountered if you try to deploy:
    
    - the cluster member Bash Web Server instances fail to deploy as they try to use the placeholder
location defined in the `2-bash-web-server-template` catalog entry. Have commented out the
location in template 2.
    
    The observed result for the next two points were that the balancer would never have any
Bash Web Server instances added to `proxy.serverpool.targets` and you would just get 404s
when browsing to the balancer endpoint.
    
    - the `app.port` sensor isn't populated as its trying to create a sensor on the `BasicApplication`
while the config exists on the `VanillaSoftwareProcess`.
    Added an id `bash-web-server` to the `vanilla-bash-server` in template 2 to allow us to
address the config when creating the `my-app` StaticSensor.
    
    - the balancer is unable to populate `member.sensor.hostname` as its attempting to pull
`host.subnet.hostname` from the  `BasicApplication` while this sensor is on the `VanillaSoftwareProcess`.
Added a `Propagator`.
    
    - moved the `SshCommandSensor` to template 2 so that it could access the `output.txt`
and added `enricher.producer` to the `YamlTimeWeightedDeltaEnricher` so it could pull from
the `VanillaSoftwareProcess` (id `bash-web-server`)
    - minor usability tweaks turning off sticky session and reducing the `maxPoolSize`
    
    Would appreciate someone having a look at the changes here, as its quite a change in the
structure of the app and may be indicative of issues elsewhere?
    
    **Not** resolved - the `my.message` config in template 4 is not overriding that set in
template 2.

----


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

Mime
View raw message