Open Stack

On Nov 20, 2012, at 9:57 AM, "Daniel P. Berrange" <berrange at redhat.com> wrote:

> On Tue, Nov 20, 2012 at 10:40:58AM -0500, Russell Bryant wrote:
>> Greetings,
>> 
>> There is currently a patch in the review queue for nova that adds hooks.
>> 
>> https://review.openstack.org/#/c/16336/
>> 
>> I like the concept, but I think it could benefit from some design
>> discussion.  That's difficult on gerrit and much better suited for the
>> mailing list, so here we are.
> 
> My thoughts are
> 
> - What is the intended usage of the hooks?
> - What is the usage relationship between hooks & extensions ?
> - What are they expected to be allowed to do / not do ?
> - What guarantees are provided wrt hooks continuing to
>   work minor, and major updates ?
> - What internal APIs (if any) should hooks be allowed to
>   use ?
> - Is there any way to enforce any rules we make above ?
> 
> My overriding desire is that we want to avoid sleep-walking into
> a situation where people write all sorts of hooks; these rely
> on internal code we consider unstable; we're then forced to maintain
> stabilty of internal APIs across major and/or minor updates to avoid
> breaking people's hooks.
> 

Good morning,

The goal around hooks is rather simple.  It's to provide a convenient, non-magical way to insert code "wrapping" a function that doesn't require you to shove additional code into the Nova codebase.  It's just a decorator allowing you to run arbitrary code before and after the wrapped function.  For example, you could use this as a convenience method to do systems integration functions for your cloud that may not make sense to everyone upstream.

Adding a named 'create' hook to a function:

@add_hook("create")
def create(self, x, y, z=1):
    # do stuff
    return rv

The decorator would invoke hook code that is registered for the 'create' hook.  The signature of such code will look like this:

def pre(*args, **kwargs):
	# do stuff.  args = (x,y)  kwargs={'z': 1}

def post(rv, *args, **kwargs)
  	# rv is the return value of the create function


My concept for what a hook can do is…whatever the heck you want.  My preference is to not provide *any* stability of API guarantees.  We have APIs and notifications if people want to do customizations off of a more controlled interface.

Here are some more questions:
1) return value - let 'post' hooks modify the return value of the wrapped function?  
2) ordering - create an ability to explicitly define the order hook code will run in?
3) exception handling -  let the hook code manage exceptions,?

Thanks,
Brian