Hello there, Tripleo can't really drop the dependency on ansible-runner, since it's the official and supported way to run ansible from within python. We could of course replace it by subprocess.Popen and the whole family, but we'll lose all the facilities, especially the ones involved in the Ansible Execution Environment, which is kind of the "future" for running ansible (for the better and the worst). Since ansible-runner has an open issue for that (you even linked it), and at least one open pull-request to correct this issue, I'm not really sure we're needing to do anything but follow that open issue and ensure we get the right version of the package once they merge any of the proposal to remove it. Would that be OK? Though, of course, it won't allow to set a deadline on a specific date... Cheers, C. On 7/9/22 15:26, Jeremy Stanley wrote:
It became apparent in a Python community discussion[0] yesterday that lockfile has been designated as a "critical project" by PyPI, even though it was effectively abandoned in 2010. Because our release automation account is listed as one of its maintainers, I looked into whether we still need it for anything...
For those who have been around here a while, you may recall that the OpenStack project temporarily assumed maintenance[1] of lockfile in late 2014 and uploaded a few new releases for it, as a stop-gap until we could replace our uses with oslo.concurrency. That work was completed[2] early in the Liberty development cycle.
Unfortunately for us, that's not the end of the story. I looked yesterday expecting to see that we've not needed lockfile for 7 years, and was disappointed to discover it's still in our constraints list. Why? After much wailing and gnashing of teeth and manually installing multiple bisections of the requirements list, I narrowed it down to one dependency: ansible-runner.
Apparently, ansible-runner currently depends[3] on python-daemon, which still has a dependency on lockfile[4]. Our uses of ansible-runner seem to be pretty much limited to TripleO repositories (hence tagging them in the subject), so it's possible they could find an alternative to it and solve this dilemma. Optionally, we could try to help the ansible-runner or python-daemon maintainers with new implementations of the problem dependencies as a way out.
Whatever path we take, we're long overdue. The reasons we moved off lockfile ages ago are still there, and the risk to us has only continued to increase in the meantime. I'm open to suggestions, but we really ought to make sure we have it out of our constraints list by the Zed release.
[0] https://discuss.python.org/t/17219 [1] https://lists.openstack.org/pipermail/openstack-dev/2014-June/038387.html [2] https://review.openstack.org/151224 [3] https://github.com/ansible/ansible-runner/issues/379 [4] https://pagure.io/python-daemon/issue/42
-- Cédric Jeanneret (He/Him/His) Sr. Software Engineer - OpenStack Platform Deployment Framework TC Red Hat EMEA https://www.redhat.com/