Should the HDFS Service ever work outside the metron application area in hdfs? Should it be bound?
Also, should the UI ‘know’ that it needs to get grok rules from hdfs service or from grok service or should it just ask the grok service and let it take care of things? On August 17, 2017 at 12:23:42, Otto Fowler ([email protected]) wrote: Is there a way to debug the UI and the Rest Service running locally, connected to vagrant node1? On August 17, 2017 at 12:01:49, Ryan Merriman ([email protected]) wrote: Check out line 336 in https://github.com/apache/metron/blob/master/metron-interface/metron-config/src/app/sensors/sensor-parser-config/sensor-parser-config.component.ts . That's where the check is done to determine if a grok parser has been selected. I would also check the browser console for errors. On Thu, Aug 17, 2017 at 10:51 AM, Otto Fowler <[email protected]> wrote: > That is the “I have a branch where I have broken that” part comes in ;) > > Actually I’m working on making HDFS actually work, because it doesn’t from > the > rule loading perspective. We ( mmiklavcic and I ) thing everything has > been loading > from class path because the grokpath doesn’t resolve on hdfs, it is > missing the /apps/metron part. > > I have fix all of that, and made it so the parsers load grok from hdfs > correctly now, but the REST > and thus the 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 ([email protected]) wrote: > > 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 retrieved from the > classpath makes it tricky though. For example, if you are looking at a > parser that stores it's pattern in the classpath (Yaf for example) the > path > would be "/patterns/yaf". Once you go to save it you have to change the > path to a path that exists in HDFS (/apps/metron/patterns/yaf) because you > obviously can't update the pattern in the jar classpath. I regret that we > added this (I think it was me actually) because it's caused nothing but > confusion and doesn't add any value. I would be in favor of keeping > patterns exclusively in HDFS. > > Ryan > > On Thu, Aug 17, 2017 at 10:25 AM, Otto Fowler <[email protected]> > wrote: > > > Question, > > > > How does the UI decide, when you edit a parser, to show the grok pattern > > field? I have branch where I have broken that, for example if I add a > new > > configuration, I see the grok pattern field, until I actually select > GROK > > as the parser type, then it goes away. > > > > Also, just to confirm, we don’t *do* anything with the grok patterns in > the > > ui, we only enter and test them or test data against them? > > > >
