[oslo][release][requirements] broken watch_log_file depends on unmaintained pyinotify
Hello, # This is mainly a oslo topic but I'm adding release team and requirements # team because we likely need new stable/2024.1 release of oslo.log. I looked into an old oslo.log bug[1] during the weekend and noticed that the watch_log_file option in oslo.log has been broken for some time. Looking into the problem further, I leaned that pyinotify[1] library, which is used in this feature, hasn't been updated for 9 years (!!). What is worse, pyinotify dependes on asynccore which has been removed from Python 3.12 and I'm skeptical that we can fix pyinotify to make it work with Python 3.12. There was an old discussion to replace pyinotify by inorify[3] but itnofiy hasn't been updated for 4 years and looks also unmaintained. I think the only option we have here is deprecating the functionality in 2024.1 so that we can remove it in early phase of 2024.2. Because we are quite close to 2024.1 GA, we have to make the decision early. I've already proposed the change for deprecation[4]. If you have any concerns then please reply to this email or leave your comments in the review. Thank you, Takashi [1] https://bugs.launchpad.net/oslo.log/+bug/1740111 [2] https://github.com/seb-m/pyinotify [3] https://github.com/dsoprea/PyInotify [4] https://review.opendev.org/c/openstack/oslo.log/+/914788 -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit
IMO deprecating this feature make sense. Le dim. 31 mars 2024 à 07:22, Takashi Kajinami <kajinamit@oss.nttdata.com> a écrit :
Hello,
# This is mainly a oslo topic but I'm adding release team and requirements # team because we likely need new stable/2024.1 release of oslo.log.
I looked into an old oslo.log bug[1] during the weekend and noticed that the watch_log_file option in oslo.log has been broken for some time.
Looking into the problem further, I leaned that pyinotify[1] library, which is used in this feature, hasn't been updated for 9 years (!!). What is worse, pyinotify dependes on asynccore which has been removed from Python 3.12 and I'm skeptical that we can fix pyinotify to make it work with Python 3.12.
There was an old discussion to replace pyinotify by inorify[3] but itnofiy hasn't been updated for 4 years and looks also unmaintained.
I think the only option we have here is deprecating the functionality in 2024.1 so that we can remove it in early phase of 2024.2.
Because we are quite close to 2024.1 GA, we have to make the decision early. I've already proposed the change for deprecation[4]. If you have any concerns then please reply to this email or leave your comments in the review.
Thank you, Takashi
[1] https://bugs.launchpad.net/oslo.log/+bug/1740111 [2] https://github.com/seb-m/pyinotify [3] https://github.com/dsoprea/PyInotify [4] https://review.opendev.org/c/openstack/oslo.log/+/914788
-- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit
-- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/
+1 just removing it makes sense, I think it’s good that we keep pushing to remove dead/unmaintained code and dependencies. Thanks Takashi! Best regards Tobias
On 31 Mar 2024, at 07:19, Takashi Kajinami <kajinamit@oss.nttdata.com> wrote:
Hello,
# This is mainly a oslo topic but I'm adding release team and requirements # team because we likely need new stable/2024.1 release of oslo.log.
I looked into an old oslo.log bug[1] during the weekend and noticed that the watch_log_file option in oslo.log has been broken for some time.
Looking into the problem further, I leaned that pyinotify[1] library, which is used in this feature, hasn't been updated for 9 years (!!). What is worse, pyinotify dependes on asynccore which has been removed from Python 3.12 and I'm skeptical that we can fix pyinotify to make it work with Python 3.12.
There was an old discussion to replace pyinotify by inorify[3] but itnofiy hasn't been updated for 4 years and looks also unmaintained.
I think the only option we have here is deprecating the functionality in 2024.1 so that we can remove it in early phase of 2024.2.
Because we are quite close to 2024.1 GA, we have to make the decision early. I've already proposed the change for deprecation[4]. If you have any concerns then please reply to this email or leave your comments in the review.
Thank you, Takashi
[1] https://bugs.launchpad.net/oslo.log/+bug/1740111 [2] https://github.com/seb-m/pyinotify [3] https://github.com/dsoprea/PyInotify [4] https://review.opendev.org/c/openstack/oslo.log/+/914788
-- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit
Hello, The deprecation patch https://review.opendev.org/c/openstack/oslo.log/+/914788 was merged so the feature will be officially deprecated in stable/2024.2 . If we follow the normal deprecation/removal process, we are supported to keep the feature until 2025.1 release, but given the situation we may have to find out a way to drop the implementation early mainly. We may have several options here, and I'll dump some of these I have in my mind now. 1. Remove the option and implementation after 2025.1 This follows the standard process in SLURP. This requires no additional work now, but may prevents us from adding Python 3.12 support in 2024.2 or 2025.1. 2. Backport the deprecation to stable/2024.1, and remove the feature entirely in stable/2024.1 This follows how hyperv driver was deprecated and then removed in nova after 2023.1 release. Although backporting deprecation is not allowed in general, if we can make a release with deprecation early enough then we can ease the confusion hopefully. https://review.opendev.org/c/openstack/oslo.log/+/914880 3. Keep the option until 2025.1 but mock the feature in 2024.2 The normal deprecation process prohibits feature removal without deprecation process, but given the fact that the feature has been broken for some time, mocking the feature may not make the situation worse and could be justified. https://review.opendev.org/c/openstack/oslo.log/+/915068 I initially thought of 2, but am now inclined to 3 after discussion with Herve and Elod. However I'd like to ask for preference of others or any better alternative proposals, because the proposals may anyway exceptional ones (except for 1 which may cause problems in near-future cycles). On 3/31/24 14:19, Takashi Kajinami wrote:
Hello,
# This is mainly a oslo topic but I'm adding release team and requirements # team because we likely need new stable/2024.1 release of oslo.log.
I looked into an old oslo.log bug[1] during the weekend and noticed that the watch_log_file option in oslo.log has been broken for some time.
Looking into the problem further, I leaned that pyinotify[1] library, which is used in this feature, hasn't been updated for 9 years (!!). What is worse, pyinotify dependes on asynccore which has been removed from Python 3.12 and I'm skeptical that we can fix pyinotify to make it work with Python 3.12.
There was an old discussion to replace pyinotify by inorify[3] but itnofiy hasn't been updated for 4 years and looks also unmaintained.
I think the only option we have here is deprecating the functionality in 2024.1 so that we can remove it in early phase of 2024.2.
Because we are quite close to 2024.1 GA, we have to make the decision early. I've already proposed the change for deprecation[4]. If you have any concerns then please reply to this email or leave your comments in the review.
Thank you, Takashi
[1] https://bugs.launchpad.net/oslo.log/+bug/1740111 [2] https://github.com/seb-m/pyinotify [3] https://github.com/dsoprea/PyInotify [4] https://review.opendev.org/c/openstack/oslo.log/+/914788
Text "3" to 12345 to vote for mock. Le jeu. 4 avr. 2024 à 16:48, Takashi Kajinami <kajinamit@oss.nttdata.com> a écrit :
Hello,
The deprecation patch https://review.opendev.org/c/openstack/oslo.log/+/914788 was merged so the feature will be officially deprecated in stable/2024.2 .
If we follow the normal deprecation/removal process, we are supported to keep the feature until 2025.1 release, but given the situation we may have to find out a way to drop the implementation early mainly.
We may have several options here, and I'll dump some of these I have in my mind now.
1. Remove the option and implementation after 2025.1 This follows the standard process in SLURP. This requires no additional work now, but may prevents us from adding Python 3.12 support in 2024.2 or 2025.1.
2. Backport the deprecation to stable/2024.1, and remove the feature entirely in stable/2024.1 This follows how hyperv driver was deprecated and then removed in nova after 2023.1 release. Although backporting deprecation is not allowed in general, if we can make a release with deprecation early enough then we can ease the confusion hopefully.
https://review.opendev.org/c/openstack/oslo.log/+/914880
3. Keep the option until 2025.1 but mock the feature in 2024.2 The normal deprecation process prohibits feature removal without deprecation process, but given the fact that the feature has been broken for some time, mocking the feature may not make the situation worse and could be justified.
https://review.opendev.org/c/openstack/oslo.log/+/915068
I initially thought of 2, but am now inclined to 3 after discussion with Herve and Elod. However I'd like to ask for preference of others or any better alternative proposals, because the proposals may anyway exceptional ones (except for 1 which may cause problems in near-future cycles).
On 3/31/24 14:19, Takashi Kajinami wrote:
Hello,
# This is mainly a oslo topic but I'm adding release team and requirements # team because we likely need new stable/2024.1 release of oslo.log.
I looked into an old oslo.log bug[1] during the weekend and noticed that the watch_log_file option in oslo.log has been broken for some time.
Looking into the problem further, I leaned that pyinotify[1] library, which is used in this feature, hasn't been updated for 9 years (!!). What is worse, pyinotify dependes on asynccore which has been removed from Python 3.12 and I'm skeptical that we can fix pyinotify to make it work with Python 3.12.
There was an old discussion to replace pyinotify by inorify[3] but itnofiy hasn't been updated for 4 years and looks also unmaintained.
I think the only option we have here is deprecating the functionality in 2024.1 so that we can remove it in early phase of 2024.2.
Because we are quite close to 2024.1 GA, we have to make the decision early. I've already proposed the change for deprecation[4]. If you have any concerns then please reply to this email or leave your comments in the review.
Thank you, Takashi
[1] https://bugs.launchpad.net/oslo.log/+bug/1740111 [2] https://github.com/seb-m/pyinotify [3] https://github.com/dsoprea/PyInotify [4] https://review.opendev.org/c/openstack/oslo.log/+/914788
-- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/
I had local conversation with Herve and Elod and we agreed that option 3 (keep the option but remove the feature) is the best approach. Because we haven't heard any different preference in the list, I think we can now merge https://review.opendev.org/c/openstack/oslo.log/+/915068 based on that strategy. On 4/5/24 21:06, Herve Beraud wrote:
Text "3" to 12345 to vote for mock.
Le jeu. 4 avr. 2024 à 16:48, Takashi Kajinami <kajinamit@oss.nttdata.com <mailto:kajinamit@oss.nttdata.com>> a écrit :
Hello,
The deprecation patch https://review.opendev.org/c/openstack/oslo.log/+/914788 <https://review.opendev.org/c/openstack/oslo.log/+/914788> was merged so the feature will be officially deprecated in stable/2024.2 .
If we follow the normal deprecation/removal process, we are supported to keep the feature until 2025.1 release, but given the situation we may have to find out a way to drop the implementation early mainly.
We may have several options here, and I'll dump some of these I have in my mind now.
1. Remove the option and implementation after 2025.1 This follows the standard process in SLURP. This requires no additional work now, but may prevents us from adding Python 3.12 support in 2024.2 or 2025.1.
2. Backport the deprecation to stable/2024.1, and remove the feature entirely in stable/2024.1 This follows how hyperv driver was deprecated and then removed in nova after 2023.1 release. Although backporting deprecation is not allowed in general, if we can make a release with deprecation early enough then we can ease the confusion hopefully.
https://review.opendev.org/c/openstack/oslo.log/+/914880 <https://review.opendev.org/c/openstack/oslo.log/+/914880>
3. Keep the option until 2025.1 but mock the feature in 2024.2 The normal deprecation process prohibits feature removal without deprecation process, but given the fact that the feature has been broken for some time, mocking the feature may not make the situation worse and could be justified.
https://review.opendev.org/c/openstack/oslo.log/+/915068 <https://review.opendev.org/c/openstack/oslo.log/+/915068>
I initially thought of 2, but am now inclined to 3 after discussion with Herve and Elod. However I'd like to ask for preference of others or any better alternative proposals, because the proposals may anyway exceptional ones (except for 1 which may cause problems in near-future cycles).
On 3/31/24 14:19, Takashi Kajinami wrote: > Hello, > > > # This is mainly a oslo topic but I'm adding release team and requirements > # team because we likely need new stable/2024.1 release of oslo.log. > > I looked into an old oslo.log bug[1] during the weekend and noticed that > the watch_log_file option in oslo.log has been broken for some time. > > Looking into the problem further, I leaned that pyinotify[1] library, which > is used in this feature, hasn't been updated for 9 years (!!). What is worse, > pyinotify dependes on asynccore which has been removed from Python 3.12 and > I'm skeptical that we can fix pyinotify to make it work with Python 3.12. > > There was an old discussion to replace pyinotify by inorify[3] but itnofiy > hasn't been updated for 4 years and looks also unmaintained. > > I think the only option we have here is deprecating the functionality in > 2024.1 so that we can remove it in early phase of 2024.2. > > Because we are quite close to 2024.1 GA, we have to make the decision early. > I've already proposed the change for deprecation[4]. If you have any concerns > then please reply to this email or leave your comments in the review. > > Thank you, > Takashi > > [1] https://bugs.launchpad.net/oslo.log/+bug/1740111 <https://bugs.launchpad.net/oslo.log/+bug/1740111> > [2] https://github.com/seb-m/pyinotify <https://github.com/seb-m/pyinotify> > [3] https://github.com/dsoprea/PyInotify <https://github.com/dsoprea/PyInotify> > [4] https://review.opendev.org/c/openstack/oslo.log/+/914788 <https://review.opendev.org/c/openstack/oslo.log/+/914788> >
-- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ <https://github.com/4383/>
participants (3)
-
Herve Beraud
-
Takashi Kajinami
-
Tobias Urdin