Github user justinleet commented on the issue:
https://github.com/apache/metron/pull/1275
Thoughts on the outstanding items
**Installing Metron in Knox**
- re: "The approach in this PR only works if Metron is installed on the
same machine as the Knox gateway." I know of Hadoop installs using multiple
Knox instances with a load balancer in front of them. I would expect this to be
a reasonable expectation for people with sufficiently large Metron installs (or
many tenants or whatever). I expect that to influence the decision here.
- re: topology file. Can you give a bit more detail on the pros/cons? Is
there any standard that other implementors are using or recommendations in the
docs?
**Adding Knox to the stack**
- As noted above, multiple Knox instances with load balancer is a potential
configuration users will want. In that case, colocation is not a given.
- I don't think Knox as a required service is a given. I wish Ambari let
you have optional services and gate things more directly. We might be able to
mimic that functionality by hiding the relevant configs unless Knox is enabled.
It might still require the user to hit a toggle, but it might be possible to
check against a Knox service config directly for that. I've never tried it
(and it might be nice to do in general for some of our other configs, e.g. Solr
and ES).
** Ambari Automation **
- I'm inclined to consider Ambari necessary for effort as a whole to be
really done. I'd prefer it to be done now just to have it done and coherent,
but I'm fine with it being a follow-on PR (given the usual assumptions that
everything continues to work as expected and is documented, otherwise I'd be
inclined to use feature branch). It means docs are throwaway once that goes in,
but I'm personally fine with it being manually documented then automated later.
** Quick Links**
- As mentioned above, I think we're out of luck here.
---
