Github user merrimanr commented on the issue:
https://github.com/apache/metron/pull/1275
Thanks for the feedback @justinleet.
- Colocating: You bring up a good point about multiple Knox instances. The
primary challenge here is that enabling Metron on Knox requires copying files
to local directories on each Knox Gateway. If Knox exposed this through a REST
API or could read files from HDFS this would not be an issue but I'm not aware
that either of those options are supported. This is not an issue with other
services (HDFS, HBase, etc) because those services have been added to the Knox
project and are installed along with Knox. We could go that route but there
are some major drawbacks (see the "Knox SSO feature branch review and features"
discussion thread). It's not clear to me how we solve this in an automated
way. Is this (copying Metron files to Knox Gateway hosts) possible with Ambari?
- Custom topology vs Knox default: There are several advantages to
maintaining our own topology file:
- We have complete control over how we expose settings in Ambari. The
Knox default topology is exposed in Ambari as raw xml.
- We have control over the url value where the Knox default url is
`/gateway/default/<service name>`. There may be a way to change this but I
don't know how.
- The topology file will be smaller and easier to understand because it
only contains Metron services.
The main disadvantage I see is related to the issue described above: we
need a way to copy this
file to Knox Gateway hosts and update it.
- Ambari automation: I do believe everything still works as before in this
PR. I think some decisions we make here will influence that work so a follow
on seems appropriate to me.
- Quick Links: I agree, looks like we're out of luck here. I think we'll
either need to make Knox the default and make the Metron quick links match or
live with quick links being updated manually.
---
