After thinking about it, they are not the same thing, service providers
were designed to have multiple backends to pick from, at resource
creation time.
This is not the case of qos_plugin, where the notification driver is
just a plug to the backend implementation, while we remove the burden of
DB manipulation, and provide qos policy objects to the notification
driver as they change.
** Changed in: neutron
Status: In Progress => Opinion
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1558614
Title:
The QoS notification_driver is just a service_provider, and we should
look into moving to that
Status in neutron:
Opinion
Bug description:
The notification_driver parameter for QoS is just a service provider, that
it's then called
from the QoS plugin, when a policy is created, changed or deleted.
We should look into moving into the standard naming of
"service_providers" and deprecate the other.
https://github.com/openstack/neutron/blob/master/neutron/services/qos/notification_drivers/qos_base.py#L17
https://github.com/openstack/neutron/blob/master/neutron/services/qos/notification_drivers/manager.py
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1558614/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : [email protected]
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
