Go error when pushing app to CF.
Closed this issue · 5 comments
Using this fork, #1 I get the following error during staging phase when pushing the app to CF.
-----> Running: godep go install -tags cloudfoundry ./...
go build github.com/cloudfoundry-incubator/datadog-firehose-nozzle/integration_test: no buildable Go source files in /tmp/staged/app/.heroku/go/src/github.com/cloudfoundry-incubator/datadog-firehose-nozzle/integration_test
When removing the integration_test folder I can successfully push the app.
We have created an issue in Pivotal Tracker to manage this. You can view the current status of your issue at: https://www.pivotaltracker.com/story/show/102246856.
Quoting @erikjasiak from the pivotal tracker story:
The problem with making the nozzle an app in full-sized CF is that an outage to a part of CF might also wipe out your ability to monitor the problem in the first place. This is acceptable for lattice given its scale.
What is the use-case for an app-deployed Nozzle? I think that's what would need to be evaluated, relative to the risk of a blind-outage.
@simonjohansson could you answer Erik's question?
Since the firehose supports round robin consumers and I have different discrete CF installations I simply run multiple consumers in different cf installations with same subscription ID to mitigate that risk.
Main reason why I don't want to run this on a dedicated VM (deployed by bosh or not) is simply that the less VMs in our env the better, also cf push > bosh deploy in many cases :)
Hi @simonjohansson ,
Unfortunately, I keep coming back to all the reasons we don't want to support nozzles as apps by default. While cf push may be more convenient than a bosh deploy at times, having an out-of-the-box option to app deploy a nozzle today means a greater risk of something going Horribly Wrong with a DEA/Diego, and leaving the user to fly blind.
As you've noticed, it certainly wouldn't be hard for someone to manipulate the codebase to make a nozzle deploy as an app, but I'd rather someone have to take that specific action to know they'd gone outside "standard configuration (ymmv)", instead of fielding "why can't I see why Diego crashed?" questions that will have unpleasant answers for all involved.
I will link to this convo in some of our upcoming notes for those that do want to give this a try, and if there's an ongoing community need we can revisit.
Apologies, but thanks for the PR and thank you for being an otherwise happy firehose user - the syslog nozzle is still awesome!
Erik
@erikjasiak ok, fair enough. :)