Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/711
+1
---
Github user merrimanr commented on the issue:
https://github.com/apache/metron/pull/711
The latest commit addresses the escalateMany request.
---
Github user nickwallen commented on the issue:
https://github.com/apache/metron/pull/711
Ok, then I will leave that for @merrimanr to respond to. In my opinion we
can tackle escalate many in a future PR.
---
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/711
@nickwallen
The question of the assumption of how complete the passed data is can wait.
My point about escalateOne vs. escalateMany stands.
---
Github user nickwallen commented on the issue:
https://github.com/apache/metron/pull/711
@ottobackwards What do you think about this one? Good enough for a first
pass?
---
Github user nickwallen commented on the issue:
https://github.com/apache/metron/pull/711
I think your current approach works best right now. Keep it simple. +1
---
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
Github user merrimanr commented on the issue:
https://github.com/apache/metron/pull/711
I don't think it matters that much but I'm leaning towards keeping the REST
layer simple. The Alerts UI will be responsible for adding other annotations
so it's not a stretch to add these too.
Github user nickwallen commented on the issue:
https://github.com/apache/metron/pull/711
> The alert or list of alerts should be annotated with the user who
escalated the alert(s) and time the alert(s) was escalated.
That JIRA works for me @merrimanr . So the assumption
Github user merrimanr commented on the issue:
https://github.com/apache/metron/pull/711
I create a Jira for this:
https://issues.apache.org/jira/browse/METRON-1147. It's could probably use
some more description but this is a start.
---
If your project is set up for it, you can
Github user nickwallen commented on the issue:
https://github.com/apache/metron/pull/711
@ottobackwards Those are all important points to consider. I just don't
know that we need to think through all of that right now. I am thinking of
this PR as a very basic, first pass. Let's
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/711
part of the issue is there is no use case for how this is going to be used
beyond the general. How often do analysts that have possibly 1000s of alerts
find the one magic alert?
I
Github user simonellistonball commented on the issue:
https://github.com/apache/metron/pull/711
@ottobackwards agreed, this is very separate from the management ui (won't
touch, or be used by anything in the management ui). Also agreed this is a
separate entity, but one that will be
Github user nickwallen commented on the issue:
https://github.com/apache/metron/pull/711
I don't see the need for additional docs. Escalating an alert here means
to push the alert data to a Kafka topic. That is all documented in the README,
as far as I can see. Additional detailed
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/711
Platform wise, we want both. The metron configuration UI is the 'default'
ui for the project, but the rest api is the main supported interface. As such
they should be treated as separate
Github user simonellistonball commented on the issue:
https://github.com/apache/metron/pull/711
I'd say the docs belong with the UI docs, since this is pretty much an
endpoint to drive the UI buttons, no?
---
If your project is set up for it, you can reply to this email and have
15 matches
Mail list logo
