[horizon][requirements] Upgrade of urllib breaks Selenium
Hello everyone, we have just recently fixed our gates in the Horizon project from the pkg_resources, but we noticed just now that they broke again, this time because urllib was upgraded in the global requirements: https://review.opendev.org/c/openstack/requirements/+/972462 Unfortunately, it seems that this version of urllib doesn't work with the version of selenium library that is forced by the global requirements. And naturally that makes all our integration tests fail. As a temporary measure we are going to use a local copy of the global constraints file with the urllib downgraded for the selenium jobs, just to unblock the gates. This is a very sensitive time for us, because we have to cut a release very soon. We will try to find a better solution for the long term. Suggestions welcome. Regards,
On Thu, Feb 26, 2026, at 8:26 AM, Radomir Dopieralski wrote:
Hello everyone,
we have just recently fixed our gates in the Horizon project from the pkg_resources, but we noticed just now that they broke again, this time because urllib was upgraded in the global requirements: https://review.opendev.org/c/openstack/requirements/+/972462
Unfortunately, it seems that this version of urllib doesn't work with the version of selenium library that is forced by the global requirements. And naturally that makes all our integration tests fail.
As a temporary measure we are going to use a local copy of the global constraints file with the urllib downgraded for the selenium jobs, just to unblock the gates. This is a very sensitive time for us, because we have to cut a release very soon. We will try to find a better solution for the long term. Suggestions welcome.
The version of selenium in the constraints file is almost 8 years old. I suspect that the proper solution here is to update to Selenium 4. This document indicates it should be straightforward to do so: https://www.selenium.dev/documentation/webdriver/troubleshooting/upgrade_to_...
Regards,
On Thu, Feb 26, 2026 at 5:32 PM Clark Boylan <cboylan@sapwetik.org> wrote:
The version of selenium in the constraints file is almost 8 years old. I suspect that the proper solution here is to update to Selenium 4. This document indicates it should be straightforward to do so: https://www.selenium.dev/documentation/webdriver/troubleshooting/upgrade_to_...
It's never straightforward when global requirements are involved, because the patch has to pass tests with both old version and new version. We will be experimenting with it and try to find a solution that works.
Are you sure that passing with both is really needed? As in case selenium is updated in constraints first - then you only need to pass on the new version? And given that it's broken now anyway - probably it's not that bad to update it right away? чт, 26 февр. 2026 г. в 17:38, Radomir Dopieralski <openstack@dopieralski.pl
:
On Thu, Feb 26, 2026 at 5:32 PM Clark Boylan <cboylan@sapwetik.org> wrote:
The version of selenium in the constraints file is almost 8 years old. I suspect that the proper solution here is to update to Selenium 4. This document indicates it should be straightforward to do so: https://www.selenium.dev/documentation/webdriver/troubleshooting/upgrade_to_...
It's never straightforward when global requirements are involved, because the patch has to pass tests with both old version and new version. We will be experimenting with it and try to find a solution that works.
On Thu, Feb 26, 2026 at 5:44 PM Dmitriy Rabotyagov <noonedeadpunk@gmail.com> wrote:
Are you sure that passing with both is really needed?
As in case selenium is updated in constraints first - then you only need to pass on the new version? And given that it's broken now anyway - probably it's not that bad to update it right away?
We had that problem with xstatic-font-awesome, and that is what we have been told. I also think this is pretty bad, but what can I do?
On Thu, Feb 26, 2026, at 8:46 AM, Radomir Dopieralski wrote:
On Thu, Feb 26, 2026 at 5:44 PM Dmitriy Rabotyagov <noonedeadpunk@gmail.com> wrote:
Are you sure that passing with both is really needed?
As in case selenium is updated in constraints first - then you only need to pass on the new version? And given that it's broken now anyway - probably it's not that bad to update it right away?
We had that problem with xstatic-font-awesome, and that is what we have been told. I also think this is pretty bad, but what can I do?
Any chance you can provide a reference to that discussion? My understanding is that only a single version of a python library is in use at any given time. The constraints file determines what that specific version is. That means right now you are forced to use selenium===3.141.0 and only that version. When you push a change to openstack/requirements to update this value to selenium===4.41.0 only that version will be used. What I suspect was previously conveyed is that when you push that change for selenium===4.41.0 the requirements CI jobs will run the Horizon unittests so they need to be compatible with 4.41.0 to merge the requirements update. Ensuring that you work with both versions is one solution and you can iteratively improve on this with a change in requirements that depends on a Horizon change that adds support for both. Another solution is to drop the testing of Horizon from requirements temporarily, bump the dep, then fix Horizon. Since things are already broken this may not be the worst solution. Yet another approach would be to disable selenium tests in Horizon so that requirements can run the rest of the tests and land the update. Then fix the selnium tests. I don't think starting from a position that this is impossible to change is very productive. Let's identify the problem we are trying to solve (selenium is too old for modern python deps and needs to be updated), then discuss the solution and obstacles for that solution in concrete terms so that we can improve the situation.
You can see the old font-awesome discussion at https://review.opendev.org/c/openstack/requirements/+/950400. I'm sure there are many possible solutions, chief among them just disabling the whole global requirements system, but it seems they are frowned upon? In any case, at this point the whole discussion is moot. We don't know if we will need any substantial changes in our tests to support new version of selenium yet, and how big those changes are going to be. I wrote the initial message to let everyone know about the situation. We will see what can be done once we test newer selenium version. On Thu, Feb 26, 2026 at 6:11 PM Clark Boylan <cboylan@sapwetik.org> wrote:
On Thu, Feb 26, 2026 at 5:44 PM Dmitriy Rabotyagov <noonedeadpunk@gmail.com> wrote:
Are you sure that passing with both is really needed?
As in case selenium is updated in constraints first - then you only need to pass on the new version? And given that it's broken now anyway -
On Thu, Feb 26, 2026, at 8:46 AM, Radomir Dopieralski wrote: probably it's not that bad to update it right away?
We had that problem with xstatic-font-awesome, and that is what we have been told. I also think this is pretty bad, but what can I do?
Any chance you can provide a reference to that discussion? My understanding is that only a single version of a python library is in use at any given time. The constraints file determines what that specific version is. That means right now you are forced to use selenium===3.141.0 and only that version. When you push a change to openstack/requirements to update this value to selenium===4.41.0 only that version will be used.
What I suspect was previously conveyed is that when you push that change for selenium===4.41.0 the requirements CI jobs will run the Horizon unittests so they need to be compatible with 4.41.0 to merge the requirements update. Ensuring that you work with both versions is one solution and you can iteratively improve on this with a change in requirements that depends on a Horizon change that adds support for both.
Another solution is to drop the testing of Horizon from requirements temporarily, bump the dep, then fix Horizon. Since things are already broken this may not be the worst solution.
Yet another approach would be to disable selenium tests in Horizon so that requirements can run the rest of the tests and land the update. Then fix the selnium tests.
I don't think starting from a position that this is impossible to change is very productive. Let's identify the problem we are trying to solve (selenium is too old for modern python deps and needs to be updated), then discuss the solution and obstacles for that solution in concrete terms so that we can improve the situation.
participants (3)
-
Clark Boylan
-
Dmitriy Rabotyagov
-
Radomir Dopieralski