Open Stack

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>
wrote:

> 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20220711/d05974bd/attachment.htm>