)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"206a9d61d5cdeb33428d713e9c119419afc6eefe","unresolved":false,"context_lines":[{"line_number":8,"context_line":""},{"line_number":9,"context_line":"Since 20.09, OVN supports VXLAN type for inter-chassis communication."},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"Depends-On: I1ff47fc3398760d5b631bf89e6cfcc7ae339f0e3"},{"line_number":12,"context_line":"Change-Id: I81c016ba9c91282d1bebb40a282077e14ce4bd6b"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":3,"id":"9f560f44_ee4b59ae","line":11,"updated":"2020-10-01 08:20:52.000000000","message":"this depends-on just bumped OVS hash, but OVN used is still 20.06 AFAICT.\n\nAlso, should we maybe add some validation what ovn version is actually installed before enabling vxlan type in ovn mech driver? Or at least add some note in the documentation?","commit_id":"a516001782dee1dc69784caedeb41ded24f0a325"},{"author":{"_account_id":9656,"name":"Ihar Hrachyshka","email":"ihrachys@redhat.com","username":"ihrachys","status":"Red Hat Networking Systems Engineer"},"change_message_id":"1f6eb0eeab7af3a2f3e0dcf2c60c2ed4c7ab8058","unresolved":false,"context_lines":[{"line_number":8,"context_line":""},{"line_number":9,"context_line":"Since 20.09, OVN supports VXLAN type for inter-chassis communication."},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"Depends-On: I1ff47fc3398760d5b631bf89e6cfcc7ae339f0e3"},{"line_number":12,"context_line":"Change-Id: I81c016ba9c91282d1bebb40a282077e14ce4bd6b"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":3,"id":"9f560f44_3ccd705e","line":11,"in_reply_to":"9f560f44_19e36308","updated":"2020-10-02 14:54:09.000000000","message":"What would the sanity check do? To properly validate OVN (not OVS) behavior, we would have to create a new switch, land ports on vxlan enabled chassis, then check connectivity. A fit that seems to be overkill to me.\n\nPerhaps there is some other check that is less involving? What would it be?","commit_id":"a516001782dee1dc69784caedeb41ded24f0a325"},{"author":{"_account_id":8655,"name":"Jakub Libosvar","email":"libosvar@redhat.com","username":"jlibosva"},"change_message_id":"911a541a5173b84b2c59296a8ef0e57ee673ee9d","unresolved":false,"context_lines":[{"line_number":8,"context_line":""},{"line_number":9,"context_line":"Since 20.09, OVN supports VXLAN type for inter-chassis communication."},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"Depends-On: I1ff47fc3398760d5b631bf89e6cfcc7ae339f0e3"},{"line_number":12,"context_line":"Change-Id: I81c016ba9c91282d1bebb40a282077e14ce4bd6b"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":3,"id":"9f560f44_19e36308","line":11,"in_reply_to":"9f560f44_c8ae3b80","updated":"2020-10-02 08:53:21.000000000","message":"Perhaps we can add a sanity check like we do for OVS? \n\nhttps://github.com/openstack/neutron/blob/master/neutron/cmd/sanity/checks.py#L53","commit_id":"a516001782dee1dc69784caedeb41ded24f0a325"},{"author":{"_account_id":9656,"name":"Ihar Hrachyshka","email":"ihrachys@redhat.com","username":"ihrachys","status":"Red Hat Networking Systems Engineer"},"change_message_id":"96202816c691825692a05c8248f79efb98147bc9","unresolved":false,"context_lines":[{"line_number":8,"context_line":""},{"line_number":9,"context_line":"Since 20.09, OVN supports VXLAN type for inter-chassis communication."},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"Depends-On: I1ff47fc3398760d5b631bf89e6cfcc7ae339f0e3"},{"line_number":12,"context_line":"Change-Id: I81c016ba9c91282d1bebb40a282077e14ce4bd6b"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":3,"id":"9f560f44_c8ae3b80","line":11,"in_reply_to":"9f560f44_ee4b59ae","updated":"2020-10-02 02:49:09.000000000","message":"this depends-on was needed to pass the gate, it was not my intent to bump the version of OVS or OVN as part of the patch.\n\nNot sure about type validation check. Do we do it for other types? There is no explicit check to execute to determine if OVN is ready for VXLAN, but I guess we could use the presence of nb_global.options[\u0027max_tunid\u0027] key as an indicator of a fresh enough OVN setup since the key was added as part of VXLAN support. Do you think it\u0027s worth pursuing considering we don\u0027t do any explicit checks for other types? (for example, one may have no vlan encaps configured in OVN but have the type enabled for ML2. Is it a real problem?)\n\nDocumentation: yes, I will add it.","commit_id":"a516001782dee1dc69784caedeb41ded24f0a325"}]}