[ci][all] Migrating doc job back to ubuntu jammy
Hi, I noticed that doc job in taskflow repo was broken recently. Example: https://review.opendev.org/c/openstack/taskflow/+/944495?tab=change-view-tab... Digging into the failure, it seems the failure is caused by api doc build, trying to parse a module importing asyncore, because asyncore is no longer available in Python 3.12. IIUC Doc job was recently migrated from Ubuntu Jammy to Ubuntu Noble, which means that the default python version was bumped to 3.12. We are aware of the deprecation/removal of asyncore and already deprecated the implementation in taskflow. However deprecation was merged during 2024.2 cycle so we can't remove it until 2025.2 cycle to follow SLURP policy. There might be a way to drop the asyncore-related implementations from docs to unblock the doc job, I'm not sure if that is the right approach given the fact the implementation is deprecated but is still valid in older python versions. Thus, I wonder if we can keep running doc job in Jammy for 2025.1, which still supports Ubuntu Jammy, and then migrate the job again during 2025.2 . An alternative approach is to remove the asyncore implementation during this cycle, breaking SLURP policy, but I'm not sure if this can be the preferred option. Thank you, Takashi -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit
As a short-term (and possibly long-term) fix, I proposed https://review.opendev.org/c/openstack/taskflow/+/944586 which removes the module dependent on asyncore from api doc. On 3/15/25 10:36 AM, Takashi Kajinami wrote:
Hi,
I noticed that doc job in taskflow repo was broken recently.
Example: https://review.opendev.org/c/openstack/taskflow/+/944495?tab=change-view-tab...
Digging into the failure, it seems the failure is caused by api doc build, trying to parse a module importing asyncore, because asyncore is no longer available in Python 3.12. IIUC Doc job was recently migrated from Ubuntu Jammy to Ubuntu Noble, which means that the default python version was bumped to 3.12.
We are aware of the deprecation/removal of asyncore and already deprecated the implementation in taskflow. However deprecation was merged during 2024.2 cycle so we can't remove it until 2025.2 cycle to follow SLURP policy.
There might be a way to drop the asyncore-related implementations from docs to unblock the doc job, I'm not sure if that is the right approach given the fact the implementation is deprecated but is still valid in older python versions.
Thus, I wonder if we can keep running doc job in Jammy for 2025.1, which still supports Ubuntu Jammy, and then migrate the job again during 2025.2 .
An alternative approach is to remove the asyncore implementation during this cycle, breaking SLURP policy, but I'm not sure if this can be the preferred option.
Thank you, Takashi
---- On Fri, 14 Mar 2025 18:36:24 -0700 Takashi Kajinami <kajinamit@oss.nttdata.com> wrote ---
Hi,
I noticed that doc job in taskflow repo was broken recently.
Example: https://review.opendev.org/c/openstack/taskflow/+/944495?tab=change-view-tab...
Digging into the failure, it seems the failure is caused by api doc build, trying to parse a module importing asyncore, because asyncore is no longer available in Python 3.12. IIUC Doc job was recently migrated from Ubuntu Jammy to Ubuntu Noble, which means that the default python version was bumped to 3.12.
Yes, we migrated the doc job also to Noble on Friday, below email: - https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.... I tested many projects (not all) and fixed a few before migration. For example, pcre.h package error (bug/2088359, see cinder fix as an example). If there are other errors, they should be quick to fix; otherwise, you can keep that project doc job running on Jammy until they are ready. Example- https://review.opendev.org/c/openstack/taskflow/+/944601
We are aware of the deprecation/removal of asyncore and already deprecated the implementation in taskflow. However deprecation was merged during 2024.2 cycle so we can't remove it until 2025.2 cycle to follow SLURP policy.
There might be a way to drop the asyncore-related implementations from docs to unblock the doc job, I'm not sure if that is the right approach given the fact the implementation is deprecated but is still valid in older python versions.
Thus, I wonder if we can keep running doc job in Jammy for 2025.1, which still supports Ubuntu Jammy, and then migrate the job again during 2025.2 .
An alternative approach is to remove the asyncore implementation during this cycle, breaking SLURP policy, but I'm not sure if this can be the preferred option.
We do not need to do either, and another workaround is to keep running the taskflow doc job on Jammy until it is ready. I proposed that, and it continues to work as it was before migration - https://review.opendev.org/c/openstack/taskflow/+/944601 -gmann
Thank you, Takashi
-- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit
Thanks. I didn't attempt project-specific override because the local override may complicate maintenance of that stable branch (2025.1 may have a few doc jobs in jammy and the others in noble), and was wondering about the global switch but we can try the local override and if look for another option if something goes wrong. I've proposed removal of process executor in master, which we can hopefully merge in 2025.2, so that we can switch the taskflow's doc job back to Noble during next cycle. On 3/16/25 9:53 AM, Ghanshyam Mann wrote:
---- On Fri, 14 Mar 2025 18:36:24 -0700 Takashi Kajinami <kajinamit@oss.nttdata.com> wrote ---
Hi,
I noticed that doc job in taskflow repo was broken recently.
Example: https://review.opendev.org/c/openstack/taskflow/+/944495?tab=change-view-tab...
Digging into the failure, it seems the failure is caused by api doc build, trying to parse a module importing asyncore, because asyncore is no longer available in Python 3.12. IIUC Doc job was recently migrated from Ubuntu Jammy to Ubuntu Noble, which means that the default python version was bumped to 3.12.
Yes, we migrated the doc job also to Noble on Friday, below email: - https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack....
I tested many projects (not all) and fixed a few before migration. For example, pcre.h package error (bug/2088359, see cinder fix as an example). If there are other errors, they should be quick to fix; otherwise, you can keep that project doc job running on Jammy until they are ready.
Example- https://review.opendev.org/c/openstack/taskflow/+/944601
We are aware of the deprecation/removal of asyncore and already deprecated the implementation in taskflow. However deprecation was merged during 2024.2 cycle so we can't remove it until 2025.2 cycle to follow SLURP policy.
There might be a way to drop the asyncore-related implementations from docs to unblock the doc job, I'm not sure if that is the right approach given the fact the implementation is deprecated but is still valid in older python versions.
Thus, I wonder if we can keep running doc job in Jammy for 2025.1, which still supports Ubuntu Jammy, and then migrate the job again during 2025.2 .
An alternative approach is to remove the asyncore implementation during this cycle, breaking SLURP policy, but I'm not sure if this can be the preferred option.
We do not need to do either, and another workaround is to keep running the taskflow doc job on Jammy until it is ready. I proposed that, and it continues to work as it was before migration
- https://review.opendev.org/c/openstack/taskflow/+/944601
-gmann
Thank you, Takashi
-- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit
---- On Sat, 15 Mar 2025 19:29:01 -0700 Takashi Kajinami <kajinamit@oss.nttdata.com> wrote ---
Thanks. I didn't attempt project-specific override because the local override may complicate maintenance of that stable branch (2025.1 may have a few doc jobs in jammy and the others in noble), and was wondering about the global switch but we can try the local override and if look for another option if something goes wrong.
I've proposed removal of process executor in master, which we can hopefully merge in 2025.2, so that we can switch the taskflow's doc job back to Noble during next cycle.
++, sounds good, thanks. -gmann
On 3/16/25 9:53 AM, Ghanshyam Mann wrote:
---- On Fri, 14 Mar 2025 18:36:24 -0700 Takashi Kajinami <kajinamit@oss.nttdata.com> wrote ---
Hi,
I noticed that doc job in taskflow repo was broken recently.
Example: https://review.opendev.org/c/openstack/taskflow/+/944495?tab=change-view-tab...
Digging into the failure, it seems the failure is caused by api doc build, trying to parse a module importing asyncore, because asyncore is no longer available in Python 3.12. IIUC Doc job was recently migrated from Ubuntu Jammy to Ubuntu Noble, which means that the default python version was bumped to 3.12.
Yes, we migrated the doc job also to Noble on Friday, below email: - https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack....
I tested many projects (not all) and fixed a few before migration. For example, pcre.h package error (bug/2088359, see cinder fix as an example). If there are other errors, they should be quick to fix; otherwise, you can keep that project doc job running on Jammy until they are ready.
Example- https://review.opendev.org/c/openstack/taskflow/+/944601
We are aware of the deprecation/removal of asyncore and already deprecated the implementation in taskflow. However deprecation was merged during 2024.2 cycle so we can't remove it until 2025.2 cycle to follow SLURP policy.
There might be a way to drop the asyncore-related implementations from docs to unblock the doc job, I'm not sure if that is the right approach given the fact the implementation is deprecated but is still valid in older python versions.
Thus, I wonder if we can keep running doc job in Jammy for 2025.1, which still supports Ubuntu Jammy, and then migrate the job again during 2025.2 .
An alternative approach is to remove the asyncore implementation during this cycle, breaking SLURP policy, but I'm not sure if this can be the preferred option.
We do not need to do either, and another workaround is to keep running the taskflow doc job on Jammy until it is ready. I proposed that, and it continues to work as it was before migration
- https://review.opendev.org/c/openstack/taskflow/+/944601
-gmann
Thank you, Takashi
-- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit
participants (2)
-
Ghanshyam Mann
-
Takashi Kajinami