I agree with everything Kyle said and I think some of Nick's assumptions are false. I don't see this a third deployment option.
I can understand people not wanting to maintain another deployment path with Metron already being as big as it is. Ensuring that you've tested and updated all the appropriate components is already tedious. But in the case of this module, is it something that needs to updated anytime someone makes a deployment related change? I don't think so and I've never had that expectation. The build won't fail and nothing from this project is ever deployed or shipped. For me, maintaining this tool as needed is good enough. What happens if a change is introduced that breaks something? I discover it as I'm using the tool, fix it, contribute it back and move on. No big deal. I had been maintaining this privately for a while before the PR was submitted and the work to keep it current with master was pretty minimal. Does that mean it should live somewhere else besides the master branch in Metron? I'm not sure what the answer is but there should be a way to share and collaborate with the community on tools like this that aren't necessarily deployed to production. Kyle's contribution is valuable and something I would definitely use. Ryan
