)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"1fe16bae410005dd74f404875849b557c698a9ca","unresolved":true,"context_lines":[{"line_number":11,"context_line":"the Placement API during neutron-server startup. However, this method"},{"line_number":12,"context_line":"was never called from production code, only from unit tests."},{"line_number":13,"context_line":""},{"line_number":14,"context_line":"When OVN controller registers a chassis in the SB DB before"},{"line_number":15,"context_line":"neutron-server starts, the OVSDB IDL initial sync does not generate"},{"line_number":16,"context_line":"ROW_CREATE events for pre-existing rows. The ChassisBandwidthConfigEvent"},{"line_number":17,"context_line":"handler only processes ROW_CREATE and ROW_UPDATE events, so chassis"},{"line_number":18,"context_line":"that already exist with resource_provider_bandwidths in their CMS"},{"line_number":19,"context_line":"options are silently ignored. This results in no bandwidth resource"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"2eb538ea_c9bcaba0","line":16,"range":{"start_line":14,"start_character":0,"end_line":16,"end_character":40},"updated":"2026-06-26 09:29:54.000000000","message":"That\u0027s not true. Initially the method `read_initial_chassis_config` was used to bulk read all the existing chassis registers and update the placement config. But that was not needed since [1]. There I removed the call to `read_initial_chassis_config` [2] because now we read the chassis placement config when we receive the IDL updates [3].\n\nI\u0027m manually testing in my dev env. I updated the placement config:\n```\nroot@u24ovn1:~# ovs-vsctl set Open_vSwitch .   external_ids:ovn-cms-options\u003d\"resource_provider_bandwidths\u003dbr-ex:1001:2000;rp_tunnelled:5000:6000, \\\n                                resource_provider_inventory_defaults\u003dallocation_ratio:1.0;min_unit:10, \\\n                                resource_provider_hypervisors\u003dbr-ex:u24ovn1;rp_tunnelled:u24ovn1\"\n\n```\n\nAnd I see the changes in the provider list:\n```\n$ openstack resource provider list \n+--------------------------------------+-------------------------------------------+------------+--------------------------------------+--------------------------------------+\n| uuid                                 | name                                      | generation | root_provider_uuid                   | parent_provider_uuid                 |\n+--------------------------------------+-------------------------------------------+------------+--------------------------------------+--------------------------------------+\n| fb5e30ac-1a6f-4d2c-9bda-4ce9b5a267e0 | u24ovn1                                   |          2 | fb5e30ac-1a6f-4d2c-9bda-4ce9b5a267e0 | None                                 |\n| 04de42a0-11ee-5094-8019-38e193bdc17c | u24ovn1:OVN Controller agent              |          1 | fb5e30ac-1a6f-4d2c-9bda-4ce9b5a267e0 | fb5e30ac-1a6f-4d2c-9bda-4ce9b5a267e0 |\n| 7b6f7659-d141-5af2-9c92-0d7769687bbe | u24ovn1:OVN Controller agent:br-ex        |          4 | fb5e30ac-1a6f-4d2c-9bda-4ce9b5a267e0 | 04de42a0-11ee-5094-8019-38e193bdc17c |\n| 025c4dab-c85f-5efc-a987-457ff2232fa3 | u24ovn1:OVN Controller agent:rp_tunnelled |          4 | fb5e30ac-1a6f-4d2c-9bda-4ce9b5a267e0 | 04de42a0-11ee-5094-8019-38e193bdc17c |\n+--------------------------------------+-------------------------------------------+------------+--------------------------------------+--------------------------------------+\n```\n\nThat works with the Neutron API running or stopped. I can delete manually the existing resource providers and then start again the Neutron API - the RPs are added again to the placement API.\n\n\n[1]https://review.opendev.org/c/openstack/neutron/+/945017\n[2]https://review.opendev.org/c/openstack/neutron/+/945017/4/neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/ovn_db_sync.py\n[3]https://review.opendev.org/c/openstack/neutron/+/945017/4/neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/extensions/placement.py#147","commit_id":"46afbff1888768eea2583a8d3cdf04953cc535b9"},{"author":{"_account_id":33341,"name":"Maor Blaustein","email":"mblue@redhat.com","username":"blue"},"change_message_id":"52900fefcbfd5840464631cd912adce005eb2073","unresolved":true,"context_lines":[{"line_number":11,"context_line":"the Placement API during neutron-server startup. However, this method"},{"line_number":12,"context_line":"was never called from production code, only from unit tests."},{"line_number":13,"context_line":""},{"line_number":14,"context_line":"When OVN controller registers a chassis in the SB DB before"},{"line_number":15,"context_line":"neutron-server starts, the OVSDB IDL initial sync does not generate"},{"line_number":16,"context_line":"ROW_CREATE events for pre-existing rows. The ChassisBandwidthConfigEvent"},{"line_number":17,"context_line":"handler only processes ROW_CREATE and ROW_UPDATE events, so chassis"},{"line_number":18,"context_line":"that already exist with resource_provider_bandwidths in their CMS"},{"line_number":19,"context_line":"options are silently ignored. This results in no bandwidth resource"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"5bb3b80c_d210219e","line":16,"range":{"start_line":14,"start_character":0,"end_line":16,"end_character":40},"in_reply_to":"2eb538ea_c9bcaba0","updated":"2026-06-28 17:31:35.000000000","message":"Thank you for reviewing and checking this issue.\n\nI\u0027m sorry I didn\u0027t explain the reproducer well enough in the commit message.\nThe issue is specifically about the startup order, not runtime updates.\n\nI suspect the test you did here (setting CMS options while neutron is running) works because it triggers a ROW_UPDATE event on the Chassis table, the ChassisBandwidthConfigEvent handler processes it correctly.\n\nWhile the issue I hit:\nwhen CMS options are set before neutron-server starts (which is what devstack does, _start_ovs sets CMS, then start_neutron_service_and_check starts neutron), the chassis already exists in the\nSB DB when neutron connects.\nThe IDL initial sync does not fire ROW_CREATE events for pre existing rows, and no ROW_UPDATE fires because nothing changes after neutron starts.\n\nThe fix re-adds the read_initial_chassis_config() call in OvnSbSynchronizer.do_sync() to catch pre-existing chassis that the event handler misses during startup (since neutron api wasn\u0027t running in reproducer and CREATE events missed).\n\nThe following is the reproducer with neutron fix verification, that may clarify more (paste from actual devstack session):\nhttps://paste.opendev.org/show/bPCoWpgqRMukILMT8GBp/\n(there is a tiny addition of sed to add `port-resource-request-groups` that already exists in CI job of reproducer but doesn\u0027t execute with its local.conf and stack.sh used).\n\nSequence of events:\n1. Deploy devstack with CMS options (devstack patch sets them during _start_ovs)\n2. CMS options confirmed set: sudo ovs-vsctl get Open_vSwitch . external-ids:ovn-cms-options\n(confirm shows bandwidths).\n3. openstack resource provider list\n(only Nova RP, no bandwidth RPs - issue reproduced).\n4. Cherry-pick this current fix, restart neutron services to use fix.\n5. openstack resource provider list\n(bandwidth RPs appear, fix verified).\n6. QoS min bandwidth placement test passes.\n\nI could be missing something, but I hope this clarifies more the issue and fix from my current understanding.","commit_id":"46afbff1888768eea2583a8d3cdf04953cc535b9"},{"author":{"_account_id":33341,"name":"Maor Blaustein","email":"mblue@redhat.com","username":"blue"},"change_message_id":"0109102a8800a60d80e2018376c1eb701ad0c81b","unresolved":true,"context_lines":[{"line_number":11,"context_line":"the Placement API during neutron-server startup. However, this method"},{"line_number":12,"context_line":"was never called from production code, only from unit tests."},{"line_number":13,"context_line":""},{"line_number":14,"context_line":"When OVN controller registers a chassis in the SB DB before"},{"line_number":15,"context_line":"neutron-server starts, the OVSDB IDL initial sync does not generate"},{"line_number":16,"context_line":"ROW_CREATE events for pre-existing rows. The ChassisBandwidthConfigEvent"},{"line_number":17,"context_line":"handler only processes ROW_CREATE and ROW_UPDATE events, so chassis"},{"line_number":18,"context_line":"that already exist with resource_provider_bandwidths in their CMS"},{"line_number":19,"context_line":"options are silently ignored. This results in no bandwidth resource"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"10ae5645_c4d43a00","line":16,"range":{"start_line":14,"start_character":0,"end_line":16,"end_character":40},"in_reply_to":"5bb3b80c_d210219e","updated":"2026-06-28 17:42:44.000000000","message":"Also checked neutron journal (all services) from the initial devstack deployment, zero placement related log entries.\nThe ROW_CREATE event for the pre existing chassis never reached ChassisBandwidthConfigEvent.run().\nNo \"Error connecting to Placement API\" (from name2uuid) or \"Placement configuration modified\" (from run method) messages at all, possibly confirming the IDL initial sync did not fire ROW_CREATE for the existing chassis.","commit_id":"46afbff1888768eea2583a8d3cdf04953cc535b9"}]}