On 09/08/2018 15:27, Matt Riedemann wrote: > On 8/9/2018 8:44 AM, Graham Hayes wrote: >> Designate has no plans to swap or add support for the new interface in >> the near or medium term - we are more than willing to take patches, but >> we do not have the people power to do it ourselves. >> >> Some of our users do use the old interface a lot - designate-sink >> is quite heavily embeded in some workflows. > > This is what I suspected would be the answer from most projects. > > I was very half-assedly wondering if we could write some kind of > translation middleware library that allows your service to listen for > versioned notifications and translate them to legacy notifications. Then > we could apply that generically across projects that don't have time for > a big re-write while allowing nova to drop the legacy compat code (after > some period of deprecation, I was thinking at least a year). > > It should be pretty simple to write a dumb versioned->unversioned > payload mapping for each legacy notification, but there might be more > sophisticated ways of doing that using some kind of schema or template > instead. Just thinking out loud. >
I have no objection to that - and I wish we had the people to move to the new formats - I know maintaining legacy features like this is extra work no-one needs. Thinking out loud .... You could just send the deprecation notice, and we could deprecate designate-sink if no one came forward to update it - that seems fairer to push the burden on to the people who actually use the feature, not other teams maintaining legacy stuff. Does that seem overly harsh? __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev