search

cloudfoundry-attic / datadog-firehose-nozzle

OBSOLETE CF component to forward metrics from the Loggregator Firehose to DataDog
Apache License 2.0
9 stars 29 forks source link

Go error when pushing app to CF. #2

Closed simonjohansson closed 9 years ago

simonjohansson commented 9 years ago

Using this fork, https://github.com/cloudfoundry-incubator/datadog-firehose-nozzle/pull/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.

cf-gitbot commented 9 years ago

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.

roxtar commented 9 years ago

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?

simonjohansson commented 9 years ago

@erikjasiak

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 :)

erikjasiak commented 9 years ago

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

simonjohansson commented 9 years ago

@erikjasiak ok, fair enough. :)