But, since the code for the interface isn’t available yet apart from integrated in the k8 charm, it feels like I quickly can get into a situation that the charms would divert too much.
What do you mean by that? The interface code is in a charm lib, so you should be able to import it and share it without fear of divergence.
Or do you mean the actual ‘workload’ config management code?
If that is what you mean, maybe a more productive way to go forward is for you to contribute a feature to the charm to make it work on both k8s and machine. I’ve heard of someone doing that using a subclassing mechanism.
For example you could have
class CharmLokiK8s(LokiCharmBase) and
class CharmLokiLXD(LokiCharmBase), and a
__main__ routine which decides which one to instantiate based on the substrate.
I don’t think that the Framework has any abstraction yet in place for that, but allowing for multi-substrate charms was on the agenda in several meetings at some point
Best to ask @jnsgruk and @benhoyt re the state of the art in that respect.
The o11y team also has several ‘machine’ stories in the roadmap, better to involve @0x12b in the conversation as well.