Open Stack

Le mer. 22 sept. 2021 à 18:05, Balazs Gibizer <balazs.gibizer at est.tech> a
écrit :

>
>
> On Wed, Sep 22 2021 at 01:15:13 PM +0000, Jeremy Stanley
> <fungi at yuggoth.org> wrote:
> > On 2021-09-22 14:56:43 +0200 (+0200), Előd Illés wrote:
> > [...]
> >>  Option 3: it is really just a temporary solution (maybe worse than
> >>  Option 1), though it is probably acceptable to unblock gate on
> >>  stable branches until the appropriate solution will be chosen.
> >>  Also worth to emphasize that this problem doesn't only affect
> >>  lower-constraints tests, but also could affect branches where we
> >>  have old packages (versions) in upper-constraints.txt!
> > [...]
> >
> > Do also note that all solutions in this space are effectively
> > temporary. When we drafted the stable branch and extended
> > maintenance policies, we accepted that there comes a time for any
> > job where circumstances may prevent us from being able to
> > effectively continue running it. If the complexity of the solution
> > outweighs the *temporary* benefits of being able to run the job for
> > longer, it may not be worth the effort.
>
> As the issue affects even the recent stable branches this would
> effectively mean we lose all the lower-constraints testing. And if
> later the same thing happen with one of our upper requirements then we
> will to lose all the testing. I think we cannot simply say that we
> ignore the problem by turning off the job.
>
> >
> > While we almost certainly could come up with a non-default
> > replacement for Zuul's standard tox job which allows us to use
> > specific versions of tox, virtualenv, pip, setuptools, et cetera,
> > that added complexity does not come for free. It has a maintenance
> > cost which extends far into the future. Also think back on the times
> > when we've reached for the "easy" solution of pinning such tools in
> > other frameworks like DevStack: everyone's in a rush to stop the
> > bleeding and get back to testing, but nobody cares about fixing the
> > underlying issue and so such things end up pinned for years until
> > that pinning breaks something else because we're blind to all the
> > bitrot around us.
> >
> > And then there's the fact that while we can "fix" things this way in
> > CI jobs, these are ultimately tools for our developers which we just
> > happen to also be able to run in the CI system, not the other way
> > around. Pinning setuptools in the tox jobs does not solve this for
> > developers running tox locally on their own systems. Are we going to
> > start providing them with a list of specific versions of these tools
> > which we're only able to test with, substantially increasing the
> > complexity of setting up local dev environments and making it even
> > harder for newcomers to contribute to the project?
> >
> > The stable branch policy is a set of guidelines and suggestions, not
> > an unbreakable covenant. It's there to help us make sound choices
> > under normal circumstances, but we should not be afraid to come to a
> > collective decision about making policy exceptions in unusual
> > situations such as this one.
>
> Does it mean you suggest bumping the decorator dependency to 4.0.0?
>
> > --
> > Jeremy Stanley
>
>
>
>
I have to say fungi made great points. While option 2 has some ideal,
option 1 seems the most pragmatic and won't divert us with developing
efforts for getting there (AFAIK, we don't yet have a working solution for
option 2).

Also, I don't know for all distros but the one I know doesn't use our lower
constraints but rather redefine the dependencies by what they currently
support. So, I'm even not sure bumping our lower dep here would create an
issue for them if we tell them it's a minor release.

Operators, thoughts about it ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210922/e448e3fc/attachment.htm>