Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/946
thanks @mmiklavc
---
Github user mmiklavc commented on the issue:
https://github.com/apache/metron/pull/946
@ottobackwards - I have some open changes in a PR against this PR. Just to
confirm, the expected result of this PR should be that users can choose
1. Which client they want to instantiate
2.
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/946
@cestella " Yeah, I think that's the approach, however, there's a snag.
Storm requires us to create uber jars, so probably what we want to do is have
users actually put the xpath transport
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/946
would this have any effect on people using x-pack alternatives?
---
Github user simonellistonball commented on the issue:
https://github.com/apache/metron/pull/946
@ottobackwards in it's current state, sort of, but you're not required to
turn it on. In the desired (reflection based nifi style state) no, it should
load it and use it if present, but
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/946
wait, does this PR mean we *require* x-pack from now on?
---
Github user wardbekker commented on the issue:
https://github.com/apache/metron/pull/946
@mmiklavc yes, correct, like with ES you need to install x-pack for Kibana.
You will be prompted for username password after restart of Kibana.
---
Github user mmiklavc commented on the issue:
https://github.com/apache/metron/pull/946
@wardbekker Did you test this with Kibana by chance? I'm seeing
authentication exceptions in the Kibana UI. Looks like we need additional steps
for it to work -
Github user wardbekker commented on the issue:
https://github.com/apache/metron/pull/946
Steps to test:
- build centos vagrant dev build box
- vagrant ssh
- sudo /usr/share/elasticsearch/bin/elasticsearch-plugin install x-pack
- sudo
Github user mmiklavc commented on the issue:
https://github.com/apache/metron/pull/946
I knew what you meant :)
---
Github user cestella commented on the issue:
https://github.com/apache/metron/pull/946
ah, crap, looked at the wrong setting. That's what I meant instead of
`storm.library.path`
---
Github user mmiklavc commented on the issue:
https://github.com/apache/metron/pull/946
We could probably leverage this guy here
---
Github user cestella commented on the issue:
https://github.com/apache/metron/pull/946
@mmiklavc Yeah, I think that's the approach, however, there's a snag.
Storm requires us to create uber jars, so probably what we want to do is have
users actually put the xpath transport client on
Github user justinleet commented on the issue:
https://github.com/apache/metron/pull/946
@mmiklavc I agree, as long as the user themselves is setting it up, I
believe that would solve the license problem. At least from my understanding
of things.
---
Github user mmiklavc commented on the issue:
https://github.com/apache/metron/pull/946
@simonellistonball It looks like they are not explicitly bundling the
X-Pack client. Rather, they're expecting the user to provide the jar file
manually on the classpath and then dynamically
Github user simonellistonball commented on the issue:
https://github.com/apache/metron/pull/946
Should we consider a dual client in the same project similar to the
approach in
16 matches
Mail list logo
