- service-announce - lists.opendev.org

Gerrit Outage for Project Renames Monday April 22, 2024 at 20:00 UTC
by Clark Boylan 17 Apr '24

17 Apr '24

The OpenDev team is planning a scheduled Gerrit service outage on review.opendev.org in order to rename projects. This outage will occur on Monday April 22, 2024 at 20:00 UTC until 21:00 UTC. If you have a project you would like to rename please get in touch with the OpenDev team soon (you can respond to this email or find us in #opendev on the OFTC IRC network). Please reach out if you have any questions or concerns. The same methods described above work for that too. Clark

1 0

CVE-2024-31497 and SSH key statistics
by Jeremy Stanley 16 Apr '24

16 Apr '24

For those of you who haven't seen, CVE-2024-31497 in the PuTTY tool was announced in the past day. If you're using a NIST P521 ECDSA key and have ever used it with affected versions of PuTTY, you should remove its access everywhere and consider it potentially disclosed. Details here: https://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/vuln-p521-bias.… The key type is generally listed as the first field in the corresponding public key file, or in each line of an authorized_keys entry, including those you may have set for your account in our Gerrit server (review.opendev.org). If the type is listed as ecdsa-sha2-nistp521 or sk-ecdsa-sha2-nistp521(a)openssh.com then it's been put at risk if ever used with PuTTY versions 0.68 through 0.80. On a related note, since I wanted to see how popular that key type is among our Gerrit users, I ran some quick statistics. Of the 36976 accounts created there to date, 19888 of them have SSH keys authorized. There are 35057 total authorized keys, which means accounts with SSH keys average 1.76 keys per account. Out of those keys, 44 claim to be NIST P521 type (0.13%) used by 41 different accounts (0.20% of accounts with keys, 0.11% of all accounts). Here's a breakdown of the most popular types for keys authorized in our Gerrit: 95% ssh-rsa 3.2% ssh-ed25519 1.4% ssh-dss 0.38% ecdsa-sha2-nistp256 0.25% ssh-dsa 0.13% ecdsa-sha2-nistp521 0.023% ecdsa-sha2-nistp384 So as you can see, the key type potentially impacted by CVE-2024-31497 isn't all that popular in our circles, but it's definitely nonzero. -- Jeremy Stanley, OpenDev SysAdmin

1 0

git-review 2.4.0
by Jeremy Stanley 19 Mar '24

19 Mar '24

It's my pleasure to announce the release of git-review 2.4.0. These are the corresponding release notes since the previous release: New Features ------------ * By default, git rebase --abort is run automatically following a failed test rebase, letting the user rebase again on their own if that's the state they want to be in. A -K/--keep-rebase option is added to get the old behavior. * For convenience, --wip is now synonymous with the longer --work-in-progress option. * If HEAD already exists on a remote branch, git review will now only warn and prompt for confirmation when pushing, in order to let the Gerrit server decide whether to accept or reject it. * A copy of the Gerrit upstream project's commit-msg hook is now included directly and written to disk by default rather than pulling a remote copy. This approach is safer and more robust, but may break workflows for sites which rely on users retrieving a customized commit-msg hook. For this reason, a command-line override is provided so that users can, for example, execute git review -s --remote-hook to get the old behavior when setting up a new clone. * The GIT_SSH environment variable will now be consulted, if set, in order to determine which ssh executable to call outside of git invocations, for consistency. * A new --hashtags option allows specifying a list of one or more Gerrit hashtag strings, separated by commas. Note that spaces are not allowed either within a hashtag or between separators. * New --message option can be used to include a custom patchset message when pushing. As always, the latest version of git-review is available from PyPI: https://pypi.org/project/git-review Current documentation can be found here: https://docs.opendev.org/opendev/git-review Its source code can be obtained from the OpenDev Collaboratory: https://opendev.org/opendev/git-review Please don't hesitate to follow up through the service-discuss(a)lists.opendev.org mailing list or in the #opendev channel on the OFTC IRC network if you have any questions. -- Jeremy Stanley

1 0

Removal of Ansible 6 support from OpenDev's Zuul Service
by Clark Boylan 14 Feb '24

14 Feb '24

The Zuul project will be removing Ansible 6 support in preparation for the upcoming Zuul 10.0.0 release. The exact timing of this change isn't known yet, but it may happen as early as this week. OpenDev has automated Zuul upgrades that should pull this change into our Zuul deployment not long after upstream merges the change. We have defaulted to Ansible 8 for many months now, and we don't expect this to create many issues. If you do see issues you will need to update to Ansible 8. Zuul will also be adding support for Ansible 9 in preparation for the upcoming Zuul 10.0.0 release. Once these changes are deployed in OpenDev you may want to start testing your jobs with Ansible 9 to ensure there are no problems with that update. At some point further in the future we will be changing the default Ansible version for OpenDev's Zuul to Ansible 9. Let us know if you have any questions or concerns, Clark

1 0

Upgrading mailing lists on 2023-11-02
by Jeremy Stanley 31 Oct '23

31 Oct '23

On Thursday, November 2, 2023 beginning at 15:30 UTC the OpenDev Collaboratory is upgrading the version of Mailman used to host the Airship, Kata, OpenDev, OpenInfra, OpenStack, StarlingX and Zuul mailing list sites from 3.3.8 to 3.3.9 along with related updates to its various component services (django-mailman3 1.3.9->1.3.11, hyperkitty 1.3.7->1.3.8, postorius 1.3.8->1.3.10, mailman-web 0.0.6->0.0.8). There will be brief downtime for the web interface while services are restarted, and some message deliveries may be briefly delayed but will still eventually be processed. One of the updates includes a database migration that implicitly clears the auth sessions table, so users who were logged into the web interface will be effectively logged out and need to log in again before performing authenticated operations. Web interfaces may have a slightly different look and feel after the update, and some new options too. Changelogs can be found here for anyone interested in seeing a list of what's new: https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/NEWS.… https://gitlab.com/mailman/django-mailman3/-/blob/v1.3.11/README.rst https://gitlab.com/mailman/hyperkitty/-/blob/v1.3.8/doc/news.rst https://gitlab.com/mailman/postorius/-/blob/v1.3.10/src/postorius/doc/news.… https://gitlab.com/mailman/mailman-web/-/blob/0.0.8/README.rst -- Jeremy Stanley

1 0

Upgrading review.opendev.org to Gerrit 3.8 on November 17, 2023
by Clark Boylan 30 Oct '23

30 Oct '23

On November 17, 2023 beginning at 15:30 UTC the OpenDev team will upgrade Gerrit at https://review.opendev.org from Gerrit 3.7 to 3.8. This upgrade shouldn't take more than an hour. We have managed to to keep our Gerrit installation about one major release behind upstream's release cadence, and Gerrit 3.9's impending release means it is time for us to upgrade to 3.8. There are a number of new features, bug fixes, and performance improvements in the new version. The Gerrit project publishes detailed release information [0] which you can review if you are interested in what sorts of changes to expect. If you are interested in the upgrade process you can follow that in our planning document [1]. It is worth noting that if all goes well we expect the total Gerrit downtime to be much shorter than an hour (should only take a few minutes). If we need to revert to Gerrit 3.7, we will need to do offline reindexing of our changes which takes about half an hour. We are using an hour long upgrade window to ensure we have time for downgrades should that become necessary. [0] https://www.gerritcodereview.com/3.8.html [1] https://etherpad.opendev.org/p/gerrit-upgrade-3.8 Clark

1 0

Zuul regex deprecation [action required]
by James E. Blair 21 Sep '23

21 Sep '23

Hi, Zuul is making a change that may require action from developers on projects hosted in OpenDev. Here is the release note regarding the change: > Regular expressions using Python syntax are deprecated in favor of RE2 > syntax instead, for additional speed and safety. Negative lookahead > assertions may be replaced using the negate keyword. See Regular > Expressions[1] for more information. > > If Zuul detects a regular expression using Python syntax that is not > supported by RE2, it will register a configuration syntax > warning. These may be viewed on the configuration errors page in the > web interface. > > A future version of Zuul will remove Python regex support completely > and these warnings will become errors. [1] https://zuul-ci.org/docs/zuul/latest/project-config.html#regex It's easy to see if your project on OpenDev is affected. Each tenant has a page where the current configuration errors and warnings are displayed. Visit any page in Zuul for your tenant, and if there is a bell icon in the top right, click on that. For example, the configuration error page for the OpenStack tenant is here: https://zuul.opendev.org/t/openstack/config-errors On that page, look for the "Regex Deprecation" warnings. You can expand the warning to see exactly the file and line number where the warning is found. Almost all of the issues identified so far have been due to the fact that RE2 does not support negative lookahead assertions. In the past, we used these a lot to say things like "run this job on any branch except master" with regexes like "(?!master)". Because this is such a common pattern, we added a feature in Zuul to make this easy. A configuration like: branches: "^(?!master).*$" can now be written as: branches: regex: "^master$" negate: true This simply negates the specified regex. It's not an exact translation of the original regex, but is slightly improved and to the point: anything but exactly "master". Please take a moment and check to see if your project has instances of this warning, and go ahead and fix it. Even if there are a lot of instances, they are likely to be very similar and correcting them may take only a few minutes. Here are two changes where we update the central configuration that applies to all projects: https://review.opendev.org/c/openstack/project-config/+/893702 https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/893792 These provide examples of how to make changes for several common cases; you may be able to simply copy what was done in those changes. If you have any trouble adapting existing regexes to the new format, please contact us in #opendev to discuss the issue. We may be able to find a simple solution, or if there is another special case that is difficult to handle, we may be able to add support to Zuul to mitigate the issue. If you use "update-regexes" as a topic name, it will help people keep track of progress and possible issues. The Zuul project has not yet set a date for when support for the old syntax will be removed. I expect it to be on the order of months, which should give folks plenty of time to make the necessary changes. But please do so early so that we have time to deal with any issues. Thanks, Jim (on behalf of the OpenDev team)

1 0

Removing OpenDev's Fedora Test Images on September 11, 2023
by Clark Boylan 06 Sep '23

06 Sep '23

OpenDev has been unable to update Fedora images in a timely manner leaving us with Fedora 35 and 36 images in our CI system. Fedora 35 and 36 are long past their EOL date, and we have been planning to remove them [0]. Somewhat recently the Fedora project stopped mirroring packages for these releases which resulted in empty mirrors on our end [1]. The end result is that Fedora nodes haven't been very functional within OpenDev since. We have slowly been cleaning up usage of Fedora nodes and recently removed the fedora-latest nodeset from Zuul [2]. The next step is to remove these images from Nodepool entirely. We will do so on Monday September 11, 2023. Chances are any Fedora jobs are already broken, but this is a good reminder to look into correcting any of those jobs by moving them to another platform. [0] https://lists.opendev.org/archives/list/service-discuss@lists.opendev.org/t… [1] http://mirror.dfw.rax.opendev.org/fedora/releases/36/ [2] https://review.opendev.org/c/opendev/base-jobs/+/892380 Clark

1 0

Updating OpenDev Zuul's default Ansible version to Ansible 8
by Clark Boylan 23 Aug '23

23 Aug '23

Currently OpenDev Zuul's default Ansible version is Ansible 6. Zuul has recently added support for Ansible 8, and is dogfooding Ansible 8 in the Zuul tenant for the Zuul project. Yesterday, the OpenDev team updated the Zuul tenant for the OpenDev project to default to Ansible 8 as well. So far we have seen no problems with jobs run in these two tenants related to the Ansible version change. We would like to update the default Ansible version for all of the Zuul tenants in OpenDev's Zuul installation to Ansible 8 in the near future. The reason for this is Zuul will update the default Ansible version to Ansible 8 in Zuul itself. Not long after that change, support for Ansible 6 in Zuul will be removed. Changing things in OpenDev first allows us to do these changes in a controlled manner and get ahead of any potential problems. Assuming the Zuul and OpenDev tenants continue to run without trouble our plan is to switch the nebulous, pyca, pypa, and vexxhost tenants to Ansible 8 by default on August 28, 2023. Then if things continue to run without trouble, we will complete this change by updating the openstack tenant on September 4, 2023. I had initially thought that we would do a more conservative rollout, but initial data indicates this change may be straightforward so we'd prefer a quicker move. Note that if there are major issues we can revert the setting in our Ansible config for any of these tenants and return to a default to Ansible 6 while the issues get addressed. Issues will need to be addressed as Ansible 6 is EOL and Zuul intends to drop support for this version of Ansible. If you would like to test your jobs before the tenant configuration updates go into effect you can do so by setting `ansible-version: '8'` in the configuration of a job [0], push the resulting change to Gerrit, and then wait for Zuul to run the job and provide you with results. It is not necessary to merge the change; Zuul will speculatively test this setting. If you discover any problems through this process please let us know. [0] https://zuul-ci.org/docs/zuul/latest/config/job.html#attr-job.ansible-versi… Clark

1 0

opendevorg docker hub images moving to quay.io
by Clark Boylan 24 May '23

24 May '23

The OpenDev team has decided to move hosting for its container images from docker hub to quay.io. Over the weekend we landed changes to update the publication location for our python base images (opendevorg/python-builder, opendevorg/python-base, opendevorg/uwsgi-base). We will continue to move additional images as quickly as possible. While we publish these images primarily for our own consumption, they are entirely open source and others may be using them as well. If you are using these images, you should update the image source locations to quay.io/opendevorg/$imagename. Once we have updated publishing for our last image, we will begin a 30 day countdown, after which we will clean up images on docker hub to remove any confusion over which images are maintained and up to date. We will send notice for a more specific time frame once it is known. Let us know if you have an questions. Clark

1 1