Comment 7 for bug 1982712

More information about why don't use subordinate charm.

1. Charms are supposed to be devops distilled, meaning encompassing best practice operations into the charms themselves. That way, when you deploy mysql you'll get not only mysql but you'll also get a solid way on how to monitor that mysql cluster, you'll get operational semantics on alerts that are generally important and actions that allow you to simplify the operations (like backup, etc, etc)
 1.1 once you start pulling the monitoring pieces out of the charm, you start to lose the operations bits

2. As Billy mention, the charm should include the monitor logic itself.
  2.1. The mysql prometheus exporter charm is not generic, we won't relate it to another charm
  2.2 The exporter will live with the principle charm, the objective is to be able to just juju deploy mysql and then relate mysql and the prometheus charm itself

3. There may be a version management issue when exporter lives outside of the principle charm
  2.1 If we shipped the principle charm without the exporter compatibility fixed, and therefore operator could't upgrade to the newer principle or they'd lose the monitoring. Putting them together in the same project, so we can cover it with testing.

4. It may bring more complexity when we have to deal with two different things at the same time(without subordinate) - but this also happen in subordinate pattern.