Hi, Last decision from the Denver PTG [1] was to * finish the remaining transformations [2] * change the default value of notification_format conf option from 'both' to 'versioned' * communicate that the legacy notification interface has been deprecated, unsupported but the code will not be removed Since the PTG the last two transformation patches [2] has been approved and the deprecation patch has been prepared [3]. However recently we got a bug report [4] where the performance impact of emiting both legacy and versioned notification caused unnecessary load on the message bus. (Btw this performance impact was raised in the original spec [5]). The original reason we emited both type of notifications was to keep backward compatibility with consumers only understanding legacy notifications. It worked so well that most of the consumers still depend on the legacy notifications (detailed status is in [1]). I see three options to move forward: A) Do nothing. By default, emit both type of notifications. This means that deployers seeing the performance impact of [4] needs to reconfigure nova. Also this is agains our decision to move away from supporting legacy notifications. B) Follow the plan from the PTG and change the default value of the config to emit only versioned notifications. This solves the immediate effect of the bug [4]. This is following our original plan. BUT this is backward incompatible change which in the current situation means most of the deployments (e.g. those, deploying notification consumer modules like ceilometer) need to change this config to 'unversioned' or 'both'. There was discussion about helping out notification consumers to convert their code using the new versioned interface but I have no spare time at the moment and I failed to drum up resources internally for this work. Also I don't see others volunteering for such work. C) Change the default to 'legacy'. This solves the bug [4]. BUT sends a really mixed message. As our original goal was to stop supporting the legacy notification interface of nova. Matt stated on IRC recently, there is no real bug inflow for the legacy code. Also looking at changes in the code I see that last cycle we had couple of blueprints extending the new versioned notifications with extra fields but that inflow stopped in this cycle too. So we most probably can keep the legacy code in place and supported forever without too much pain and too much divergence from the versioned interface. -- Personally, I spent enough time implementing and reviewing the versioned interface that I'm biased towards option B). But I do understand that our original goals setting in 2015 was made in such environment that changed significantly in the past cycles. So I can accept option C) as well if we can agree. Cheers, gibi [1] https://etherpad.openstack.org/p/nova-ptg-stein L765 [2] https://review.openstack.org/#/q/topic:bp/versioned-notification-transformat... [3] https://review.openstack.org/#/c/603079/ [4] https://bugs.launchpad.net/nova/+bug/1805659 [5] https://review.openstack.org/#/c/224755/11/specs/mitaka/approved/versioned-n...