Closed brentm5 closed 3 months ago
What are the steps to get a review or have a further discussion around the changes above?
Sorry @brentm5! This fell through the cracks, I've added this to our next sprint so we should be taking a look in the next 2-3 weeks.
What does this PR do?
Allows users consuming the datadog_monitor resource to select a config file name instead of just the default of conf.yaml. The default still exists but by adding this option others can call the datadog_monitor function multiple times and not override existing files.
Motivation
This allows people to use the integration multiple times and place different config files in the same integration directory. The use case would be many different cookbooks adding a single check they care about without doing messy attribute overrides. The use case would be the following, Cookbook A & Cookbook B are both maintained by different teams but can be used on the same host. In the previous way of doing this you would have to add attributes in different cookbooks which can cause weird issues around attribute inheritance / ordering. By adding this teams can more easily just create different config files that are owned by the respective cookbooks and do not step on each other.
Cookbook A:
Additional Notes
Possible Drawbacks / Trade-offs
I don't see too many Drawbacks, by default the existing behavior exists. The only drawback I can think of is this does add some complexity since there can be multiple files to manage however if you manage the with this resource then the delete function has the same logic.
Describe how to test/QA your changes
I am not entire sure what other tests should be added which is why I made this a Draft. The testing should be light, essentially create an integration (logs might be the easiest since it doesn't require an integration to run) and just validate that the new file is generated. The default case should already be tested.
Reviewer's Checklist