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 again
and 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 be
taking the next step in 2nd cycle of project marked as Inactive. So all these current Inactive
projects 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 etc
can give some answer), let's deprecate them irrespective their dependent project is Inactive
or 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.



-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:openstack/heat
 > >
 > 
 > 
 > -- 
 > Regards,
 > Rabi Mishra
 > 
 >