Current implementation is well-structured, and because of this, it wouldn't be hard to refactor it to follow the patterns we are starting to use in DP across all charms, with a division into core, managers, and handlers. The Spark history server charm is an example of such a pattern, which is also described a bit more in the spec DA067.
When using this pattern, you can also inherit some functions already implemented, such as the k8s_utls module. This module can be translated into a manager, for which we already have some implementations; see here. The idea of this effort is indeed to start coming up with a common pattern such that the general bits of the code can be moved into a centralized repository and be more effectively maintained, also providing a common pattern to all charms such that people can quickly onboard (without for instance requiring to re-understand the structure of the code, as I had to do now)
Reporter: @deusebio
Current implementation is well-structured, and because of this, it wouldn't be hard to refactor it to follow the patterns we are starting to use in DP across all charms, with a division into core, managers, and handlers. The Spark history server charm is an example of such a pattern, which is also described a bit more in the spec DA067.
When using this pattern, you can also inherit some functions already implemented, such as the
k8s_utlsmodule. This module can be translated into a manager, for which we already have some implementations; see here. The idea of this effort is indeed to start coming up with a common pattern such that the general bits of the code can be moved into a centralized repository and be more effectively maintained, also providing a common pattern to all charms such that people can quickly onboard (without for instance requiring to re-understand the structure of the code, as I had to do now)Reporter: @deusebio