Add SnapExporter class and DCGM

[gabrielcocenza]

• Added the SnapExporter class that can be used for handle snap packages
• Added the DCGMExporter that installs the DCGM exporter if detected NVIDIA GPUs
• BaseExporter is a simple abstract class that has the required methods for an exporter
• RendarableExporter is the legacy BaseExporter that contains the logic for exporters that are not snaped
• DCGMExporterStrategy is not used on HWToolHelper. Avoid injecting the charm config and this class will eventually be removed

[aieri]

Although this smells a bit like COU class hierarchies, I generally like it. Hardware observer's code feels to me really hard to follow and overly complex, probably due to the complexities of supporting those binary resources and unpackaged exporters. Going forward we will only have snapped exporters though, so we should be able to remove a ton of complexity. After all, a snap doesn't need much to be handled, probably just installing, configuring (via snap set, not config files), starting/stopping the services (without needing systemd templates), and some way to check the services are alive. From this perspective perhaps the dcgm (and smartctl) snaps can provide a much needed reset.

I have added more specific comments directly in the body of the PR.

[jneo8]

Nice work, most of the change are LGTM.

I still want to keep to strategy design, yes just a wrapper, at this point until we finish the #272 .

[gabrielcocenza]

I still want to keep to strategy design, yes just a wrapper

@jneo8 I don't see a strong reason why to add strategy snap exporters. They are working fine this way and if add the strategy, we would need to inject the config to HWToolHelper to instantiate a strategy. Than we would need to map the install from the strategy to the install from the exporter and so on...

[jneo8]

@jneo8 I don't see a strong reason why to add strategy snap exporters. They are working fine this way and if add the strategy, we would need to inject the config to HWToolHelper to instantiate a strategy. Than we would need to map the install from the strategy to the install from the exporter and so on...

Please check the source code how SmartExporter use the strategy. You don't have to use HWToolHelper, you can register strategy on the service class directly and use it. The design idea is to separate the responsibilities that the package install/remove logic should be define in the strategy class and service class only handle the service life-cycle.

[aieri]

Thanks, this is looking good but I have a few comments

[gabrielcocenza]

Still need to manually test to see if it's behaving as expected, but I've included the strategy that @jneo8 asked and another round of review is needed.

I don't fully agree that this is the right approach, but let's discuss that on a major refactor in another PR.

[jneo8]

Thanks, after address those comments, it's LGTM.