To try to emphasize some points: * airflow.stats and airflow.metrics have been in there since 2.7 * as of now they are removed in main, and these removals will be reflected in 3.2 * this is ok if we agree that these were not user-public interface (i.e. people are not using them in their dags) * a (silent) vote of +1 in this lazy consensus means, yes we can remove (do nothing) * a vote of -1 means, we can't just remove we have to keep the interfaces around where they were, so we have to add backcompat shims
This is the same vote we had for traces (added 3.0), but now for airflow.stats and airflow.metrics added (2.7) On Wed, Mar 18, 2026 at 3:23 AM Christos Bisias <[email protected]> wrote: > Hello everyone, > > For accessing metrics and traces, there were metaclass interfaces, called > `Stats` and `Trace` respectively. Each interface was reading the config > and then initializing the instance of the appropriate implementation. Each > metaclass was acting like a singleton cache and in all consecutive calls > after the first one, it would always access the same existing instance. > > Daniel Standish has been leading an effort to simplify the OTel traces > code. He was able to remove the `Trace` interface and add a single > configuration when initializing all the airflow settings in core. > > Traces were simpler because they have a single supported implementation > while metrics have multiple. But after discussions, we think that we can > follow a similar approach and remove the stats interface. The reason is > that there is too much complexity that increases with every new addition or > refactoring. It's going to be easier to maintain if simplified. > > The question is whether `airflow.metrics` and `airflow.stats` are public > interfaces. They have been around since airflow 2.7 but as far as I know, > no one from the community has talked about adding user-defined metrics from > under dags. Additionally, there are no docs saying how users can do it. The > only public info is for enabling the project's internal metrics. > > I'm considering these modules as private and I'm assuming that users aren't > aware of them or using them. I think they are safe to remove. > > I would like to call for a lazy consensus vote which will run for 72 hours. > If no one votes -1 during the voting period, the vote will be considered > passed. > > Thank you! > > Regards, > Christos >
