make compatible with the riak newrelic rpm

[deanxorr]

@tannerburson @StabbyCutyou

current chore-new_relic is not compatible with any projects using the riak monitoring in the Tapjoy fork of the newrelic_rpm gem.

Why does this matter?

In Yosemite, zookeeper does not seem to install cleanly. To avoid the zookeeper issue (and still run all the services locally that have hard dependencies on one another, namely device_identity_service, virtual_currency_service, and tapjoyserver) I had to upgrade chore on DiS and VCS, since they were never upgraded when we split out the chore-core business.

So I did it myself, and I just want to make sure no one's going to flip out if we loosen the dependency a bit. Is there truly a hard requirement for newrelic_rpm 3.7.x?

[StabbyCutyou]

So, unless i'm missing something, TJS is on 3.7, and is not referencing our fork of new relic any more... I don't remember why we stopped using it.

Ill ping Pfeify

[deanxorr]

hey @StabbyCutyou @obrie any update on this?

For your trouble:

[obrie]

TJS is using 3.7.3.205 which is our fork of the RPM gem. Also note, as per https://github.com/Tapjoy/chore_internal/pull/138, that the latest version of chore is only compatible (as far as I recall and as far as the PR indicates) with RPM 3.7.0+. The reason we have the fork is to prevent deadlocks. So... I believe that the latest version of chore is only compatible with RPM 3.7.3.205. If we can demonstrate compatibility with our 3.6 fork (the tj-3.6.7.159 branch in our fork), then I'm okay with this PR -- however, it will require some version-specific core in this repo.

[StabbyCutyou]

It is my opinion that we should not spend time trying to ensure backward compatibility with the older new relic gem, and instead upgrade the single project which is causing the dependency issue to be in line with TJS. Then we can drop this PR altogether and reduce the overall complexity of Deans needed changes.