For orchestration (and now the scheduler improvements) we need to know when an 
operation fails ... and specifically, which resource was involved. In the 
majority of the cases it's an instance_uuid we're looking for, but it could be 
a security group id or a reservation id.

With most of the compute.manager calls the resource id is the third parameter 
in the call (after self & context), but there are some oddities. And sometimes 
we need to know the additional parameters (like a migration id related to an 
instance uuid). So simply enforcing parameter orders may be insufficient and 
impossible to enforce programmatically.

A little background:

In nova, exceptions are generally handled in the RPC or middleware layers as a 
logged event and life goes on. In an attempt to tie this into the notification 
system, a while ago I added stuff to the wrap_exception decorator. I'm sure 
you've seen this nightmare scattered around the code:
@exception.wrap_exception(notifier=notifier, publisher_id=publisher_id())

What started as a simple decorator now takes parameters and the code has become 
nasty. 

But it works ... no matter where the exception was generated, the notifier gets:
*   compute.<host_id>
*   <method name>
*   and whatever arguments the method takes.

So, we know what operation failed and the host it failed on, but someone needs 
to crack the argument nut to get the goodies. It's a fragile coupling from 
publisher to receiver.

One, less fragile, alternative is to put a try/except block inside every 
top-level nova.compute.manager method and send meaningful exceptions right from 
the source. More fidelity, but messier code. Although "explicit is better than 
implicit" keeps ringing in my head.

Or, we make a general event parser that anyone can use ... but again, the link 
between the actual method and the parser is fragile. The developers have to 
remember to update both. 

Opinions?

-S








_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Reply via email to