You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the logic to control the service is base on the BaseExporter class, which controls the life-cycle of the service. And we control this exporter class life-cycle in the main charm class.
This means every exporter service need to handle their install/config-change/remove hooks.
With this change, every time we need to add a new exporter to this charm, we only need to create another exporter service class and register them to the main charm class. Don't have to change the skeleton of main charm class.
The exporter service class should handle it's own resource download/attach. The situation right now is the attach resource logic belong to the main charm class. From my point of view, those hardware resource should always belong to one specific exporter, e.g., the storcli belong to hardware-exporter and smartctl exporter binary belong to smartctl-exporter.
The text was updated successfully, but these errors were encountered:
jneo8
changed the title
[Refactor] Make exporter service be become juju Object base.
[Refactor] Make exporter service become juju Object base.
Jun 28, 2024
- Restructure StrategyABC to have consistence interface
- Remove HWToolHelper and move the logic into service layer
- Change the `install` function return on BaseExporter for blocked
message required
- New ResourceMixin embedded into BaseExporter
partial fix: canonical#272
Currently the logic to control the service is base on the
BaseExporter
class, which controls the life-cycle of the service. And we control this exporter class life-cycle in the main charm class.The refactor idea is that we re-create the exporter service class inherit from operator framework's Object class
sudo refactor code
The text was updated successfully, but these errors were encountered: