Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/853
+1 by inspection
---
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/853
Sorry, I'll try to get back to this today
---
Github user merrimanr commented on the issue:
https://github.com/apache/metron/pull/853
Any other feedback @ottobackwards or is this ready to go?
---
Github user mmiklavc commented on the issue:
https://github.com/apache/metron/pull/853
@merrimanr this looks much better. I'm +1 via inspection pending any
further feedback from @ottobackwards.
---
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/853
This looks great, one small comment from review
---
Github user merrimanr commented on the issue:
https://github.com/apache/metron/pull/853
I took @ottobackwards's suggestion and added a "type" parameter that can be
used to independently manage user settings for different types of clients. I
moved the users settings for the Alerts UI
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/853
I am not an expert in hbase, I cannot say how i'd implement it.
The version thing we can leave out, it will be just as good or bad as what
we have in zookeeper right?
I think the
Github user merrimanr commented on the issue:
https://github.com/apache/metron/pull/853
I think it's a fair question @ottobackwards. Anything that might affect
how the HBase table is laid out should be worked out now or we're back to
altering tables during upgrades. Currently the
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/853
Of course re-reading your comment, I see you specifically didn't account
for these, but I think there are some basic tweaks to allow for this that don't
presuppose far flung 20% use cases.
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/853
First, nice work.
Second, I have this question:
Since we will have some unknown number of rest clients, that may want to
save 'configuration' associated with a user, and not just
Github user merrimanr commented on the issue:
https://github.com/apache/metron/pull/853
The latest commit switches the persistence for storing user settings to
HBase rather than a RDBMS as discussed on the dev list. Instead of fields
being stored in RDBMS columns, the user settings
Github user mmiklavc commented on the issue:
https://github.com/apache/metron/pull/853
Bump @merrimanr
---
Github user mmiklavc commented on the issue:
https://github.com/apache/metron/pull/853
I don't see anything that should be problematic in ES 5.6.2, but can you
confirm @merrimanr?
---
Github user merrimanr commented on the issue:
https://github.com/apache/metron/pull/853
I will address 6 shortly. For 5, should we explore a more flexible store
in this PR? Or at least validate that an RDBMS is the right choice? I think
this is something we should tackle now as it
Github user justinleet commented on the issue:
https://github.com/apache/metron/pull/853
We're good on 1-4.
For point 5. I'd still like to see a note in the upgrading, even if it
gets removed when the more flexible store is added. I don't know when we'll get
around to using
Github user cestella commented on the issue:
https://github.com/apache/metron/pull/853
Just ducking in here, @merrimanr is this ready for review? Specifically,
the responses to @justinleet 's questions have all been factored into the
current code for this PR, right? If yes,
Github user merrimanr commented on the issue:
https://github.com/apache/metron/pull/853
Here are my thoughts on your responses.
1. I think we're in agreement. This is how this PR currently works.
2. No, saved searches are currently stored client-side. I think the plan
Github user justinleet commented on the issue:
https://github.com/apache/metron/pull/853
To respond to the questions in the description (and maybe kick off
conversation, especially if anyone disagrees) + add my own thoughts. In no
particular order.
@merrimanr Let me know if
Github user merrimanr commented on the issue:
https://github.com/apache/metron/pull/853
Done
---
Github user justinleet commented on the issue:
https://github.com/apache/metron/pull/853
@merrimanr Can you deconflict this?
---
Github user merrimanr commented on the issue:
https://github.com/apache/metron/pull/853
Ambari does not manage this config. It is only included in the base
application.yml as a default setting. I don't feel like this setting should be
in Ambari for a couple reasons: changing it
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/853
What I get to was, the setting should be exposed in ambari if ambari
manages the config.
---
Github user merrimanr commented on the issue:
https://github.com/apache/metron/pull/853
Each environment will have it's own application.yaml. Full dev has one,
our testing environment has one, Ambari ships one etc. There is also a base
application.yaml that has the defaults
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/853
Does ambari own the application.yaml currently?
---
24 matches
Mail list logo
