[dev][requirements][tripleo] Return of the revenge of lockfile strikes back part II
jpodivin at redhat.com
Mon Jul 11 09:59:02 UTC 2022
We could, and maybe should, ask people working on ansible to give that
issue/PR more attention.
I see the PR is untriaged for some time now...
On Mon, Jul 11, 2022 at 9:50 AM Cédric Jeanneret <cjeanner at redhat.com>
> 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...
> On 7/9/22 15:26, Jeremy Stanley wrote:
> > It became apparent in a Python community discussion 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 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 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 on python-daemon,
> > which still has a dependency on lockfile. 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.
> >  https://discuss.python.org/t/17219
> > 
> >  https://review.openstack.org/151224
> >  https://github.com/ansible/ansible-runner/issues/379
> >  https://pagure.io/python-daemon/issue/42
> Cédric Jeanneret (He/Him/His)
> Sr. Software Engineer - OpenStack Platform
> Deployment Framework TC
> Red Hat EMEA
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openstack-discuss