Is there some way in the ops framework to get the series information of a running unit?
My current approach is brutal:
# Handle jammy
if 0 == open('/etc/issue', 'r').read().find('Ubuntu 22.04'):
self._something()
1 Like
I’m not aware of any special hacks, but personally I would use lsb_release.
e.g.
from subprocess import check_output
check_output("lsb_release -a".split()).splitlines()[3].split(b":")[1].strip()
Yeah, lsb_release would be good - but not all linux distro ships that… or at least that was the case a few years ago. /etc/issue seems to be more common.
How about uname?
Not sure. Possibly. But from a Juju perspective, the “series” would be the abstraction that would be relevant since we are talking of matching this against the content of “charmcraft.yaml” - “run-on” directive. E.g. if a charm author would be building support for different series, he/she would be using that as a juju attribute to implement the needed features that would be “series” dependent.
I see your point, and I wouldn’t be against adding a wrapper for that. Maybe worth an issue on https://github.com/canonical/operator-libs-linux ?
I’m not sure it’s something for ops main since we try to remain as substrate-agnostic as possible (except for pebble).
@rwcarlsen @pengale thoughts on this?
I would argue that its strange not to provide access to such a key component such as “series” from some juju construct.
Why would series even be part of juju if its not a primitive to work with from a developer point of view.
Surely this must be possible by means native to Juju?
I don’t believe that the ops code has the context to be able to directly inspect Juju’s concept of series. If the operator framework grew the ability to detect series, that ability would look a lot like a generalized version of the code you posted above. It would just be hidden away in a nice wrapper 
This sounds like a great candidate for a charm lib – a small bit of useful and reusable code that fixes a practical problem. In the long run, I think that you’ll be able to handle things like this with an assumes directive in the metadata.
I agree. But its also causing further confusion in what relation this potential “lib” would add in relation to the old “charmhelpers”.
What should a developer have for a relation to that lib nowadays?
I have been using the charmhelpers lib sometimes, but since some time ago - it causes compile-issues with charmcraft thats not building charms with that lib included without patching the charmcraft.yaml to fix setuptools to < v58 like this: https://github.com/erik78se/charm-minecraft-server/blob/92467bac26993dc2d1f547af45663e383d740790/minecraft-server/charmcraft.yaml
This is messy to me…
Hi Erik,
The approach that we’ve been taking is to take elements of charmhelpers and convert them into standalone libraries. Most of the code in operator-libs-linux derives from charmhelpers, for example.
If the series detection code in charmhelpers is reasonably standalone, it could similarly be pulled out of charmhelpers and dropped into a lib.
1 Like
Oh, is there some index around this to allow for discovery of them or how would I work with these libs?
charmlib discovery is still a WIP. There is an index on these forums. There is a manually maintained list of libraries on this forum: Juju | Popular charm library index
I would specifically take a look at this section: https://juju.is/docs/sdk/library-index#heading--libraries-that-provide-tools-for-machine-charms
Very interesting.
However, does the “platform: Kubernetes” also imply that also libraries will be k8 vs machine charms?
I found this “Deploy Operator Libs Linux using Charmhub - The Open Operator Collection” via the machine charm link you provided, yet it leads to a Kubernetes lib…
Currently, libraries are attached to charms. The intent was to give the library context, I believe, and provide some hints as to how to use it.
The operator-libs-linux libraries are all attached to a placeholder charm, which confusingly is marked in the store as being a k8s charm.
That’s not hard to fix – someone (probably me) just needs to go in and edit the metadata.yaml of the placeholder charm.
The library you referenced will work on any system that has systemd installed. This would typically be a “machine” environment. Apologies for the confusion!
1 Like
No worries, generally this is a cool thing and I look forward to seeing some sort of indexed catalog of these libraries online down the road.