[GitHub] metron issue #616: METRON-877 Extract core implementation and UDF support, c...

[mattf-horton]

Github user mattf-horton commented on the issue:

https://github.com/apache/metron/pull/616
  
This has been committed to git-wip-us.apache.org/repos/asf/metron.  
Propagation seems a little slow today.



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] metron issue #620: Metron-988: UI for viewing alerts generated by Metron

[iraghumitra]

Github user iraghumitra commented on the issue:

https://github.com/apache/metron/pull/620
  
@merrimanr QueryBuilder is thought of as a model than a utils class, the 
fields with '_' are used for display purpose and are not required to be 
persisted. I will take an another pass to see if I can refactor the code to 
make it look simple.In fact, the Saved Search and Recent Search Saves the query 
builder.
I understand that SearchRequest might be a more suitable name so renaming 
QueryBuilder to SearchRequest makes sense ?. I am taking an another pass at 
abstracting all the API calls so that we can change the api provider to 'solr' 
or rest api easily form the UI. Once i do that the service classes would look 
better.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] metron issue #616: METRON-877 Extract core implementation and UDF support, c...

[ottobackwards]

Github user ottobackwards commented on the issue:

https://github.com/apache/metron/pull/616
  
super!  great work @mattf-horton 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] metron issue #616: METRON-877 Extract core implementation and UDF support, c...

[ottobackwards]

Github user ottobackwards commented on the issue:

https://github.com/apache/metron/pull/616
  
so can this be merged?



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] metron issue #338: METRON-295: Script parsing bolt

[ottobackwards]

Github user ottobackwards commented on the issue:

https://github.com/apache/metron/pull/338
  
I am not sure what the status of this pr is.  I think that we may want to 
re-think this a little in light of 
[METRON-777](https://github.com/apache/metron/pull/530)


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [DISCUSS] METRON-994 -> Rest v. Stellar ( api of record )?

[Otto Fowler]

Bump


On June 13, 2017 at 00:11:52, Otto Fowler (ottobackwa...@gmail.com) wrote:

I have opened METRON–994 
: STELLAR Shell and management should front the METRON REST api

As Stellar management functions start overlapping with the REST api, we may
want have stellar management backed by rest, and have a single main api -
rest.

Nick brings up an excellent point that we should consider doing the
opposite, back the rest api with the stellar implementation.

After a little thought, I believe that this approach may have the greatest
pay off long term, as it will result (hopefully) in an increase of the
number of STELLAR commands, that may be leveraged in different contexts.

But, I think this issue warrants more discussion from the group.

The questions as I can see them (please add more or correct me ) are:

   - Should Stellar have a api which is fronted by multiple front ends?
   - If so, which is better suited, REST, STELLAR or other?
   - What are some trade offs | pay offs with each approach?