QoS implementaiton for networking-midonet¶

QoS driver¶

Use the Neutron QoS plugin as it is. Implement MidoNet specific notification driver which communicates with the MidoNet API.

[DEFAULT]
service_plugins = qos

[qos]
notification_drivers = midonet,message_queue

setup.cfg:

neutron.qos.notification_drivers =
    midonet = midonet.neutron.services.qos.driver:MidoNetQosServiceNotificationDriver

Note: message_queue driver [4] is the AMQP RPC [7] based driver for the reference implementation. It isn’t necessary for MidoNet-only deployments.

Neutron QoS plugin [1] has notification driver mechansim [2], which can be used for networking-midonet to implement backend notifications.

When Neutron QoS plugin receives API requests, it updates the corresponding DB rows. After committing the DB changes, it calls one of the following methods of the loaded notification drivers:

• create_policy
• update_policy
• delete_policy

Note: a request for a rule (eg. update_policy_rule) ends up with a notification for the entire policy the rule belongs to.

Note: a request for a specific rule type (eg. update_policy_dscp_marking_rule) are automatically converted to a generic method (eg. update_policy_rule) by the QoS extension, namely QoSPluginBase. [6]

Error handling¶

Notification driver methods are considered async and always success. [9] Currently there’s no convenient way to report errors from the backend. While it’s possible for a driver to return an error by raising an exception, if multiple drivers are loaded and one of them fails that way, the rest of drivers are just skipped. Even if we assume the simplest case where only MidoNet QoS driver is loaded, there’s no mechanism to mark the resource error or rollback the operation. There’s an ongoing effort in Neutron [8] in that area, which might improve the situation.

Core resource extensions¶

For ML2, the existing QoS extension driver should work.

If we want to make this feature available for the monolithic plugins, the equivalent needs to be implemented for them.