Allow creating more than one config file per integration

[albertvaka]

What does this PR do?

Allows specifying the name of the config file to be created by datadog_agent::integration, so different config files with different instances can be defined from different places in the code. For example, in the following manifest we define two config files for the postgres integration:

  datadog_agent::integration { 'postgres_dbA':
    integration => 'postgres',
    conf_file => 'dbA',
    instances => [{
      host     => 'localhost',
      dbname   => 'dbA',
      username => 'dbAuser',
      password => 'dbApass',
    }],
  }

  datadog_agent::integration { 'postgres_dbB':
    integration => 'postgres',
    conf_file => 'dbB',
    instances => [{
      host     => 'localhost',
      dbname   => 'dbB',
      username => 'dbBuser',
      password => 'dbBpass',
    }],
  }

which results in a config file being created for each:

$ cat /etc/datadog-agent/conf.d/postgres.d/dbA.yaml 
---
init_config: 
instances:
- host: localhost
  dbname: dbA
  username: dbAuser
  password: dbApass
$ cat /etc/datadog-agent/conf.d/postgres.d/dbB.yaml 
---
init_config: 
instances:
- host: localhost
  dbname: dbB
  username: dbBuser
  password: dbBpass

Motivation

Fixes #147

[cdloh]

Thanks for the fast PR!

The only issue I see with this is that you lose the logic and defaults from the main class and template. Keeping with the theme of postgres the main postgres class ensures that your custom metrics are acceptable otherwise fails.

This is probably an acceptable loss? The other option would be to make each integration a resource and call those specifically instead of the integration resource itself, however that's a much larger change.

[albertvaka]

Yes, with this approach we don't check anything, which has cons (eg: typos might go unnoticed) but also pros (eg: it's more flexible for advanced use cases like yours; when there's a new integration or a new config field, this works right away, otherwise the puppet module needs to be updated).

Unfortunately it's a compromise we have to make one way or another, and I prefer leaving the postgres class as it is so it covers the more basic use case, and implement this in the generic integration.

[cdloh]

Makes sense!