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

Re: [DISCUSS] Pcap panel architecture

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 anything problematic in metron-api, just that is was > inconsistent with the rest of Metron. There is work involved in making it >

Re: [DISCUSS] Pcap panel architecture

Mike, I never said there was anything problematic in metron-api, just that is was inconsistent with the rest of Metron. There is work involved in making it consistent which is why I listed it as a downside. I'm less concerned with whether we use tabs or spaces but that we use one or the other.

Re: [DISCUSS] Pcap panel architecture

Yes, completely agreed. We're on the same page. On Thu, May 3, 2018 at 7:50 PM, Otto Fowler wrote: > I think my point is that maybe we should have a discuss about: > > * PCAP UI, goals etc > * Where it would live and why, what that would mean etc > * Backend ( this

Re: [DISCUSS] Pcap panel architecture

I think my point is that maybe we should have a discuss about: * PCAP UI, goals etc * Where it would live and why, what that would mean etc * Backend ( this original mail ) On May 3, 2018 at 18:34:00, Michael Miklavcic (michael.miklav...@gmail.com) wrote: Otto, what are you and your customers

Re: [DISCUSS] Pcap panel architecture

Otto, what are you and your customers finding useful and/or difficult from a split management/alerts UI perspective? It might help us to restate the original scope and intent around maintaining separate management and alert UI's, to your point about "contrary to previous direction." I personally

Re: [DISCUSS] Pcap panel architecture

Comments inline below. On Thu, May 3, 2018 at 3:25 PM, Ryan Merriman wrote: > Otto, > > I'm assuming just adding it to the Alerts UI is less work but I wouldn't be > strongly opposed to it being it's own UI. What are the reasons for doing > that? > > I don't know that we

Re: [DISCUSS] Pcap panel architecture

If that UI becomes the Alerts _and_ the PCAP Query UI, then it isn’t the alerts ui anymore. It is becoming more of a “composite” app, with multiple feature ui’s together. I didn’t think that was what we were going for, thus the config ui and the alert ui. Just adding disparate thing as ‘new

Re: [DISCUSS] Pcap panel architecture

Otto, I'm assuming just adding it to the Alerts UI is less work but I wouldn't be strongly opposed to it being it's own UI. What are the reasons for doing that? Mike, On using metron-api: 1. I'm making an assumption about it not being used much. Maybe it still works without issue. I

Re: [DISCUSS] Pcap panel architecture

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

Re: [DISCUSS] Pcap panel architecture

Thanks for the write-up, Ryan. A few questions and comments. 1. metron-api 1. "It hasn't been used in a while and will need some end to end testing to make sure it still functions properly" > I was probably one of the last developers to touch this code a year or more ago -

[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