Open Stack

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-transformation-stein+status:open
[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-notification-api.rst@687