qos driver api can have better error handling

[YAMAMOTO Takashi]

the current qos (notification) driver api assumes driver methods are async and always success.
however, it might not be the case for some of possible backends. eg. a controller based implementation, where a driver would make a rest api call to the backend.

- currently one of drivers raises an exception, the rest of drivers are simply skipped.
  it might not be what an api user would expect.

- whan driver calls end up with an error, the db changes should be reverted, or
  the resource should be marked "possibly not sync".

[Miguel Angel Ajo (mangelajo)]

Agreed, this has been discussed in last QoS meeting
http://eavesdrop.openstack.org/meetings/neutron_qos/2016/neutron_qos.2016-10-05-14.01.log.html

[Miguel Angel Ajo (mangelajo)]

It's a tricky situation not fully resolved in ml2 or anywhere else.

What if a driver failed, but some other succeeded ?

Shall we revert them all, and then revert the DB? what if one of the reverts then fail?

I think that we should let the drivers report an error via an exception (without making other drivers fail), but at the same time, it should be the failed driver responsibility to track the need to resync such object when the backend comes back (otherwise the revert failure becomes an issue too).

[Manjeet Singh Bhatia (manjeet-s-bhatia)]

For networking-odl we have change documentation to configure driver properly,

[Isaku Yamahata (yamahata)]

networking-odl needs hooks that are called during db transaction.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/396651
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=38c1812015b6977f8212723d082222cefb0926e6
Submitter: Jenkins
Branch: master

commit 38c1812015b6977f8212723d082222cefb0926e6
Author: Miguel Angel Ajo <email address hidden>
Date: Thu Nov 17 09:17:29 2016 -0500

    Transition qos notification driver into qos driver

    This will deprecate the notification_driver config setting,
    and no config setting will be needed.

    Also it lays down the foundation for a more decoupled interaction
    with mechanism drivers.

    Closes-Bug: #1657379
    Related-Bug: #1627749
    DocImpact

    Change-Id: I2f166a43f0b980ad22617f8a3f7b4cc7f4786c48

[Manjeet Singh Bhatia (manjeet-s-bhatia)]

as notification driver is no longer in use https://review.openstack.org/#/c/454300/ so this is not valid now