Github user asfgit closed the pull request at:
https://github.com/apache/metron/pull/745
---
So the escalation topic is a new parameter for the REST service in 0.4.1.
It appears that the ambari upgrade story is a bit weak.
Is it possible to modify /var/lib/ambari-agent/cache/
common-services/METRON/0.4.1/package/templates/metron.j2 and
- create a kafka topic called 'metron_escalation'
Hello,
After upgrading from 0.4.1-rc (from last week) to rc4, both Metron
Management UI and Metron REST fail to start with an error related to
"METRON_ESCALATION_TOPIC="{{metron_escalation_topic}}"".
Does anyone know what might be going on here?
Metron Management UI Start output:
Traceback
Github user nickwallen commented on the issue:
https://github.com/apache/metron/pull/740
> What about functions that check for the GLOBAL_ flag, and may make
assumptions that do not hold with a non-z partial configuration?
I thought I had responded to this, but I must not
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/740
thanks @cestella. I am waiting on an answer to the question on other
functions that look for the GLOBAL_CONFIG flag. See above, a couple of times.
---
Github user cestella commented on the issue:
https://github.com/apache/metron/pull/740
YES! I love it. We can create a follow-on for a `-g` option to initialize
the global config, but I like this approach. +1 by inspection, but I want to
make sure @ottobackwards is cool with it as
+1.
- verified signature
- time mvn -q -T 2C -DskipTests install && time mvn -q -T 2C
surefire:test@unit-tests && time mvn -q surefire:test@integration-tests &&
time mvn -q test --projects metron-interface/metron-config && time
build_utils/verify_licenses.sh
- searched for 0.4.0
- ran in full
I don't think this instance is a big deal. But ideally I think any
changes, including a fix like this, should go through the PR process.
On Fri, Sep 8, 2017 at 10:44 PM Casey Stella wrote:
> So, generally the goal is to commit the minimal set of commits squashed by
>
Github user nickwallen commented on a diff in the pull request:
https://github.com/apache/metron/pull/740#discussion_r137926435
--- Diff:
metron-stellar/stellar-common/src/main/java/org/apache/metron/stellar/common/shell/StellarShell.java
---
@@ -287,39 +294,131 @@ private void
Github user nickwallen commented on a diff in the pull request:
https://github.com/apache/metron/pull/740#discussion_r137926399
--- Diff:
metron-stellar/stellar-common/src/main/java/org/apache/metron/stellar/common/shell/StellarExecutor.java
---
@@ -203,6 +205,9 @@ public
Github user nickwallen commented on the issue:
https://github.com/apache/metron/pull/740
I am re-reading through everyone's comments just to make sure I haven't
misjudged all the feedback that I have received so far (thanks to all for
feedback).
> you could also make
Github user nickwallen commented on a diff in the pull request:
https://github.com/apache/metron/pull/740#discussion_r137924431
--- Diff:
metron-stellar/stellar-common/src/main/java/org/apache/metron/stellar/common/shell/StellarShell.java
---
@@ -308,17 +315,68 @@ private void
Github user nickwallen commented on the issue:
https://github.com/apache/metron/pull/740
> Can't we turn everything passed in into json and use the json patch stuff
to "build out' the configuration? Why not have the globals as a
map all the time?
It still is
13 matches
Mail list logo