The Kubeflow team does integration with cos for all their charms. As this implementation needs to be tested, the integration with grafana-agent-k8s is sufficient, and these tests are the same for all charms, so it makes sense to implement it in one place.
This was already implemented it into their helper called chisme #98, however after first round of implementation we realized that this can cause an issue with dependencies, since libjuju package is need and chisme is used as reusable code base for many charms. Like this, the libjuju will be part of charms, which brings a lot of unnecessary package to charm + the build process will require some additional packages to build binaries (see my comment here).
For these reason, we think, that this abstraction would be more suitable for a package used only for testing. Of course, the first choice is to go with pytest-operator, since it is standard for any operator charm.
This issue is reported for the purpose of discussion and common decision on how to test the integration with cos, which everyone will eventually do. Perhaps we could create another plugin called pytest-cos that takes advantage of the pytest-operator.
I will push the draft PR with the abstraction to see how it can be used, I will check the integration tests.
The Kubeflow team does integration with cos for all their charms. As this implementation needs to be tested, the integration with grafana-agent-k8s is sufficient, and these tests are the same for all charms, so it makes sense to implement it in one place.
This was already implemented it into their helper called chisme #98, however after first round of implementation we realized that this can cause an issue with dependencies, since libjuju package is need and chisme is used as reusable code base for many charms. Like this, the libjuju will be part of charms, which brings a lot of unnecessary package to charm + the build process will require some additional packages to build binaries (see my comment here).
For these reason, we think, that this abstraction would be more suitable for a package used only for testing. Of course, the first choice is to go with
pytest-operator, since it is standard for any operator charm.This issue is reported for the purpose of discussion and common decision on how to test the integration with cos, which everyone will eventually do. Perhaps we could create another plugin called
pytest-costhat takes advantage of thepytest-operator.I will push the draft PR with the abstraction to see how it can be used, I will check the integration tests.