Comment 2 for bug 1808805

Revision history for this message
Scott Shambarger (sshambar) wrote :

Hit this on v11, but it doesn't appear fixed even in master.

OK, I've managed to fix the issue with a couple changes:

First, submit the topology to the storm cluster (and not run it locally):

--- ansible/roles/monasca/templates/monasca-thresh/monasca-thresh.json.j2.orig
+++ ansible/roles/monasca/templates/monasca-thresh/monasca-thresh.json.j2
@@ -1,3 +1,3 @@
 {
- "command": "/opt/storm/bin/storm jar /monasca-thresh-source/monasca-thresh-*/thresh/target/monasca-thresh-*-SNAPSHOT-shaded.jar -Djava.io.tmpdir=/var/lib/monasca-thresh/data monasca.thresh.ThresholdingEngine /etc/monasca/thresh-config.yml monasca-thresh local",
+ "command": "/opt/storm/bin/storm jar /monasca-thresh-source/monasca-thresh-*/thresh/target/monasca-thresh-*-SNAPSHOT-shaded.jar -Djava.io.tmpdir=/var/lib/monasca-thresh/data monasca.thresh.ThresholdingEngine /etc/monasca/thresh-config.yml monasca-thresh",
     "config_files": [

This will submit the topology, and then exit... so the second fix is to not restart the registration container:

--- ansible/roles/monasca/handlers/main.yml.orig
+++ ansible/roles/monasca/handlers/main.yml
@@ -73,2 +73,3 @@
     dimensions: "{{ service.dimensions }}"
+ restart_policy: no
   when:

With these combined changes, the topology is correctly registered, and running in the storm cloud.

NOTE: monasca_thresh will fail on future runs as the topology is already present... basically the start program should probably borrow the logic from the default container's docker/start.sh which waits for mariadb, kafka, and then checks if the topology is already present, and if so just exits normally... but that would probably require dropping in a monasca_extended_start file too...

If you like, I can submit a pull request...