Omit
On September 20, 2017 at 19:20:27, Otto Fowler (ottobackwa...@gmail.com)
wrote:
> With the bundles, archetype, plug-in and parser moves gone 777 will be
> much smaller though.
>
> Also I did not mean to admit Mike’s doc reviews, sorry.
>
> On September 20, 2017 at 18:04:20, Otto Fowler
With the bundles, archetype, plug-in and parser moves gone 777 will be much
smaller though.
Also I did not mean to admit Mike’s doc reviews, sorry.
On September 20, 2017 at 18:04:20, Otto Fowler (ottobackwa...@gmail.com)
wrote:
> I am not taking any of this as starting to do a flame war :) And
I am not taking any of this as starting to do a flame war :) And your
concern is about review not merging right? If it is all reviewed and
accepted, why would 6 merges be preferable? That doesn’t make sense.
Breaking it up only makes sense with regards to review, so that is how I’ll
take it.
Github user merrimanr commented on the issue:
https://github.com/apache/metron/pull/737
Just pushed out a commit that addresses @ottobackwards comments and fixes
the NUM_WORKERS and NUM_ACKERS issue. I also added a warning that appears when
a storm setting changes, telling the user
Recently @nickwallen brought up some good points about the usability of the
Management UI here:
https://github.com/apache/metron/pull/737#issuecomment-330632113. The
issues he brings up apply to all child panels so I think it makes sense to
agree on a common approach and apply it to all of them.
Github user nickwallen commented on a diff in the pull request:
https://github.com/apache/metron/pull/726#discussion_r140089410
--- Diff:
metron-deployment/packaging/ambari/metron-mpack/src/main/resources/common-services/METRON/CURRENT/package/scripts/profiler_master.py
---
@@
Github user justinleet commented on a diff in the pull request:
https://github.com/apache/metron/pull/726#discussion_r140088458
--- Diff:
metron-deployment/packaging/ambari/metron-mpack/src/main/resources/common-services/METRON/CURRENT/package/scripts/profiler_master.py
---
@@
Github user nickwallen commented on a diff in the pull request:
https://github.com/apache/metron/pull/726#discussion_r140087640
--- Diff:
metron-deployment/packaging/ambari/metron-mpack/src/main/resources/common-services/METRON/CURRENT/package/scripts/profiler_master.py
---
@@
Github user nickwallen commented on a diff in the pull request:
https://github.com/apache/metron/pull/726#discussion_r140087395
--- Diff:
metron-deployment/packaging/ambari/metron-mpack/src/main/resources/common-services/METRON/CURRENT/package/scripts/profiler_master.py
---
@@
I was just responding to your statement "Well, if there is an alternative
merge strategy, I’m all ears." I understand that you disagree, but this is
an alternative strategy. I think this approach is feasible and I outlined
how here [1].
The criticism of this approach is the amount of effort and
“Bite off small chunks” is what I keep hearing. I have no idea how to do
that from an already integrated and working branch.
Do you mean I…
- create patch files of whole directories and do a pr per directory, but
the build doesn’t work?
On September 20, 2017 at 15:07:56, Nick Allen
OK,
So, I think that this discussion should be taken up again after the demo.
It will be hopefully
easier then.
Sorry for the static.
Also : remember
https://cwiki.apache.org/confluence/display/METRON/Metron+Extension+System+and+Parser+Extensions
On September 20, 2017 at 14:29:51, Ryan
But wait, I thought we had established that this was such a fundamental
change that it was hard to chunk it out and keep master working.
Jon
On Wed, Sep 20, 2017 at 3:08 PM Nick Allen wrote:
> > Otto: Well, if there is an alternative merge strategy, I’m all ears.
>
> Yes,
> Otto: Well, if there is an alternative merge strategy, I’m all ears.
Yes, the alternative strategy is what I mentioned. :) Copied in below.
> Nick: Are you going to bite-off small chunks of the feature branch and
introduce PRs against master?
On Wed, Sep 20, 2017 at 12:02 PM Otto Fowler
I will attempt to clarify parsers vs sensors. Parsers refer to concrete
parser classes and sensors refer to configuration + one of the parser
classes (with parser class being defined in the configuration). The
architecture was designed so that a parser class can be made dynamic and
behave
Per our prior conversations, I prefer option 2 - treating third party and
built-in the same way. I would love to see signing of extensions in the
future as a potential follow-on so we could verify the Metron built-ins
(and even third parties).
Jon
On Wed, Sep 20, 2017 at 10:22 AM Otto Fowler
Well, if there is an alternative merge strategy, I’m all ears.
As it stands, the only complete code / conceptual review has been the
bundles-lib by mattf.
So there is still a great deal of review activity to do.
Also conceptually there is ( might not be complete )
* the discuss thread topic from
Github user iraghumitra commented on the issue:
https://github.com/apache/metron/pull/762
@merrimanr tested the UI works as explained in the comments
---
Github user iraghumitra commented on a diff in the pull request:
https://github.com/apache/metron/pull/762#discussion_r139988431
--- Diff:
metron-interface/metron-alerts/e2e/alert-details/alert-status/alert-details-status.e2e-spec.ts
---
@@ -0,0 +1,58 @@
+///
+/**
+
So, were the functionality is not FB related, I have been doing PR’s
against master ( such as hdfs service ability to set permissions ).
I don’t think we have talked about the end game PR from feature to master,
I am don’t know how we would do multiple PRs to bring it down
once ‘accepted’. I
So it sounds like these PRs do move us closer to bringing the two branches
together. But I think I am missing your high-level approach though.
How are we going to get all of the functionality from the feature branch
into master? Are you going to bite-off small chunks of the feature branch
and
Simon, I’m sorry, I may not have answered your question.
I use parser and sensors as the same thing, but from what you say I think I
mean parser.
On September 20, 2017 at 10:08:25, Otto Fowler (ottobackwa...@gmail.com)
wrote:
So,
The distinction between ‘sensor’ and ‘parser’ is not clear to me
So,
The distinction between ‘sensor’ and ‘parser’ is not clear to me either, if
it is defined somewhere and I have missed it, please point me in the right
direction.
While I don’t want to fork the discussion, the question is where you find
it so to speak, so about bundles and configurations.
With
Otto,
Can you just clarify what you mean by parsers in this instance. To my mind
parsers in metron are be classes, and do not have any configuration settings.
Instances of parsers are referred to in the ui as sensors, and are essentially
concrete instances of parsers and as such do have
Note: Grok, CSV and JSONMap would be ‘always there’, as they are still
part of the system and not installed individually.
On September 20, 2017 at 09:39:38, Otto Fowler (ottobackwa...@gmail.com)
wrote:
The question has come up about the metron parsers installation vs. parser
extension
The question has come up about the metron parsers installation vs. parser
extension installation differences, and I’d like to get some comments.
Right now ( let’s pretend the UI PR get’s merged to the feature branch for
a minute ) in the original take on this the metron parsers ( bro, yaf,
snort
Right now, these two PR’s are stacked, the UI depends on the BundleSystem
changes.
I would rather bring them down to feature before I do master integration,
than integrate master
into feature and then bring it out to the stacked PR’s. Simple as that.
On September 20, 2017 at 08:35:09, Nick
Github user justinleet commented on a diff in the pull request:
https://github.com/apache/metron/pull/757#discussion_r139957912
--- Diff:
metron-deployment/packaging/ambari/metron-mpack/src/main/resources/common-services/METRON/CURRENT/service_advisor.py
---
@@ -69,6 +69,10 @@
Hi Otto -
What is the plan for bringing the feature branch and master together? Do
these PRs move us closer to bringing the two branches together?
Thanks
On Wed, Sep 20, 2017 at 8:19 AM Otto Fowler wrote:
> Can I get a bump on
Can I get a bump on https://github.com/apache/metron/pull/747 and
https://github.com/apache/metron/pull/761?
The next time I take master is going to be a bit of integration work, and I
would like to unstack and get my stuff integrated first.
Github user ottobackwards commented on a diff in the pull request:
https://github.com/apache/metron/pull/757#discussion_r139951556
--- Diff:
metron-deployment/packaging/ambari/metron-mpack/src/main/resources/common-services/METRON/CURRENT/service_advisor.py
---
@@ -69,6 +69,10 @@
Github user justinleet commented on a diff in the pull request:
https://github.com/apache/metron/pull/757#discussion_r139943087
--- Diff:
metron-deployment/packaging/ambari/metron-mpack/src/main/resources/common-services/METRON/CURRENT/service_advisor.py
---
@@ -69,6 +69,10 @@
Github user justinleet commented on a diff in the pull request:
https://github.com/apache/metron/pull/757#discussion_r139942579
--- Diff:
metron-deployment/packaging/ambari/metron-mpack/src/main/resources/common-services/METRON/CURRENT/package/scripts/rest_commands.py
---
@@
33 matches
Mail list logo