Re: [VOTE] Move Apache Metron to the Apache Attic and Dissolve PMC

+1 > On Nov 16, 2020, at 5:19 PM, David Lyle wrote: > > +1 > >> On Mon, Nov 16, 2020 at 3:10 PM Michael Miklavcic < >> michael.miklav...@gmail.com> wrote: >> >> +1 >> >>> On Mon, Nov 16, 2020 at 7:01 AM Justin Leet wrote: >>> >>> Hi all, >>> >>> This is a vote thread to retire Metron to t

Re: Discuss: Time to update bundled SOLR support?

aid that, especially for feature branches, having more eyes on it > > is generally pretty helpful if you're interested in hopping in to catch > any > > issues or opportunities. I believe the people most involved are Mike > > Miklavcic, Nick Allen, and Ryan Merriman, so they

Re: [DISCUSS] Parser Aggregation in Management UI

"We planning to add the changes to the latest PR as additional commits to avoid impacting the PR sequence. We will refer to the source PR in the commit message of the fix. Also adding a link to the comment section of the source PR of the change request to the fixing commit to make them connected."

Re: [DISCUSS] Shaded jar classifiers

u spin it up in full-dev > (to ensure ambari doesn't have any dependencies on the jar names)? > > Other than that, I'm +1 to the effort! > > On Mon, Jun 3, 2019 at 8:55 AM Ryan Merriman wrote: > > > I recently opened a PR <https://github.com/apache/metron/pull/1436

[DISCUSS] Shaded jar classifiers

I recently opened a PR that has potential to significantly change (for the better in my opinion) the way our Maven build process works. I want to highlight this and get any feedback on potential issues that may come with this change. I frequently run i

Re: [DISCUSS] Metron RPM spec file changelog

I vote we get rid of them. It's easy enough to look through the commit history to see what changed and when. If there is a need to explain a change I think an inline comment would be more appropriate. On Thu, May 30, 2019 at 3:52 PM Michael Miklavcic < michael.miklav...@gmail.com> wrote: > Duri

Re: [VOTE] Metron Release Candidate 0.7.1-RC1

I am working on the backend change mentioned above ( https://issues.apache.org/jira/browse/METRON-2034) and should a PR up today. On Mon, Apr 29, 2019 at 1:16 PM Tamás Fodor wrote: > As Justin pointed out, we've already implemented the frontend related part > of the aggregation in https://github

Re: [DISCUSS] Next Release

Jon is correct. I am actively working on this and hope to have it completed soon. I realize it will hold up the release so it's a priority for me. On Sat, Mar 30, 2019 at 6:09 PM zeo...@gmail.com wrote: > Isn't the documentation already in progress? > > https://github.com/apache/metron/pull/

[DISCUSS] Upgrading HBase and Kafka support

I have been researching the effort involved to upgrade to HDP 3. Along the way I've found a couple challenging issues that we will need to solve, both involving our integration testing strategy. The first issue is Kafka. We are moving from 0.10.0 to 2.0.0 and there have been significant changes

Re: [DISCUSS] Architecture documentation

of data in Metron. I think we probably want an updated version > of this wiki entry from back in the day - > https://cwiki.apache.org/confluence/display/METRON/Metron+Architecture > > Best, > Mike > > > On Mon, Feb 25, 2019 at 7:18 AM Nick Allen wrote: > >

[DISCUSS] Architecture documentation

Recently I submitted a PR that introduces a large number of changes to a critical part of our code base. Reviewers feel like it is significant enough to document at an architectural level (and I agree). There are a couple points I would like to clarify.

Re: [DISCUSS] Writer class refactor

>> point about not passing 2 separate lists, I suggest that we modify the API >> by passing in something like Map> so that the >> tuples always get acked with respect to their messages. This way we can >> avoid the tuple-message batch boundary problem by ensuring we only ack

Re: [DISCUSS] Writer class refactor

rty writers, and would structure > them as such. > > > > On January 18, 2019 at 13:55:00, Ryan Merriman (merrim...@gmail.com) > wrote: > > Recently there was a bug reported by a user where a parser that emits > multiple messages from a single tuple doesn't work correct

[DISCUSS] Writer class refactor

Recently there was a bug reported by a user where a parser that emits multiple messages from a single tuple doesn't work correctly: https://issues.apache.org/jira/browse/METRON-1968. This has exposed a problem with how the writer classes work. The fundamental issue is this: the writer classes op

Re: [DISCUSS] Knox SSO feature branch review and features

:54 AM Ryan Merriman wrote: > I would also add that defaulting to Knox being on simplifies things at a > technical level. > > On Fri, Nov 16, 2018 at 10:52 AM Michael Miklavcic < > michael.miklav...@gmail.com> wrote: > >> That's fantastic, thanks for that detail

Re: [DISCUSS] Knox SSO feature branch review and features

ments from Otto and Simon. > > On Fri, Nov 16, 2018 at 9:49 AM Ryan Merriman wrote: > > > I was still able to spin up the UI locally and debug in my testing. I am > > in complete agreement, we need to ensure the developer experience doesn't > > change. &

Re: [DISCUSS] Knox SSO feature branch review and features

ng look like for UI testing with Knox enabled? > Anything we lose from a dev testability standpoint? The discussion of > defaults sounds reasonable to me, and I'd like to understand any other > tradeoffs there may be for non-prod deployments like full dev. > > On Fri, Nov 1

Re: [DISCUSS] Knox SSO feature branch review and features

ave we looked at how others integrate? Having all the code and being > > able to track stuff is kind of the point of this whole thing isn’t it? > > > > Maybe this is implied and I’m missing it, if so I apologize. > > > > I think consistency with the rest of the hadoop stack with kn

Re: [DISCUSS] Knox SSO feature branch review and features

d others that are app-specific. Some > explanation of what this looks like would be helpful. > 3) Sounds like this follows pretty naturally from #1 > 4) Relates to #2. I think we need some guidance on what a manual vs > MPack/automated install would look like. > > Cheers, >

Re: [DISCUSS] Knox SSO feature branch review and features

igrate over to LDAP and then be deprecated. The code should still be > pluggable and if anyone wanted to extend it to work with JDBC they could, > or if people wanted to plug in another proxy they could, but this is not > something we would officially support. > > Thanks, > James

Re: [DISCUSS] Knox SSO feature branch review and features

w of several > organisations who are blocked from using Metron by the presence of the JDBC > authentication method in its current form. > > Simon > > On Mon, 12 Nov 2018 at 14:36, Ryan Merriman wrote: > > > Let me clarify on exposing both legacy and Knox URLs at the same ti

Re: [DISCUSS] Knox SSO feature branch review and features

x an optional feature that requires setup > > with > > > the help of some documentation (like Kerberos) while keeping the system > > the > > > way it is now by default. > > > Sounds good to me. > > > > > > > I imagine we'll deprecate JDB

Re: [DISCUSS] Knox SSO feature branch review and features

t; > > without > > > > >>> saying, but I just want to be doubly sure that we're installing > > the > > > > >>> default > > > > >>> via the standard install mechanism as opposed to something > > separate > > >

[DISCUSS] Adding Apache Knox

I want to open a discussion around adding Apache Knox to our architecture. I believe there are some benefits it offers in a couple different areas: 1. It provides a proxy to endpoints for commonly used Hadoop-ecosystem components that we use. This would simplify our web architecture by a

Re: [DISCUSS] Deprecate split-join enrichment topology in favor of unified enrichment topology

+1 On Thu, Nov 1, 2018 at 5:38 PM Casey Stella wrote: > +1 > On Thu, Nov 1, 2018 at 18:34 Nick Allen wrote: > > > +1 > > > > On Thu, Nov 1, 2018, 6:27 PM Justin Leet wrote: > > > > > +1, I haven't seen any case where the split-join topology isn't made > > > obsolete by the unified topology. >

Re: [DISCUSS] Stellar REST client

e: > I believe the issue of introducing and supporting higher latency > enrichments is a systemic one, and should be solved as such, > with the rest and other higher latency enrichments build on top of that > framework. > > > > > On October 19, 2018 at 12:22:28, R

Re: [DISCUSS] Stellar REST client

o not do so, I'd suggest we use HTTP > Components as it's another apache project and under active > development/support. I'd also be ok with OkHttp if it's actively > maintained. > > On Fri, Oct 19, 2018 at 11:46 AM Ryan Merriman > wrote: > > > I

[DISCUSS] Stellar REST client

I want to open up discussion around adding a Stellar REST client function. There are services available to enrich security telemetry and they are commonly exposed through a REST interface. The primary purpose of this discuss thread to collect requirements from the community and agree on a general

Re: [DISCUSS] Batch Profiler Feature Branch

+1 from me. Great work. On Thu, Sep 27, 2018 at 12:41 PM Justin Leet wrote: > I'm +1 on merging the feature branch into master. There's a lot of good > work here, and it's definitely been nice to see the couple remaining > improvements make it in. > > Thanks a lot for the contribution, this is

Re: [DISCUSS] Knox SSO feature branch review and features

I have reviewed a couple different PRs so I'll add some context where I can. Obviously Simon would be the most qualified to answer but I'll add my thoughts. For question 1, while they may not all be necessary I think it does make sense to include them in this feature branch if our primary goal is

Re: [DISCUSS] Internal Metron fields

g those keys, which would be eliminated by > refactoring. > >> On Fri, Sep 7, 2018, 3:50 PM Ryan Merriman wrote: >> >> I recently worked on a PR that involved changing the default behavior of >> the ElasticsearchWriter to store data using field names with the

[DISCUSS] Internal Metron fields

I recently worked on a PR that involved changing the default behavior of the ElasticsearchWriter to store data using field names with the default Metron separator, dots. One of the unfortunate consequences of this is that although dots are allowed in more recent versions of ES, it changes how thes

Re: [DISCUSS] Pcap query branch completion

t; On Thu, Aug 16, 2018, 4:17 PM Ryan Merriman wrote: > > > We discovered a bug in our testing and felt it should be fixed before we > > merge. There is a PR up for review that already has a +1: > > https://github.com/apache/metron/pull/1168. I don't anticipate this >

Re: [DISCUSS] Pcap query branch completion

se who > > contributed to it! > > > > On Thu, Aug 16, 2018 at 8:27 AM Otto Fowler > wrote: > > > >> Looks good, thanks! > >> > >> On August 15, 2018 at 19:38:12, Ryan Merriman (merrim...@gmail.com) > wrote: > >> > >> O

Re: [DISCUSS] Pcap query branch completion

Otto, I believe the items you requested are in the feature branch now. Is there anything outstanding that we missed? The Jiras for the Pcap feature branch should be up to date: https://issues.apache.org/jira/browse/METRON-1554 On Mon, Aug 13, 2018 at 5:13 PM, Ryan Merriman wrote: > - D

Re: [DISCUSS] Pcap query branch completion

e offer guidance on storm > tuning, and that is conceptually the same isn’t it? That is why it comes > to mind. > Maybe this can be a follow on, in the tuning guide? > > On August 13, 2018 at 17:36:41, Ryan Merriman (merrim...@gmail.com) wrote: > > - Date range limits on quer

Re: [DISCUSS] Pcap query branch completion

Thanks for the feedback Otto. I have created a sub task for documenting the Job cleanup documentation: https://issues.apache.org/jira/browse/METRON-1737. I completely agree with you there, this needs to be documented. For the others you marked "Follow on" I will create follow on tasks in Jira.

[DISCUSS] Pcap query branch completion

We are nearing a fully functional Pcap query feature branch. I want to take a moment before we merge to review the original discussion threads and make sure the community is happy with the state of this feature branch before we accept it into master. The original discuss threads are located at: -

Re: [DISCUSS] Deprecating metron-api

there. You might want > to cc user@ as well, to get a broader set of input for the "are people > using it?" question. > > On Fri, Jun 29, 2018 at 5:21 PM Ryan Merriman wrote: > > > We are currently working on adding pcap query capabilities to the Alerts > UI > &g

[DISCUSS] Deprecating metron-api

We are currently working on adding pcap query capabilities to the Alerts UI as part of https://issues.apache.org/jira/browse/METRON-1554. This involves exposing pcap endpoints in our REST application which will make metron-api obsolete. Is anyone currently using this module? Are there any object

Re: [DISCUSS] Field conversions

's another way to skin this cat. > > Ultimately, I think we should just ditch this field transformation > business, as Laurens said, as long as we have a utility to transform > existing data. > > On Tue, Jun 5, 2018 at 8:54 AM Ryan Merriman wrote: > > > Having 2 diff

Re: [DISCUSS] Field conversions

onversion/upgrade > script to change '.' to ':'? > > > On 2018-06-04 13:55, Ryan Merriman wrote: > >> We've been dealing with a reoccurring challenge in Metron. It is common >> for various fields to contain '.' characters for the purpose o

[DISCUSS] Field conversions

We've been dealing with a reoccurring challenge in Metron. It is common for various fields to contain '.' characters for the purpose of making them more readable, namespacing, etc. At one point we only supported Elasticsearch 2.3 which did not allow dots and forced us to use ':' instead. This li

Re: [DISCUSS] Pcap panel architecture

Yes there will be an admin role that can read and delete all. On Fri, May 11, 2018 at 4:11 PM, Otto Fowler wrote: > Do we at least require a admin/super user? See’s all the queues and jobs? > > > On May 11, 2018 at 17:03:34, Ryan Merriman (merrim...@gmail.com) wrote: > > T

Re: [DISCUSS] Pcap panel architecture

for analysis Jon. > > > > > > On May 11, 2018 at 10:14:02, zeo...@gmail.com (zeo...@gmail.com) wrote: > > > > I think baby steps are fine - admin gets access to all, otherwise you > only > > see your own pcaps, but we file a jira for a future add of API securi

Re: [DISCUSS] Pcap panel architecture

> > On Thu, May 10, 2018 at 10:16 AM Ryan Merriman > wrote: > > > Mike, I believe the /pcapGetter/getPcapsByIdentifiers endpoint exposes > the > > fixed query option which we have covered. I agree with you that > > deprecating the metron-api module should be a

Re: [DISCUSS] Release Manager

being our RM. > > On Thu, May 10, 2018 at 12:06 PM Ryan Merriman > wrote: > > > Thanks for all your help Matt. > > > > On Thu, May 10, 2018 at 10:53 AM, Michael Miklavcic < > > michael.miklav...@gmail.com> wrote: > > > > > Thanks Matt for d

Re: [DISCUSS] Release Manager

Thanks for all your help Matt. On Thu, May 10, 2018 at 10:53 AM, Michael Miklavcic < michael.miklav...@gmail.com> wrote: > Thanks Matt for doing this for the community. > > Justin Leet as new lord commander of the Night's Watch? Aye, dilly, dilly. > > On Thu, May 10, 2018 at 9:07 AM, Justin Leet

Re: [DISCUSS] Pcap panel architecture

27;t believe there is a way to "PAUSE" or "SUSPEND" > jobs. That said, I think GET /api/v1/pcap/stop/ is sufficient for > the job management operations. > > On Wed, May 9, 2018 at 11:00 AM, Ryan Merriman > wrote: > > > Now that we are confident we can run

Re: [DISCUSS] Pcap panel architecture

results or cleaning up queries (deleting results) would also be limited to that user. Does this sound reasonable? Do we want to add an admin role that can do everything? Is there anything anyone else wants to discuss with regards to authorization or security in general? On Wed, May 9, 2018 at

Re: [DISCUSS] Pcap panel architecture

ho do packet munging for a living know. > > Jon > > On Wed, May 9, 2018 at 1:00 PM Ryan Merriman wrote: > > > Now that we are confident we can run submit a MR job from our current > REST > > application, is this the desired approach? Just want to confirm. > > > >

Re: [DISCUSS] Pcap panel architecture

Miklavcic < michael.miklav...@gmail.com> wrote: > Sweet! That's great news. The pom changes are a lot simpler than I > expected. Very nice. > > On Tue, May 8, 2018 at 4:35 PM, Ryan Merriman wrote: > > > Finally figured it out. Commit is here: > > http

Re: [DISCUSS] Pcap panel architecture

> > operational complexity, and mpack implications of having another server > > installed and running somewhere on the cluster (also, ssl, kerberos, etc > > etc requirements for that service). > > > > On 8 May 2018 at 14:27, Ryan Merriman wrote: > > > > > +

Re: [DISCUSS] Pcap panel architecture

+1 to having metron-api as it's own service and using a gateway type pattern. On Tue, May 8, 2018 at 8:13 AM, Otto Fowler wrote: > Why not have metron-api as it’s own service and use a ‘gateway’ type > pattern in rest? > > > On May 8, 2018 at 08:45:33, Ryan Merriman (merrim

Re: [DISCUSS] Pcap panel architecture

n jar" to start the > existing pcap service, per the instructions in metron-api/README.md. > > > On Mon, May 7, 2018 at 3:28 PM, Ryan Merriman wrote: > > > To explore the idea of merging metron-api into metron-rest and running > pcap > > queries inside our REST appl

Re: [DISCUSS] Pcap panel architecture

ottobackwa...@gmail.com) wrote: > > RE: Tracking v. users > > The submittal and tracking can associate the submitter with the yarn job > and track that, > regardless of the yarn credentials. > > IE> if all submittals and monitoring are by the same yarn user ( Metron )

Re: [DISCUSS] Pcap panel architecture

t; > Maybe we can do : > > template -> query parameters -> script => yarn info > yarn info + query info + alert context + yarn status => report info -> > stored in a user’s ‘report queue’ > report persistence added to report info > metron-rest -> api to monitor

Re: [DISCUSS] Pcap panel architecture

I started a separate thread on Pcap UI considerations and user requirements at Otto's request. This should help us keep these two related but separate discussions focused. On Fri, May 4, 2018 at 7:19 AM, Michel Sumbul wrote: > Hello, > > > > (Youhouuu my first reply on this kind of mail chain^^

[DISCUSS] Pcap UI user requirements

Continuing a discussion that started in a discuss thread about exposing Pcap query capabilities in the back end. How should we expose this feature to users? Should it be integrated into the Alerts UI or be separate standalone UI? To summarize the general points made in the other thread: - Ad

Re: [DISCUSS] Pcap panel architecture

I know, I was running with it :) > On May 3, 2018, at 10:21 PM, Michael Miklavcic > wrote: > > Tabs vs spaces was a Silicon Valley joke, man :-) > >> On Thu, May 3, 2018, 8:42 PM Ryan Merriman wrote: >> >> Mike, >> >> I never said there was any

Re: [DISCUSS] Pcap panel architecture

rection. > > > > There are a few things to consider if we are going to start moving > > everything into Alerts Ui aren’t there? > > > > It may be a better road to bring it in on it’s own like the alerts ui > > effort, so it can be released with ‘qualifiers’ a

Re: [DISCUSS] Pcap panel architecture

owler wrote: > First thought is why the Alerts-UI and Not a dedicated Query UI? > > > On May 3, 2018 at 14:36:04, Ryan Merriman (merrim...@gmail.com) wrote: > > We are planning on adding the pcap query feature to the Alerts UI. Before > we start this work, I think it is im

[DISCUSS] Pcap panel architecture

We are planning on adding the pcap query feature to the Alerts UI. Before we start this work, I think it is important to get community buy in on the architectural approach. There are a couple different options. One option is to leverage the existing metron-api module that exposes pcap queries th

[DISCUSS] Development environment for UI work

In anticipation of more UI work starting (Alerts UI specifically), I want to kick off a discussion about how we can best provide a backend for UI developers to code against. I believe our full dev environment will not work for this because: 1. It has become more resource intensive over time an

Re: [DISCUSS] Persistence store for user profile settings

es, but thats usually when the > > datastore > > >> is > > >>> a massive set of tables with complex relationships, at least in my > > >>> experience. > > >>> > > >>> We could also use hbase, which probably wouldn'

[DISCUSS] Persistence store for user profile settings

There is currently a PR up for review that allows a user to configure and save the list of facet fields that appear in the left column of the Alerts UI: https://github.com/apache/metron/pull/853. The REST layer has ORM support which means we can store those in a relational database. However I'm

[DISCUSS] Overcoming developer inertia when spinning up new environments

I want to revisit the idea of providing an alternative container-based approach (Docker, Kubernetes, etc) to spinning up Metron that is faster and uses less resources (a "Metron light"). This would provide a way for reviewers to more quickly review and test out changes. Full dev with ansible will

Re: [DISCUSS] Integration/e2e test infrastructure requirements

, Dec 13, 2017 at 4:41 PM, Ryan Merriman wrote: > Jira is here: https://issues.apache.org/jira/browse/METRON-1352. I am > starting to create sub-tasks based on the requirements outlined above and > included in that Jira description. > > I am compiling a list of modules that we

Re: [DISCUSS] Integration/e2e test infrastructure requirements

eature branch name? I just want to find it and set a watch > on it ;) > > > On December 13, 2017 at 15:29:00, Ryan Merriman (merrim...@gmail.com) > wrote: > > I'm open to ideas. What do you think the title should be? > > On Wed, Dec 13, 2017 at 2:13 PM, Otto Fowler

Re: [DISCUSS] Integration/e2e test infrastructure requirements

I'm open to ideas. What do you think the title should be? On Wed, Dec 13, 2017 at 2:13 PM, Otto Fowler wrote: > What is the Master Jira going to be? > > > > On December 13, 2017 at 14:36:50, Ryan Merriman (merrim...@gmail.com) > wrote: > > I am going to start the

Re: [DISCUSS] Integration/e2e test infrastructure requirements

go from there. On Mon, Dec 11, 2017 at 4:10 PM, Ryan Merriman wrote: > The purpose of this discussion is map out what is required to get the POC > started with https://github.com/apache/metron/pull/858 into master. > > The following features were added in the previously

[DISCUSS] Integration/e2e test infrastructure requirements

The purpose of this discussion is map out what is required to get the POC started with https://github.com/apache/metron/pull/858 into master. The following features were added in the previously mentioned PR: - Dockerfile for Metron REST - Dockerfile for Metron UIs - Docker Compose applic

Re: [DISCUSS] e2e test infrastructure

ov 29, 2017 at 1:28 PM, Otto Fowler wrote: > So we will just have a : > > ZK container > Kafka Container > HDFS Container > > and not deploy any metron stuff to them in the docker setup, the test > itself will deploy what it needs and cleanup? > > > On November 29, 2

Re: [DISCUSS] e2e test infrastructure

nal equivalent and limited to the in memory components > functionality and usage. I apologize if that is in fact what you are getting > at. > > Then we could move the integrations and e2e to them. > > > >> On November 29, 2017 at 10:00:20, Ryan Merriman (merrim...@g

Re: [DISCUSS] e2e test infrastructure

another, and that they can be utilized for both the > e2e and integration tests. > >> On Nov 29, 2017 8:00 AM, "Ryan Merriman" wrote: >> >> Thanks for the feedback so far everyone. All good points. >> >> Otto, if we did decide to go down the Docker

Re: [DISCUSS] e2e test infrastructure

at 3:48 PM, Otto Fowler > > wrote: > > > > > As long as there is not a large chuck of custom deployment that has to > be > > > maintained docker sounds ideal. > > > I would like to understand what it would take to create the docker e2e > > env.

Re: [GitHub] metron issue #852: METRON-1239 Drop extra dev environments

I wrote the ReadMeUtils class a long time ago as a way to make documenting the REST endpoints easier. The Controller class methods are annotated so that endpoint documentation is displayed in Swagger but it is also duplicated in the README. It seemed like a good idea at the time to provide a uti

[DISCUSS] e2e test infrastructure

Currently the e2e tests for our Alerts UI depends on full dev being up and running. This is not a good long term solution because it forces a contributor/reviewer to run the tests manually with full dev running. It would be better if the backend services could be made available to the e2e tests w

Re: [DISCUSS] Upcoming Release

aseProcess-Step15-Cleanup > ) > > So you’re correct that the version of development builds is currently set to > 0.4.2. After we actually make a release of 0.4.2, we’ll change dev build > to 0.4.3 (regardless of whether we expect the following release to > be 0.4.3 or 0.5.0). >

Re: [DISCUSS] Upcoming Release

Matt, I think we are currently on version 0.4.2. If that is the case would the next version be 0.4.3? Ryan On Fri, Nov 17, 2017 at 3:31 PM, Matt Foley wrote: > (With release manager hat on) > > The community has proposed a release of Metron in the near future, > focusing on Meta-alerts runnin

Re: [GitHub] metron issue #823: METRON-1286 Add MIN & MAX Stellar functions

Which 2 files are in /home/travis/build/apache/ metron/metron-stellar/stellar-common/target/rat.txt? Do you get this same error when you run mvn apache-rat:check locally? You will need to either add licenses to those 2 files or add exclusions in /metron/pom.xml if they should in fact be excluded

Re: [DISCUSS] Build broken due to transitive dependencies

t; > > How to upgrade compiler on CentOS 6: > > > > $ sudo yum install centos-release-scl > > $ sudo yum install devtoolset-3-toolchain > > $ scl enable devtoolset-3 bash > > $ > > > > On 2017-10-13 11:12, Ryan Merriman wrote: > > > >>

Re: [DISCUSS] Build broken due to transitive dependencies

We recently ran into this and the cause was an old C++ compiler version. It wants a compiler that has support for C++11: https://gcc.gnu.org/projects/cxx-status.html#cxx11. On Fri, Oct 13, 2017 at 1:00 PM, Laurens Vets wrote: > ... > [INFO] --- frontend-maven-plugin:1.3:npm (ng build) @ metron-c

[DISCUSS] How should Management UI save changes?

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.

Re: [DISUCUSS] [CALL FOR COMMENT] Metron parsers as actual extensions

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 differe

Re: [DISCUSS] Metron release 0.4.1

Matt, This was committed a few hours. I think you saw it but just wanted to make sure. Ryan > On Sep 7, 2017, at 11:26 AM, Matt Foley wrote: > > Okay. Please ping when committed. > Also, any input on https://issues.apache.org/jira/browse/METRON-1163 ? > > On 9/7/17, 7:39

Re: [DISCUSS] Metron release 0.4.1

Matt, We recently found a bug that's breaking certain features in the management UI. The fixes are still in review ( https://github.com/apache/metron/pull/729 and https://github.com/apache/metron/pull/730) and should make it in soon. It would be good to include these if possible. Ryan On Thu,

Re: REST and ManagementUI : Grok

; > When I create a new parser config in the ui (+) the Grok pattern > label/button disappear the moment i select a parser type, even grok. > > > > > On August 17, 2017 at 11:36:24, Ryan Merriman (merrim...@gmail.com) wrote: > > The UI shows the Grok editor when you select

Re: REST and ManagementUI : Grok

The UI shows the Grok editor when you select the GrokParser as the parser type. Did the package of the GrokParser change by chance? Sounds like this is a bug to me. You can view, edit, test and save grok patterns so I would say you can do everything in the UI . The fact that a pattern can be re

Re: [DISCUSS] Using Yarn package manager for metron-alerts

Thanks for this Raghu. You make a pretty compelling argument. I'm +1 on moving to yarn. Ryan On Wed, Aug 16, 2017 at 3:51 PM, Nick Allen wrote: > It is also my understanding that > ​there is no hard cut-over to yarn > . > ​After we > introduce the yarn.lock > ​ > ​,​ > as a developer you can

Re: [DISCUSS] Persisting user data

bases and I'd prefer > to > > side-step those holy wars by being agnostic. > > > > On Wed, Aug 2, 2017 at 9:36 PM, Ryan Merriman > wrote: > > > >> Spring supports a variety of databases including Postgres. I have no > >> problem with using Postgre

Re: [DISCUSS] Persisting user data

mbari Views for now. It’s just a way to get GUI > dashboards without writing all the infrastructure for it, which as you say > is somewhat water under the bridge. > > Cheers, > > --Matt > > > > [1] https://zookeeper.apache.org/doc/r3.1.2/zookeeperAdmin.html > > >

Re: [DISCUSS] Persisting user data

Is viewer login auth sufficient for this? > 3. Will you assume Ambari exists? Did you consider using Ambari Views as > the basis? (https://cwiki.apache.org/confluence/display/AMBARI/Views ) > > On 7/26/17, 2:54 PM, "Ryan Merriman" wrote: > > In anticipation of ME

[DISCUSS] Persisting user data

In anticipation of METRON-988 being merged into master, there will be a need to persist user preferences such as UI layout, saved searches, search history, etc. I think where and how we persist this data should be discussed in order to facilitate a design. This data won't be large in scale and ma

Re: [DISCUSSION] METRON-1046 -> Stellar Files for multiple statement execution

A couple things I would like to point out. You can test Stellar statements without having to send data through parser/enrichment topologies. There is a REST endpoint that allows you to pass in a sample message and parser config and returns a message with Stellar statements applied. This could ea

Re: Metron REST - Logging Config

The only way I know of is to change log4j.properites. Did you every figure out a better way? On Tue, Jul 11, 2017 at 2:10 PM, Nick Allen wrote: > How do I configure logging for Metron REST on a deployed host? > > Right now a log4j.properties file gets packaged into the metron-rest JAR > itself.

[DISCUSS] Search in REST

This discussion is an attempt to clarify some questions and discuss design decisions related to METRON-1022. The primary purpose of METRON-1022 is to provide a foundation for building Metron-specific Elasticsearch (or other search engine implementations) functions in our REST application. This tr

Re: [DISCUSS] METRON-994 -> Rest v. Stellar ( api of record )?

Makes sense to me. Are we talking about exposing an endpoint that just executes a stellar statement? We already have one but it's scope is limited to applying stellar transformations to a sample message. Assuming we would just add on to that controller. What Jiras are going to come out of th

Re: [VOTE] Apache Metron 0.4.0 release

+1 (binding) - Verified Keys - Verified mvn clean install - Ran full dev and performed several smoke tests including: - tested several REST endpoints - verified data in ES - tested Management UI - verified Storm topologies in Storm UI - verified data in Kiban

Re: Build failures

Can you confirm you're on the master branch? I see "metron-streaming" in your path to RestTestingUtil and that was changed a LONG time ago. You're likely on a really old branch. Ryan On Wed, Jun 28, 2017 at 3:27 PM, Vasco Yordanov wrote: > Hello , I just forked from github and it seems that "

  1   2   >