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

Re: Discuss: Time to update bundled SOLR support?

pecially 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 may have some more &

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

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> that > > ha

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: >

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

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? > >

[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

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: > > > I don't think we should hold up thi

[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

Re: [DISCUSS] Writer class refactor

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 a >> tuple when all associated messages are successfu

Re: [DISCUSS] Writer class refactor

riters, 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 correctly: > h

[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

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

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

ke 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 16, 2018 at 7:20

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

ked 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 knox he

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

> 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, > Mike > > > On Thu, Nov

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

n 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 > > 12.11.2018, 07:3

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

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 time. > The > > ba

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

s opposed to something > > separate > > > > and > > > > >>> manual. > > > > >>> > > > > >>> On the subject of Zuul wrt Nodejs filters. I'd like to hear some > > > more > > > > >>> detail on:

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

eve 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, Ryan Merriman (m

Re: [DISCUSS] Stellar REST client

o, 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 want to open up discussion ar

[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

Re: [DISCUSS] Internal Metron fields

cing 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

Re: [DISCUSS] Pcap query branch completion

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

those 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: > >> > >> Otto, I believe

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

gt; 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 queries > > Can you describe

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

. 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 > > as

[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

Re: [DISCUSS] Field conversions

t; > 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 different patterns for configuring field nam

Re: [DISCUSS] Field conversions

ade > 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 of making >> them >> more readable, namespacing, etc.

[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

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 <ottobackwa...@gmail.com> 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..

Re: [DISCUSS] Pcap panel architecture

> > 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 security, > > which more mature SOCs

Re: [DISCUSS] Release Manager

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

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

n'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 <merrim...@gmail.com> > wrote: > > > Now th

Re: [DISCUSS] Pcap panel architecture

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 1:22 PM, Ryan Merrim

Re: [DISCUSS] Pcap panel architecture

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

Re: [DISCUSS] Pcap panel architecture

< 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 <merrim...@gmail.com> wrote: > > > Finally figured it out. Commit is here: > > https:

Re: [DISCUSS] Pcap panel architecture

gt; > 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 <merrim...@gmail.com> 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 <ottobackwa...@gmail.com> 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

Re: [DISCUSS] Pcap panel architecture

start the > existing pcap service, per the instructions in metron-api/README.md. > > > On Mon, May 7, 2018 at 3:28 PM, Ryan Merriman <merrim...@gmail.com> wrote: > > > To explore the idea of merging metron-api into metron-rest and running > pcap > > queries inside o

Re: [DISCUSS] Pcap panel architecture

a single or > co-operative set of services, that service can maintain the mapping. > > > > On May 7, 2018 at 09:39:52, Ryan Merriman (merrim...@gmail.com) wrote: > > Otto, your use case makes sense to me. We'll have to think about how to > manage the user to job relationships

Re: [DISCUSS] Pcap panel architecture

thing like that.” > > 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 ->

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

[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: -

Re: [DISCUSS] Pcap panel architecture

I know, I was running with it :) > On May 3, 2018, at 10:21 PM, Michael Miklavcic <michael.miklav...@gmail.com> > wrote: > > Tabs vs spaces was a Silicon Valley joke, man :-) > >> On Thu, May 3, 2018, 8:42 PM Ryan Merriman <merrim...@gmail.com> wrote:

Re: [DISCUSS] Pcap panel architecture

seems contrary to > > our previous direction. > > > > 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 re

Re: [DISCUSS] Pcap panel architecture

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 important to get community buy in on the > architectural approach. There

[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

[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

Re: [DISCUSS] Persistence store for user profile settings

ally 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't be that hard either,

[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

Re: [DISCUSS] Integration/e2e test infrastructure requirements

, Dec 13, 2017 at 4:41 PM, Ryan Merriman <merrim...@gmail.com> 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 compil

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 <ottobackwa...@gmail.com> wrote: > What is the Master Jira going to be? > > > > On December 13, 2017 at 14:36:50, Ryan Merriman (merrim...@gmail.com) > wrote:

Re: [DISCUSS] Integration/e2e test infrastructure requirements

go from there. On Mon, Dec 11, 2017 at 4:10 PM, Ryan Merriman <merrim...@gmail.com> 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

[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

Re: [DISCUSS] e2e test infrastructure

> > On November 29, 2017 at 11:53:46, Ryan Merriman (merrim...@gmail.com) > wrote: > > “I would feel better using docker if each docker container only had the > base services, and did not require a separate but parallel deployment path > to ambari” > > This exactly how

Re: [DISCUSS] e2e test infrastructure

components > were functional 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

Re: [DISCUSS] e2e test infrastructure

ponent > is separate from one another, and that they can be utilized for both the > e2e and integration tests. > >> On Nov 29, 2017 8:00 AM, "Ryan Merriman" <merrim...@gmail.com> wrote: >> >> Thanks for the feedback so far everyone. All good points. &g

Re: [DISCUSS] e2e test infrastructure

l.com> > > 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

[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

Re: [DISCUSS] Upcoming Release

lease to > be 0.4.3 or 0.5.0). > > Hope this clarifies, > --Matt > > On 11/17/17, 1:59 PM, "Ryan Merriman" <merrim...@gmail.com> wrote: > >Matt, > >I think we are currently on version 0.4.2. If that is the case would the >next version be 0.4.

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

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

Lesson learned: Never question Ryan again! > > > > 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

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

[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

Re: [DISCUSS] Metron release 0.4.1

t; > On 9/7/17, 7:39 AM, "Ryan Merriman" <merrim...@gmail.com> wrote: > >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

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

GUI are not working now. > > 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

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

Re: [DISCUSS] Persisting user data

prefer > to > > side-step those holy wars by being agnostic. > > > > On Wed, Aug 2, 2017 at 9:36 PM, Ryan Merriman <merrim...@gmail.com> > wrote: > > > >> Spring supports a variety of databases including Postgres. I have no > >> pro

Re: [DISCUSS] Persisting user data

gt; > Never mind about Ambari 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/z

Re: [DISCUSS] Persisting user data

scheme will you > use? 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" <merrim...@g

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

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

[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

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

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

Re: Trying to spin up Metron in EC2: Failed

That happens when you don't have the zookeeper url configured correctly. Can you check the contents of the /etc/sysconfig/metron file on the Metron host? On Wed, May 17, 2017 at 1:36 PM, Laurens Vets wrote: > For testing purposes, I decided to spin up the default Metron AWS

Re: mvn building errors with 0.3.1

Kevin, I think your error is related to npm. Can you attach the full log file? On Mon, May 15, 2017 at 5:23 PM, Kevin Waterson wrote: > I am getting something similar.. > > [INFO] BUILD FAILURE > [INFO] >

Re: [MASTER BROKEN] Possible Issue in METRON.SPEC in master

You are correct. I just finished fixing this to get the RPMs to build. Should be an easy fix. On Tue, May 9, 2017 at 3:51 PM, Otto Fowler wrote: > I just tried to merge in master, and got conflicts in metron.spec. Which > is not unusual since spec files are awesome. >

Re: [DISCUSS] REST + ambari

It already works the way Simon describes. On Mon, May 8, 2017 at 8:08 AM, Simon Elliston Ball < si...@simonellistonball.com> wrote: > My proposal would be that the REST api use it’s application.yml for all > the parameters and have settings it needs included in that. E.g. the metron > directory

Re: Error building in Travis after taking master

You might want to try clearing the mvn cache. I've had travis get into a bad state before because of corrupt maven artifacts. On Wed, May 3, 2017 at 10:26 AM, Otto Fowler wrote: > https://travis-ci.org/ottobackwards/incubator-metron/builds/228364894?utm_ >

Re: [GitHub] incubator-metron issue #562: METRON-915 add node and npm to platform_info.sh

We are using a mvn plugin that automatically installs the correct version of node and npm locally, at least for the management UI. Are there other parts of the project that depend on these tools? Is it desirable to include this even if they aren't a prerequisite for building? I don't

Re: [Discussion] Access to Ambari Variables

You would supply Ambari credentials when you make the Ambari (not ours) REST call. On Mon, May 1, 2017 at 3:14 PM, Otto Fowler wrote: > But we don’t have SSO, so that would required the ambari credentials be > available to the rest api > > > On May 1, 2017 at 16:10:03,

Re: [DISCUSS] Metron Rest to Install Parser (METRON-258)

I think leveraging the REST application would work for this use case. Services already exist for most of the functions listed in your pseudocode (HDFS read/write, Zookeeper read/write). Asynchronous functions are also supported so no issues there. On Thu, Apr 27, 2017 at 9:09 AM, Otto Fowler

  1   2   >