Hey Nick, thanks for starting this thread. Some thought of mine from recent
work in feature branches for Solr and the Pcap query panel:
1. As a general rule, feature branches should be started for code
changes that are not able to be delivered in 1-2 PR's of no more than 1-2k
lines, but a
>> 1. We will need a break down of introducing Spark to the stack; required
version due to HDP support; do we want to update HDP support before
this?; Spark
tuning/defaults; Spark configuration support / UI etc
All sounds useful. I'm not sure how much of that we can do before we have
the code tha
Good points Otto +1 to all that.
On the Spark question, we should definitely be more deliberate about it. We
currently have an implicit dependency on spark through the zeppelin
notebooks. Most implementations I've seen of Metron also have some sort of
Spark work built around them. The current full
I think the feature branch is a good idea, but what is in the feature
branch or feature branches will have to shake out.
I agree in concept with what you have in the jira, but I have two points.
1. We will need a break down of introducing Spark to the stack
- required version due to HDP
