Re: [DISCUSS] Metron REST API Architecture and Design

Sorry, this got buried in my inbox a bit. So the first thing that came to mind was using the API for loading and exporting alerts/events with other enterprise systems, but there appear to be other benefits as well. This assumes that Metron is still intended to be the central location of all

Re: [DISCUSS] Metron REST API Architecture and Design

Hey Jon sorry for the delay. These are new to me so I'm not sure where to start. Is there a common use case we could explore initially? Ryan On Thu, Oct 27, 2016 at 9:02 AM, zeo...@gmail.com wrote: > Another thought that came to me recently - Has there been any

Re: [DISCUSS] Metron REST API Architecture and Design

Another thought that came to me recently - Has there been any consideration of using some of the newer standards such as pxGrid , DXL , etc. to integrate with other systems and allow data

Re: [DISCUSS] Metron REST API Architecture and Design

I think this is a reasonable direction for Metron. It probably makes sense to make sure that your services can accept identity propagation from Knox so that they can also be proxied along with Hadoop APIs. FWIW - discussing whether a JAXRS programming model is something wanted by the community

Re: [DISCUSS] Metron REST API Architecture and Design

There is also this comment in that Jira: "Adding the JAXRS services to knox is really easy but we haven't really discussed whether it should be a programming model aspect of Knox in the community" I think that would need to be worked out before we move services into Knox, if we decide we should

Re: [DISCUSS] Metron REST API Architecture and Design

I spent some time researching the Knox documentation and building custom services (hosted in Knox) was not well-documented. Spring is a great choice for that and I didn't really get any other feedback on which application development framework to use. So that's what I went with. I think we

Re: [DISCUSS] Metron REST API Architecture and Design

So it looks like, for now, you are not pursuing Knox (per comments in METRON-503 and then PR 316). Is there a reason for that? Jon On Fri, Oct 14, 2016 at 5:59 PM zeo...@gmail.com wrote: > Good question :) > > On Fri, Oct 14, 2016, 17:07 Ryan Merriman

Re: [DISCUSS] Metron REST API Architecture and Design

Jon, It wasn't intentional, I ran out of time and wanted to get something out there. I think it certainly could be open ended though. Where should the REST API project be located? Ryan On Thu, Oct 13, 2016 at 7:32 PM, zeo...@gmail.com wrote: > Along the lines of: > • Must

Re: [DISCUSS] Metron REST API Architecture and Design

Along the lines of: • Must be deployed to a machine with adequate resources so that resource contention is avoided. • Will need network access to all other services within Metron Has there been any consideration of a "Metron Manager" node? In the old TP2 bare metal install guide

[DISCUSS] Metron REST API Architecture and Design

I created a Jira to track this new feature at https://issues.apache.org/jira/browse/METRON-503. I also started and attached an architecture doc to that Jira with some of my ideas about how we should implement it. Please feel free to review and comment or add to it. Looking forward to everyone's