On Mon, Feb 29, 2016 at 12:23:09PM -0500, Andrew Laski wrote: > > > On Mon, Feb 29, 2016, at 12:12 PM, Dan Smith wrote: > > > In our continued quest on being more explicit about plug points it feels > > > like we should other document the interface (which means creating > > > stability on the hook parameters) or we should deprecate this construct > > > as part of a bygone era. > > > > > > I lean on deprecation because it feels like a thing we don't really want > > > to support going forward, but I can go either way. > > > > Deprecate and remove, please. We've been removing these sorts of things > > over time, and nova hooks have been ignored in that process. But really, > > making them more rigid is going to get in the way over time, trying to > > continue to honor an interface that codifies internals at a certain > > point in time, and leaving them as-is will just continue to generate > > issues like the quoted bug. > > > > I don't "lean" on deprecation, I feel strongly that these should go away. > > I've worked on a deployment that uses them heavily and would be impacted > by their removal. They are a very convenient place to put code that > should run based on Nova events but I have yet to see a usage that > couldn't have been implemented by having a service listen to > notifications and run that same code. However there is no service that > does this. So the only argument I can see for keeping them is that it's > more convenient to put that code into Nova rather than implement > something that listens for notifications. And that's not a convincing > argument to me.
Yes, that's a prime example of a use case where we should be offering a formally supportable solution instead of an unreliable hack using hooks. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| __________________________________________________________________________ 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