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/