Open Stack

On Mon, Feb 29, 2016 at 12:03:00PM -0600, Matt Riedemann wrote:
> 
> 
> On 2/29/2016 11:23 AM, 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.
> >
> >So I agree with moving forward on deprecation and think that
> >notifications provide a suitable replacement for the functionality
> >provided.
> 
> 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?  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.

Sure, notifications do *not* replace all possible use case of the current
hooks, but I think that is actually desirable.

There's three core scenarios for hooks

 1. Modifying some aspect of the Nova operation
 2. Triggering an external action synchronously to some Nova operation
 3. Triggering an external action asynchronously to some Nova operation

The Rdo example is falling in scenario 1 since it is modifying the
injected files. I think this is is absolutely the kind of thing
we should explicitly *never* support. When external code can arbitrarily
modify some aspect of Nova operation we're in totally unchartered
territory as to the behaviour of Nova. To support that we'd need to
provide a stable internal API which is just not something we want to
tie ourselves into. I don't know just what the Rdo example is trying
to achieve, but whatever it is, it should be via some supportable API
and not a hook.,

Scenaris 2 and 3 are both valid to consider. Using the notifications
system gets as an asynchronous trigger mechanism, which is probably
fine for many scenarios.  The big question is whether there's a
compelling need for scenario two, where the external action blocks
execution of the Nova operation until it has completed its hook.

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 :|