Because we haven't seen any update about these projects and haven't heard any objections to deprecating these features in ML, we merged the change[1] to deprecate support for monasca, sahara and senlin resources in heat. As I announced earlier we aim to remove the implementation in 2024.2 release, unless these projects are restored and join back the global release cycle. [1] https://review.opendev.org/c/openstack/heat/+/906251 On 1/25/24 04:21, Ghanshyam Mann wrote:
---- On Mon, 22 Jan 2024 21:55:30 -0800 Takashi Kajinami wrote ---
On 1/23/24 04:03, Ghanshyam Mann wrote: ---- On Sun, 21 Jan 2024 23:05:20 -0800 Rabi Mishra wrote --- > On Mon, Jan 22, 2024 at 11:21 AM Takashi Kajinami > kajinamit@oss.nttdata.com> wrote: > > > > Minor but important corrections. > > > > On 1/12/24 23:19, Takashi Kajinami wrote: > > > > Hello, > > > > > > As you know, some of the OpenStack projects were marked inactive during this cycle. > > There are still on-going discussions but from my view these are very likely excluded from > > the upcoming 2024.1 release and it's unclear yet if any of these projects will be kept. > > > > Currently heat provides features integrated with some of the inactive projects (Monasca, > > Sahara and Senlin), and we have to decide how we deal with these features[1]. > > > > The main concern is that we can't maintain the features for the inactive projects, and IMO > > we should retire these features if these inactive projects are abandoned or are no longer > > maintained in the consistent way with the other active projects. > > > > Based on the current situation, I'd propose the following steps for upcoming cycles. > > > > - Deprecate the features dependent on inactive projects in 2023.2 release > > - Note that we have to remove these features directly during this cycle in case any problems > > related to these project block the upcoming heat release. > > > > - Deprecate the features dependent on inactive projects in 2024.1 release > > > > > > - Remove these features in 2024.1 release unless we are sure that these projects are kept > > maintained as active projects in the openstack namespace, with following the global > > release cycle. > > > > - Remove these features in 2024.2 release ... > > > > > > > > Please let me know if you have any concern about the proposed plan. If I hear no objections > > then I'll propose patches for deprecation. > > > +1 > > I assume these projects are not expected to be `active` in the future > with some renewed interest (like I've seen with some other projects) > from the community. If at all these projects become active again, we > won't be bringing back and supporting these heat resources.Yeah, this is good point. Any project marked as Inactive can become Active againand be part of release also. Until they are explicitly marked as deprecated or retired,they are still up for maintenance. If any features going away, it does not make sense to re-add them (as Rabi mentioned)because the feature dependent project going to Inactive/Active mode. +1
IMO, we can go with ether of the below timing:1. Wait for any feature deprecation until next cycle. For any Inactive projects, TC will betaking the next step in 2nd cycle of project marked as Inactive. So all these current Inactiveprojects will be either retired or become Active in next cycle. I disagree with delaying the deprecation and do it in this cycle. If we deprecate these features in next cycle then we can't remove it until 2026.1, because of SLURP. There might be some exceptions, like we deprecate these in 2024.2 and remove these in 2025.1, but IMO we should avoid it as much as possible. Un-deprecating deprecated features are not much effort for us. It might be confusing for users, but I believe it's less confusing that removing these features in non-SLURP releases.
2. If you think those features are not used by users (which is hard to know but sending ML etccan give some answer), let's deprecate them irrespective their dependent project is Inactiveor Active. So far I've not heard any feedback to my previous email but have heard no feedback so I assume no one is using these features (at least from Heat). One exception is Monasca which is used by the people willing to maintain Monasca. However the current direction is moving out monasca from openstack/ to x/. As I mentioned earlier it's not feasible to us to keep compatibility with projects outside of the openstack governance, so if this direction is taken then I'd propose we remove monasca resources from heat code suggest anyone willing to maintain monasca resources create a separate plugin repository in x/ namespace and override the built-in resources.
Side note: TBVH I was very confused that we could not hear anything from people willing to keep Monasca, about their usage of Monasca resources in heat, until I found them in irc and asked their usage. It's really difficult to get a proper communication with people willing to keep some projects, without them subscribing the communication channels (at least I expect they can reach in mailing list as well as IRC). Because we expect some discussions triggered about inactive projects, subscribing to irc and mailing list is one type of contributions we may need from people volunteered to keeping inactive projects.
SLURP consideration for deprecation is good point. Just one update on Monasca that TC re-discussed it in this week meeting and it seems there are a few people volunteer to maintain it in OpenStack namespace (fixing gate also), let's see how soon they can make it Active project.
Another good point about communication, in my experience it is not just Monasca but many other projects having same issue. I also do not get response from IRC or ML but when I send individual email reminder then I do get the response. I am not sure how to solve this communication problem but I agree with your analysis here.
-gmann
-gmann > > > Thank you, > > Takashi Kajinami > > irc: tkajinam > > > > > > [1] > > I've submitted a series of patches to remove these features and these would give a clear view > > about the features affected. > > https://review.opendev.org/q/topic:%22inactive-project-removal%22+project:op... > > > > > -- > Regards, > Rabi Mishra > >