We have an internal gem that includes all our custom checks, and we install that gem using sensu-install. The conflicts come between the different checks we’ve written. For example, I might write a check that uses https://github.com/aws/aws-sdk-ruby in order to access the CloudTrail api. Then, a year or two later, I want to write a check that needs to access DynamoDB, but the methods I want to use aren’t available in the old version of the aws gem that we’re already using; to write this new check then I need to update the version of aws-sdk, but that breaks compatibility with the CloudTrail check and so I have to go update it. Often this gets even worse because updating the top-level gem (in this example, aws-sdk) requires updating some transitive dependency that’s also used by another gem in another check, and so the updates cascade and multiply and I find myself needing to update a dozen checks just to add one new one.
But none of these checks actually interact with each other, and so it should be perfectly fine for the CloudTrail check to use one version of aws-sdk and the DynamoDB check to use another; the problem comes in actually creating this isolation.
We have a few dozen custom checks right now, and I see it expanding dramatically the next few years, which is why I’m worried about this problem.