I’m aware that Python 3 support is worked on, but what’s the status, specifically regarding the agent? It gets more and more difficult to keep Python 2 running.
For example:
The agent’s preinst-Script (.deb package) requires /usr/bin/python to exist. It also requires it to be Python 2. Otherwise installation fails.
Ubuntu 20.04 doesn’t come with Python 2 installed anymore. Yes, one can install the python package, but that installation is rather incomplete.
CheckMK’s Docker check requires the Python-Docker module. This one isn’t available on Ubuntu 20.04. Additionally pip for Python 2 isn’t available on Ubuntu 20.04 either (only for Python 3), making installation rather cumbersome, especially for larger numbers of servers.
Getting CheckMK’s Docker check to run with Python 3 is possible (see this topic), but then I have to provide my own bakery for it if I’m not mistaken.
I’m finding myself having to apply more and more duct-tape & bandages.
I don’t care so much about running the web interface with Python 2 as CheckMK comes with its own Python version (in fact we’re running all CheckMK sites on Ubuntu 20.04 just fine), but the agent becoming a real problem.
Is this a self-baked .deb-package? For the plain agent package from /opt/omd/versions/1.6.0p13.cre/share/check_mk/agents/check-mk-agent_1.6.0p13-1_all.deb, I can find no such dependency (neither for the package itself nor in its scripts)
It is, yes. It seems that bakery scripts can trigger the inclusion of such checks, which makes sense if the scripts deployed by the bakery is a Python-2-only script.
The Docker Python module is also available for Python 3. It is only available from 3.5 to 3.7.
mk_docker.py is working on one of my test systems under Win10 with python 3.7.7 and Docker with WSL2 backend.
I checked this with the mk_docker.py from dev version. The 1.6 version will not be changed until 1.7 if it not a bugfix i think.
In the development branch, we have already completed the Python 3 migration (to 3.8). We are now cleaning up some remnants of the transition in a few places.
Regarding agent plugins, we will develop our plugins in Python 3 and provide Python 2 backports for compatibility with old systems. We will generate these automatically from the Python 3 code.
In the bakery you will have the possibility to configure which Python version is available on which system via a rule chain. Accordingly, the agent packages are packed together correctly.
The Windows-Agent will deliver its own Python 3.8 starting with 1.7, so that we don’t need the frozen-binaries (logwatch, agent updater) anymore. Other plugins, such as mk_postgres, will therefore easily work across platforms. Also own plugins can be developed with this Python 3.8.
So far we have no plan to ship our own Python under Linux / Unix. In the sense of uniformity this would be great, but it would not be easy to maintain.
Thank you very much. That’s exactly the type of information I was looking for. Your plans sound good to me, especially being able to designate which Python version to use via rules.