Open Stack

On 29 February 2016 at 18:49, Andrew Laski <andrew at 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