Metricbeat mysql: Add config.epr.yml

[mtojek]

This PR adds the config.epr.yml file to the Metricbeat mysql module.

I plan to use this file as source of configuration option for the import-beats script in https://github.com/elastic/package-registry project.

[mtojek]

If this file is required and cannot be change, WDYT about an additional one config.epr.yml that will be used only for importing purposes?

[exekias]

this normally means that the metricset is disabled by default, do we really need to change this?

[mtojek]

I used this way (enabling metricset) to ensure that the configuration option is used with the metricset.
In this case, if I enable "galera_status", the script will include all configuration options related to it.

[exekias]

About reference config: it's only use is compiling the metricbeat.reference.yml, which holds a reference file of all default config values for the user. There is nothing really interacting with it.

I'm +1 on a config.epr.yml file if needed, perhaps it can have a more focused purpose and describe only what you need. I understand this is metricsets and config keys, similar to filebeat's manifest.yml in filesets

[mtojek]

About reference config: it's only use is compiling the metricbeat.reference.yml, which holds a reference file of all default config values for the user. There is nothing really interacting with it.

I'm +1 on a config.epr.yml file if needed, perhaps it can have a more focused purpose and describe only what you need. I understand this is metricsets and config keys, similar to filebeat's manifest.yml in filesets

This will work for me too. I can adjust the PR.

[ruflin]

I like the idea of having some assets in Beats that will simplify the migration. But the part I wonder is if this case we should perhaps directly jump to the end format, meaning having the manifest file instead with parts of the info?

[mtojek]

I like the idea of having some assets in Beats that will simplify the migration. But the part I wonder is if this case we should perhaps directly jump to the end format, meaning having the manifest file instead with parts of the info?

@ruflin Having an entire manifest.yml in every dataset in beats might require lot of manual work. I'm not sure if this is a way we'd like to follow (I'm not declining this approach).

[ruflin]

@mtojek Agree, and that manual work should probably directly happening when we review the packages. Just having a specific epr config file sounds also like a lot of additional work.

[exekias]

Let's get this in for the shake of moving MySQL integration forward. If we finally go for this approach we will need to document it after the first batch of integrations are in

[mtojek]

@mtojek Agree, and that manual work should probably directly happening when we review the packages. Just having a specific epr config file sounds also like a lot of additional work.

Hmm, content of the config.epr.yml can be copied from a config.reference.yml, but the manifest needs to be rewritten.
Let's try to go with config.epr.yml. In the worst case, we'll rollback these files and apply a different option.