ROS Infrastructure updates from May 2023

The month of June is upon us already somehow.

The OSRF project committee for Infrastructure was first announced two months ago at the start of April.
Since then we’ve been keeping things running as well as we can, we’ve also made progress on several changes in ROS Infrastructure, which I’ll do my best to highlight and summarize here.

Infrastructure Community Meeting 2023-05-17

Our biggest news is that we hosted our first Infrastructure Community Meeting in May. @cottsay gave an excellent presentation on Standards-based Python packaging and the challenges and opportunities it presents for building with colcon and creating python packages for ROS. There is a recording of that meeting available if you weren’t able to attend. We’re planning to have our next community meeting in July.


Ongoing effort to sunset Python 2 and Python 3.5 in ROS infrastructure packages

With Bionic’s community support in the rearview mirror, the ROS infrastructure team is finally able to drop support for Python 2.7 and 3.5 from ROS Infrastructure packages. As we add support for Debian Bookworm we are ending new releases on Bionic and can now adopt both Python 3 exclusive features as well as features that were only introduced in Python 3.6 (like f-strings!).

There isn’t going to be a huge effort to pull the entire codebase forward at once; there isn’t really justification to make proactive changes here, but by removing coverage for these python versions from our CI, we’ll no longer be testing for changes that are not compatible with them.

The existing releases will remain available in the ROS repositories for Bionic, as they are for earlier distributions as well. However if you’re installing from pip on a platform that uses Python 3.5 or 2.7, it makes sense to pin the version of your ROS Infrastructure dependencies to their current releases.

This work has only just begun, it is accelerated somewhat by GitHub Actions dropping support for Ubuntu Bionic, where our coverage for these Python versions was hosted.
ros-infrastructure/ros_buildfarm#996 gets things started and I’m sure I’ll have more to highlight in the future.


New Windows Server 2022 base images on ci.ros2.org

@Crola1702 and @claraberendsen have been working on this internally for some time and work started to come together just as we were going into Iron’s release window. So we opted to wait until after the Iron release to switch and with Change windows docker image by Crola1702 · Pull Request #698 · ros2/ci · GitHub merged and new Windows Server 2022 agents deployed that work is now live! The team is tracking a few tests which have potentially become flakier since the swap but we don’t want to revert to the Windows Server 2019 images for anything less than a complete outage as this work paves the way for adding support for Visual Studio 2022 builds on ci.ros2.org.


On the subject of build farm reliability, @Crola1702 has been working on our internal terraform to add support for multiple Availability Zones within AWS to our build agent pools, which were previously limited to a single AZ to keep the networking configuration simple, but changes in the overall AWS landscape have put pressure on us to spread out more.


When making changes to jobs on ci.ros2.org, the Infrastructure team tries our best not to interrupt or interfere with running CI. To support that, most of the jobs have a secret twin “test” job that isn’t listed on either the manual or nightly tabs of ci.ros2.org which is an exact configuration duplicate of the corresponding CI job. The infrastructure team can use these to test modifications to jobs before deploying them for the rest of the team or to run other experiments. While testing the Windows Server 2022 images, we found that the test packaging jobs which exist on ci.ros2.org are not deployed as duplicates and were instead created by hand a loooooong time ago. With ros2/ci#700 testing clones of the packaging jobs are also deployed each time we update the job templates, making testing changes for packaging jobs more consistent with the rest of CI.


Pinning RHEL 9.1

In a bout of unfortunate timing, RHEL 9.2 released right before our Iron release and included several changes that affected ROS 2 dependencies from EPEL which were not yet available for 9.2. As a result, we pinned RHEL 9 builds to 9.1 in both ros_buildfarm and ros2/ci, as an added bonus, the change to ros2/ci allows us to explicitly set and test RHEL minor versions.


edit: How could I forget, we also announced the new status.openrobotics.org page. You can learn more about that in an earlier post New consolidated status page for Open Robotics Infrastructure and deprecation of status.ros.org


That’s all for now. Happy June and Happy Friday :rainbow_flag:

9 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.