[GitHub] metron pull request #814: METRON-1277 Add match statement to Stellar languag...

[jjmeyer0]

Github user jjmeyer0 commented on a diff in the pull request:

https://github.com/apache/metron/pull/814#discussion_r148965731
  
--- Diff: metron-stellar/stellar-common/README.md ---
@@ -100,6 +102,28 @@ In the core language functions, we support basic 
functional programming primitiv
 * `FILTER` - Filters a list by a predicate in the form of a lambda 
expression.  For instance `FILTER([ 'foo', 'bar'], (x ) -> x == 'foo' )` 
returns `[ 'foo' ]`
 * `REDUCE` - Applies a function over a list of input.  For instance 
`REDUCE([ 1, 2, 3], (sum, x) -> sum + x, 0 )` returns `6`
 
+### Stellar Language Match Expression
+
+Stellar provides the capability to write match expressions, which are 
similar to switch statements commonly found in c like languages, but more like
+Scala's match.
--- End diff --

@ottobackwards sure. Right now, I think our match statement syntax is just 
a nicer syntax for if then else blocks. I would just state something along 
those lines. I know in the future it will be more.


---

[GitHub] metron issue #814: METRON-1277 Add match statement to Stellar language

[jjmeyer0]

Github user jjmeyer0 commented on the issue:

https://github.com/apache/metron/pull/814
  
@ottobackwards something is still going on with this. I'm seeing the 
following behavior:

```bash
[Stellar]>>> foo := 500
[Stellar]>>> match{ foo > 100 => ['oops'], foo > 200 => ['oh no'], foo >= 
500 => MAP(['ok', 'haha'], (a) -> TO_UPPER(a)), default => ['a']}
[!] Invalid parse, found [OK, HAHA]
org.apache.metron.stellar.dsl.ParseException: Invalid parse, found [OK, 
HAHA]
at 
org.apache.metron.stellar.common.StellarCompiler$Expression.apply(StellarCompiler.java:210)
at 
org.apache.metron.stellar.common.BaseStellarProcessor.parse(BaseStellarProcessor.java:152)
at 
org.apache.metron.stellar.common.shell.StellarExecutor.execute(StellarExecutor.java:292)
at 
org.apache.metron.stellar.common.shell.StellarShell.handleStellar(StellarShell.java:282)
at 
org.apache.metron.stellar.common.shell.StellarShell.execute(StellarShell.java:514)
at org.jboss.aesh.console.AeshProcess.run(AeshProcess.java:53)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
[Stellar]>>> 
```


---

Re: [DISCUSS] - Remove Kibana

[Kyle Richardson]

I take your point. If another mpack would be that resource intensive, it
doesn't make much sense to go down that road. There are plenty of other
features the community would get greater value from for the time investment.

-Kyle

On Wed, Nov 1, 2017 at 10:14 PM, Michael Miklavcic <
michael.miklav...@gmail.com> wrote:

> I think the suggestion is creative, however I am strongly opposed to 2
> mpacks. It has been a fair amount of work through upgrades to maintain the
> one we have and I think splitting them might make it even worse. I'd much
> prefer to keep the dep on Kibana as is rather than make a change that
> doesn't simplify things in the end.
>
> On Nov 1, 2017 6:25 PM, "Kyle Richardson" 
> wrote:
>
> > I'll second Otto's suggestion. I like the idea of "splitting" the ES and
> > Kibana components from the pure Metron components. I suppose that would
> > mean having two mpacks to build for a while though.
> >
> > I agree with others that, at least for now, Kibana is an integral part of
> > the Metron user experience.
> >
> > -Kyle
> >
> > On Wed, Nov 1, 2017 at 7:37 PM Michael Miklavcic <
> > michael.miklav...@gmail.com> wrote:
> >
> > > It would not be installed with/by Metron. You'd install and manage
> Kibana
> > > on your own. Some things can be done with the head plugin, but it
> > wouldn't
> > > be as pretty.
> > >
> > > From the sounds of it the community still uses and wants Kibana, so
> we'll
> > > hold off until the UI can manage more of this functionality. Thanks
> > > everyone for the input.
> > >
> > > On Nov 1, 2017 4:18 PM, "Laurens Vets"  wrote:
> > >
> > > > How would I do that without Kibana? Having a SIEM without the ability
> > to
> > > > see raw processed events (whether they are alerts or not), would be a
> > big
> > > > issue I think.
> > > >
> > > > Or would Kibana always be required, just not installed by Metron?
> > > >
> > > > On 2017-11-01 11:34, Michael Miklavcic wrote:
> > > >
> > > >> You could absolutely still do it, I'm simply saying it would not be
> > > >> managed
> > > >> by us.
> > > >>
> > > >> On Nov 1, 2017 12:20 PM, "Laurens Vets"  wrote:
> > > >>
> > > >> If there's a viable way of looking at raw processed events (not
> > > >>> necessarily alerts), then I'm all for removeing Kibana. I use
> > Discover
> > > a
> > > >>> lot to filter and look at events and create new policies from that.
> > > >>>
> > > >>> Is there currently a simple way to do this without Kibana?
> > > >>>
> > > >>> On 2017-11-01 09:13, Michael Miklavcic wrote:
> > > >>>
> > > >>> As part of the ES upgrade, I got to thinking that it makes sense to
> > >  remove
> > >  Kibana and the dashboards we're currently bundling in the MPack.
> To
> > be
> > >  clear, this would not remove the ability to independently install
> > and
> > >  use
> > >  Kibana if the user so chooses, it would only remove the
> dashboards,
> > > and
> > >  potentially, the Ambari/MPack management support that we ship.
> > > 
> > >  *pros*
> > >  Removes need to support tooling outside our wheelhouse
> > >  Smaller testing effort for ongoing support and future upgrades
> > >  Simplifies our base Metron install via Ambari. Also simplifies
> full
> > > dev
> > >  setup.
> > > 
> > >  *cons*
> > >  User would need to install and setup their own Kibana instance and
> > >  dashboards.
> > >  If any existing users are using this, they'd need to backup and
> > manage
> > >  their own Kibana dashboards going forward. They would also need to
> > >  handle
> > >  any upgrade issues with Kibana post-Metron ES 5.x upgrade.
> > > 
> > >  Any concerns?
> > > 
> > >  Mike
> > > 
> > > >>>
> > >
> >
>