On Fri, May 22, 2015 at 08:37:16PM -0700, Andy Hill wrote:
> QoS set by tc does not survive a restart of the openvswitch service,
> including ones during upgrades (verified on 2.1.0.34867). We've seen
> this behavior at Rackspace across several OVS upgrades. We manually
> rebuild QoS immediately following upgrades.
For the record, I'm not saying that OVS behavior is ideal here. It
would be better if OVS didn't do that. We could change OVS not to do
that. The only case where that would could really cause a problem is a
scenario like this:
1. In the OVS database, the manager (which could be a human admin
or a program) sets an interface to use some particular QoS
settings. OVS configures them on the interface.
2. Someone stops OVS.
3. The manager deletes the QoS settings from the OVS database.
4. Someone starts OVS again.
Currently, following step 4, OVS clears the QoS settings, because it
always believes that it owns them, but with this change it would
preserve them.
Other possible changes in this area, with different tradeoffs:
* Add a QoS type that says that OVS should leave the QoS
settings alone for an interface. This would solve the problem
but it seems user-unfriendly, since it is surprising that OVS
changes the QoS settings at all if it isn't asked to do so.
* Make OVS record in the database when it changes the QoS
settings (upon request only), so that it can change them back
only if it set them up to begin with. This might be hard to
do reliably across system reboots and deletions and creations
of distinct network devices that have the same name.
Feedback on this issue is very welcome!
_______________________________________________
discuss mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/discuss
