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
>