Open Stack

On 12/6/2018 10:41 AM, Balázs Gibizer wrote:
> 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

In skimming the spec again:

https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/versioned-notification-transformation-newton.html

I get that legacy unversioned notifications in nova were kind of a mess 
and changing them without a version was icky even though they are 
internal to a deployment. Moving to using versioned notifications with 
well-defined objects, docs samples, all of that is very nice for nova 
*developers*, but what I've been struggling with is what benefit do the 
versioned notifications bring to nova *consumers*, besides we say you 
can only add new notifications if they are versioned.

In other words, what motivation does a project that is currently 
consuming unversioned legacy notifications have to put the work in to 
switch to versioned notifications? The spec doesn't really get into that 
in much detail.

I do remember an older thread with gordc where he was asking about 
schema payloads and such so a consumer could say implement processing a 
notification at version 1.0, but then if it gets a version 1.4 payload 
it could figure out how to backlevel the payload to the 1.0 version it 
understands - sort of like what we've talked about doing with os-vif 
between nova and neutron (again, for years). But that thread kind of 
died out from what I remember. But that seems like a nice benefit for 
upgrades, but I also figure it's probably very low priority on 
everyone's wishlist.

Another way I've thought about the deprecation lately is that if we 
(nova devs) did the work to migrate ceilometer, then we'd have one major 
consumer and we could then deprecate the legacy notifications and change 
the default to 'versioned'. But like you said, no one is coming out of 
the woodwork to do that work.

Anyway, I'm just having a hard time with the fact so much work has been 
put into this over the last few years that now everything is transformed 
but no one is using it, and I don't see many compelling reasons why a 
project would migrate, especially since the projects that are consuming 
nova's notifications are mostly working with a skeleton crew of maintainers.

I'd really like some input from other project developers and operators here.

-- 

Thanks,

Matt