)]}'
{"neutron/privileged/agent/linux/svd.py":[{"author":{"_account_id":8655,"name":"Jakub Libosvar","email":"libosvar@redhat.com","username":"jlibosva"},"change_message_id":"f6d71e6de7cd92cc419f6bf82608ab1e3469f7c2","unresolved":true,"context_lines":[{"line_number":183,"context_line":""},{"line_number":184,"context_line":""},{"line_number":185,"context_line":"@privileged.default.entrypoint"},{"line_number":186,"context_line":"def create_svd(br_evpn, vxlan_evpn, local_ip, mac, vxlan_parent, dstport,"},{"line_number":187,"context_line":"               br_mtu):"},{"line_number":188,"context_line":"    \"\"\"Create a shared Single VxLAN Device (SVD)"},{"line_number":189,"context_line":""}],"source_content_type":"text/x-python","patch_set":1,"id":"c52f3729_baccb153","line":186,"updated":"2026-08-31 15:02:35.000000000","message":"I haven\u0027t liked from the beginning the function creates everything in a single call with no error handling per device. I think now it\u0027s time to break it down to a function per device with its own error handling, instead of monitoring which device we actually created successfully and then loop over them in a cleanup.\n\nWhat do you think about that approach?","commit_id":"ee4669e7b35ebd4268c96ea93f9c122c238f3d19"},{"author":{"_account_id":32681,"name":"Phillip Dale","email":"phillip.dale@cleura.com","username":"pdale62"},"change_message_id":"3e0c2e2c68cab819c6dc5fe176106c1ab096d8cb","unresolved":true,"context_lines":[{"line_number":183,"context_line":""},{"line_number":184,"context_line":""},{"line_number":185,"context_line":"@privileged.default.entrypoint"},{"line_number":186,"context_line":"def create_svd(br_evpn, vxlan_evpn, local_ip, mac, vxlan_parent, dstport,"},{"line_number":187,"context_line":"               br_mtu):"},{"line_number":188,"context_line":"    \"\"\"Create a shared Single VxLAN Device (SVD)"},{"line_number":189,"context_line":""}],"source_content_type":"text/x-python","patch_set":1,"id":"9dc67238_0583fbcb","line":186,"in_reply_to":"bc5ad64c_fd253834","updated":"2026-09-01 07:09:25.000000000","message":"Want to confirm I\u0027ve read this right before writing it: the objection is to tracking created devices so they can be rolled back, not to the fix itself, so the goal is a shape where nothing needs undoing.\n\nMiro - agreed they compose, and 1003198 looks right as is: yours stops the process dying, this one stops the SVD being destroyed.\n\nIf I have it right, the split is three rather than two, since one step is a relationship rather than a device:\n\n- create_bridge() - ADD bridge (vlan_filtering, pvid 0), mac, up, mtu, addrgenmode none\n- create_vxlan() - parent lookup, ADD vxlan (dstport, local, no learning, vnifilter), mac, addrgenmode none\n- attach() - vxlan master\u003dbridge and up, then brport vlan_tunnel / neigh_suppress / learning off\n\nThen the fork, which is where I\u0027d like your input:\n\n- create-or-fail (today\u0027s contract): attach() failing still leaves someone deciding whether to remove the bridge and vxlan, so the tracking moves up to the caller rather than disappearing.\n- create-or-reuse: no rollback at all, and a partially built SVD gets completed on the next agent start, which this path already runs on every start. This is the option that actually removes the created list.\n\nFour things worth naming before picking:\n\n1. create-or-reuse means rewriting test_create_svd_device_exists and test_add_vni_netlink_error, which assert a second call raises.\n\n2. A pre-existing vxlan can\u0027t be corrected by a SET - parent, dstport, local and vnifilter are creation-time - so reuse means either verifying those against the existing device or trusting it, and recreating to fix a mismatch would destroy the VNIs riding on it.\n\n3. It settles the interaction with 1003198: _PROVISIONING_ERRORS catches SvdNetlinkError, which is what \"VNI already configured\" raises today. Under create-or-fail that needs handling below the FSM or the VRF is logged as failed and left unadvertised; under create-or-reuse it never raises and the question disappears.\n\n4. Either way I\u0027d prefer attach() to re-apply its SETs unconditionally rather than be skipped when the master is already set. vlan_tunnel and neigh_suppress are what let the one vxlan carry many VNIs, so a port that is enslaved but missing those flags breaks multi-VNI while a single VNI can still look healthy. The SETs are idempotent, so re-applying costs nothing.\n\nWhich path?","commit_id":"ee4669e7b35ebd4268c96ea93f9c122c238f3d19"},{"author":{"_account_id":32681,"name":"Phillip Dale","email":"phillip.dale@cleura.com","username":"pdale62"},"change_message_id":"35a134bb020ca37bdd05eeca17dcf223764cb518","unresolved":true,"context_lines":[{"line_number":183,"context_line":""},{"line_number":184,"context_line":""},{"line_number":185,"context_line":"@privileged.default.entrypoint"},{"line_number":186,"context_line":"def create_svd(br_evpn, vxlan_evpn, local_ip, mac, vxlan_parent, dstport,"},{"line_number":187,"context_line":"               br_mtu):"},{"line_number":188,"context_line":"    \"\"\"Create a shared Single VxLAN Device (SVD)"},{"line_number":189,"context_line":""}],"source_content_type":"text/x-python","patch_set":1,"id":"c59e8427_cdd1651e","line":186,"in_reply_to":"c52f3729_baccb153","updated":"2026-08-31 16:56:18.000000000","message":"Makes sense. Two shapes: bridge / vxlan / attach as helpers inside this entrypoint, or as separate entrypoints. The enslave-plus-brport step needs both devices, so it wants its own function either way.\n\nWhich would you prefer? And should those stay create-or-fail, or become create-or-reuse? Reuse drops the rollback entirely, but changes what test_create_svd_device_exists and test_add_vni_netlink_error assert.\n\nHappy to write it. Fold into this change, or land this fix and stack the restructure on top?","commit_id":"ee4669e7b35ebd4268c96ea93f9c122c238f3d19"},{"author":{"_account_id":34271,"name":"Miro Tomaska","display_name":"Miro Tomaska","email":"mtomaska@redhat.com","username":"mtomaska"},"change_message_id":"0d4e02c450a4959474c561368a70c3ec5f777394","unresolved":true,"context_lines":[{"line_number":183,"context_line":""},{"line_number":184,"context_line":""},{"line_number":185,"context_line":"@privileged.default.entrypoint"},{"line_number":186,"context_line":"def create_svd(br_evpn, vxlan_evpn, local_ip, mac, vxlan_parent, dstport,"},{"line_number":187,"context_line":"               br_mtu):"},{"line_number":188,"context_line":"    \"\"\"Create a shared Single VxLAN Device (SVD)"},{"line_number":189,"context_line":""}],"source_content_type":"text/x-python","patch_set":1,"id":"bc5ad64c_fd253834","line":186,"in_reply_to":"c59e8427_cdd1651e","updated":"2026-09-01 02:52:01.000000000","message":"I agree with Jakub. I actually just added(before looking at this patch) error handling into nl_dispatcher [1]. I think that my patch is still OK as is, while this patch can improve the SVD mechanics and error operations\n\nhttps://review.opendev.org/c/openstack/neutron/+/1003198","commit_id":"ee4669e7b35ebd4268c96ea93f9c122c238f3d19"}]}