On 29 February 2016 at 18:49, Andrew Laski <and...@lascii.com> wrote: > On Mon, Feb 29, 2016, at 01:18 PM, Dan Smith wrote: >> > Forgive my ignorance or for playing devil's advocate, but wouldn't the >> > main difference between notifications and hooks be that notifications >> > are asynchronous and hooks aren't? >> >> The main difference is that notifications are external and intended to >> be stable (especially with the versioned notifications effort). The >> hooks are internal and depend wholly on internal data structures. >> >> > In the case of how Rdo was using it, >> > they are adding things to the injected_files list before the instance is >> > created in the compute API. You couldn't do that with notifications as >> > far as I know. >> >> Nope, definitely not, but I see that as a good thing. Injecting files >> like that is likely to be very fragile and I think mostly regarded as >> substantially less desirable than the alternatives, regardless of how it >> happens. >> >> I think that Laski's point was that the most useful and least dangerous >> thing that hooks can be used for is the use case that is much better >> served by notifications. > > Yep. My experience with them was things like updating an external cache > on create/delete or calling out to a DNS provider to remove a reverse > DNS entry on instance delete. Things that could easily be handled with > notifications, and use cases that I think we should continue to support > by improving notifications if necessary. > > >> >> So, if file injection (and any other internals-mangling that other >> people may use them for) is not a reason to keep hooks, and if >> notifications are the proper way to trigger on things happening, then >> there's no reason to keep hooks.
+1 on the deprecation of hooks. There will not be a single replacement for the hooks. Deprecation is the best thing we can do to trigger good conversations about how we replacing hooks with a supportable alternatives, that will not break horribly across upgrades. This is an important part of our push towards improving API interoperability, see: http://docs.openstack.org/developer/nova/project_scope.html#api-scope The OpenStack Compute API should behave the same across all deployments (i.e. any differences should be discoverable). Thanks, johnthetubaguy PS Around DNS integrations, we have just added this: https://blueprints.launchpad.net/nova/+spec/neutron-hostname-dns Injecting files fights interoperability in a nasty way, but do take a look at this: https://github.com/openstack/nova/blob/master/nova/api/metadata/vendordata_json.py The work around versioned notifications should make it possible to build a async system from our notification stream: http://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/versioned-notification-api.html __________________________________________________________________________ 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