Hello Simon: Short answers: * There is a proposal for what you are asking for: https://bugs.launchpad.net/neutron/+bug/2102184. Apart from this, there is no spec proposed but the Neutron community was in favor of this. * No, the QoS service doesn't allow this right now. This kind of "project QoS" is still not implemented. * From the Neutron point of view, any QoS implementation should be done directly on the QoS extension. Of course, if you want to add any external script to control it, is up to you. * If you want to have this feature, rather than implementing something outside Neutron, I would suggest first to propose this feature for Neutron. The first step would be to propose a spec. Regards. On Wed, Jul 9, 2025 at 8:34 PM Simon Stephan <Simon.Stephan@wiit.cloud> wrote:

Hi all,

we’re currently migrating an OpenStack deployment from a setup using libvirt-based QoS (with per-flavor bandwidth limits) to a newer environment using OVN as the networking backend.

In the previous environment, bandwidth limits were enforced via libvirt, and each flavor had an associated QoS configuration. Now with OVN, this approach is no longer viable, and we are evaluating Neutron’s native QoS feature as a replacement.

Our goals:

- Enforce one default bandwidth limit per project (formerly done via flavor). - Apply a default QoS policy automatically to every new project, without requiring manual intervention. - Allow users to create their own projects via Domain Manager.

Current Observations:

- Neutron QoS policies must be explicitly associated with ports or networks, and there is no system-wide default or setting it on a domain level - There is no built-in mechanism in Neutron or Keystone to automatically attach a default QoS policy when a new project is created.

Our Proposed Solution:

We are exploring a solution where we:

1. Listen to project.create events on the RabbitMQ message bus. 2. Automatically assign a shared default QoS policy (defined in our service project and marked as shared=True) to the newly created project. 3. Possibly enforce this via automation, e.g. an event-driven microservice or script that uses openstacksdk.

Question to the community:

- Has anyone implemented something similar? - Is there an existing feature or plugin to apply a default Neutron QoS policy to all newly created projects or their ports/networks? - Are there better alternatives or architectural considerations we should keep in mind? - Any feedback or suggestions would be greatly appreciated.

Regards,

Simon