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