)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":5948,"name":"Oleg Bondarev","email":"obondarev@mirantis.com","username":"obondarev"},"change_message_id":"a569ec413991627b231fc3bc760d55d662b9965e","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"37e8b462_fb3592b7","updated":"2021-12-01 09:44:57.000000000","message":"As I commented in bug: Thus \"physical_network\" would effectively mean \"logical\" network. Doesn\u0027t it contradict with \"physical network\" meaning? IMO it will bring inconsistency into already complex provider networks logic.","commit_id":"93061a059eee76281b506b4e1c981fa29a211bb2"},{"author":{"_account_id":5948,"name":"Oleg Bondarev","email":"obondarev@mirantis.com","username":"obondarev"},"change_message_id":"8d558c0372a334742db23e517374fa780d084457","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"96fd0147_8b598878","updated":"2021-12-01 09:47:08.000000000","message":"You still have 1 physical network on host, but in neutron config you want to separate it into 2, thus making the logical, still using \"physical_network\" term for both of them. This brings a mess IMO ","commit_id":"93061a059eee76281b506b4e1c981fa29a211bb2"},{"author":{"_account_id":5948,"name":"Oleg Bondarev","email":"obondarev@mirantis.com","username":"obondarev"},"change_message_id":"10965aaeb4f40de4f47469701a3d070d80eb9011","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"e37270a4_1a6e0151","in_reply_to":"0e20f9ab_565e2395","updated":"2021-12-02 08:07:23.000000000","message":"I\u0027m wondering if that could be addressed by creating a tagged interface eth0@4000 on the node and adding it to a separate logical bridge \"br-ext\". Thus bridge_mappings can stay as is {\"external\": br-ext, \"user\": br-vlan}?","commit_id":"93061a059eee76281b506b4e1c981fa29a211bb2"},{"author":{"_account_id":5948,"name":"Oleg Bondarev","email":"obondarev@mirantis.com","username":"obondarev"},"change_message_id":"6f7845dc0e97099dee12506238ddf61c5de9bb97","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"df60224d_1b0d7063","in_reply_to":"1c5c23f1_ec1ffd6e","updated":"2021-12-03 13:55:58.000000000","message":"\u003e You may treat that \"provider:network_type\" is an alias of \"provider:physical_network\". There is no rule to limit that one \"provider:physical_network\" cloud not have two aliases.\n\nright, but each physnet should correspond to a separate bridge - otherwise it doesn\u0027t make sense. And this is current assumption in code. Also if bridges are not unique we need to verify vlan_ranges are not intersecting, flat is not conflicting with vlan on same bridge, etc. All this leads to spaghetti code.\n\n\u003e \n\u003e This work is coming from an real deployment scenario, I\u0027m not sure why this is not acceptable. Because, if some cloud still insist to remain that 1:1 relationship, just keep all map setting as it is. But for some others, this change make the N:1 relationship available. Let the users to choose the best practice. Upstream community may never encounter/cover all users\u0027 cases, but we can make things robust and resilient.\n\nI understand and agree with the use case but I think it should be addressed on host networking configuration level.","commit_id":"93061a059eee76281b506b4e1c981fa29a211bb2"},{"author":{"_account_id":5948,"name":"Oleg Bondarev","email":"obondarev@mirantis.com","username":"obondarev"},"change_message_id":"9c98d4a1dd640eb99ec5e18cdb91a212b95f5e1f","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"d33e3dc4_8eac975b","in_reply_to":"3fc7e79b_c43afafc","updated":"2021-12-03 07:48:41.000000000","message":"Host networking configuration is usually performed by OpenStack installer system using templates, so this shouldn\u0027t be an operator\u0027s headache. Also I\u0027m not sure single bridge with many rules is simpler to debug that several bridges with specific rules. Still my main concern is that \u0027physical_network\u0027 term (and hence logic) will be compromised in neutron","commit_id":"93061a059eee76281b506b4e1c981fa29a211bb2"},{"author":{"_account_id":9531,"name":"liuyulong","display_name":"LIU Yulong","email":"i@liuyulong.me","username":"LIU-Yulong"},"change_message_id":"7aba8b40ddb17bf4f0ee028347d8a6993e61c8d5","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"0e20f9ab_565e2395","in_reply_to":"96fd0147_8b598878","updated":"2021-12-02 06:53:54.000000000","message":"Sorry, I\u0027m not sure which part is confused. {\"external\": br-vlan, \"user\": br-vlan}, this is achivable in real world, external_vlan\u003d4000 and user_vlan\u003d1000-3000 can be set for one single port in TOR for some hosts, because they have only one physical NIC. For others, if NICs are enough, it can be separated. Two logical type of network are working together on one physical, for now I did not see any foreseeable problems.\n\nSo, may I have your opinions on how to deal with such production issue?","commit_id":"93061a059eee76281b506b4e1c981fa29a211bb2"},{"author":{"_account_id":9531,"name":"liuyulong","display_name":"LIU Yulong","email":"i@liuyulong.me","username":"LIU-Yulong"},"change_message_id":"5ee7c8589fb80fcd5338e3a0392e846a16cf5c32","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"1c5c23f1_ec1ffd6e","in_reply_to":"d33e3dc4_8eac975b","updated":"2021-12-03 13:32:40.000000000","message":"You may treat that \"provider:network_type\" is an alias of \"provider:physical_network\". There is no rule to limit that one \"provider:physical_network\" cloud not have two aliases.\n\nThis work is coming from an real deployment scenario, I\u0027m not sure why this is not acceptable. Because, if some cloud still insist to remain that 1:1 relationship, just keep all map setting as it is. But for some others, this change make the N:1 relationship available. Let the users to choose the best practice. Upstream community may never encounter/cover all users\u0027 cases, but we can make things robust and resilient.","commit_id":"93061a059eee76281b506b4e1c981fa29a211bb2"},{"author":{"_account_id":9531,"name":"liuyulong","display_name":"LIU Yulong","email":"i@liuyulong.me","username":"LIU-Yulong"},"change_message_id":"111bc48ed7a5b08d262bfddba253ade02ba59b02","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"c1815c05_d167c4ad","in_reply_to":"df60224d_1b0d7063","updated":"2021-12-03 14:39:03.000000000","message":"\u003e \u003e You may treat that \"provider:network_type\" is an alias of \"provider:physical_network\". There is no rule to limit that one \"provider:physical_network\" cloud not have two aliases.\n\u003e \n\u003e right, but each physnet should correspond to a separate bridge - otherwise it doesn\u0027t make sense. And this is current assumption in code. Also if bridges are not unique we need to verify vlan_ranges are not intersecting, flat is not conflicting with vlan on same bridge, etc. All this leads to spaghetti code.\n\u003e \n\nI don\u0027t see the necessity of a separate bridge, especially when the server has only one physical network card.\n\nFor that overlapping vlans, I don\u0027t know how it can work in a single NIC host. If there is one single NIC, this means it can only access one \"provider:physical_network\", but this approach can give clouds an option to map two or more local \"provider:network_type\" to one. This is a very common usecase. Because, in real production deployment, it is almost impossible to set a host in TOR with more than one (underlay/physical) VLAN network plane, aka two or more sets of 4096 vlan_IDs can be consumed, configuration complexity will increase dramatically.\n\nFlat network has its own mapping. Mis-configurations can not be avoided at all. But make things right, this should be the main responsibilities for OPers.\n\n\u003e \u003e \n\u003e \u003e This work is coming from an real deployment scenario, I\u0027m not sure why this is not acceptable. Because, if some cloud still insist to remain that 1:1 relationship, just keep all map setting as it is. But for some others, this change make the N:1 relationship available. Let the users to choose the best practice. Upstream community may never encounter/cover all users\u0027 cases, but we can make things robust and resilient.\n\u003e \n\u003e I understand and agree with the use case but I think it should be addressed on host networking configuration level.","commit_id":"93061a059eee76281b506b4e1c981fa29a211bb2"},{"author":{"_account_id":9531,"name":"liuyulong","display_name":"LIU Yulong","email":"i@liuyulong.me","username":"LIU-Yulong"},"change_message_id":"9f77f0ac9eb36ee2c5dcfd16341645bac77131f5","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"3fc7e79b_c43afafc","in_reply_to":"e37270a4_1a6e0151","updated":"2021-12-03 00:35:41.000000000","message":"I\u0027m not sure if it works. But what if there are more required types of network-type-x, network-type-y, network-type-z and so on. How many vlan sub-interface should we create? IMO, one single config should be simpler for operators, because they do not need to add more bridges, sub interfaces and tags. One single bridge is fine to work, and is simpler to do trouble shooting.","commit_id":"93061a059eee76281b506b4e1c981fa29a211bb2"},{"author":{"_account_id":5948,"name":"Oleg Bondarev","email":"obondarev@mirantis.com","username":"obondarev"},"change_message_id":"3c769a25bc52b6d6aa843806ae6e35d879012264","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"48f30ce1_da55fc86","updated":"2021-12-02 08:08:13.000000000","message":"-1 as this should be discussed on Drivers meeting as Lajos commented in the bug","commit_id":"be7b17b43c5d2c9b3b543cde19a6b50d55e2089b"},{"author":{"_account_id":23567,"name":"Luis Tomas Bolivar","email":"ltomasbo@redhat.com","username":"ltomasbo"},"change_message_id":"71ee90c33cc8e5c770c79b159402007a16cb1241","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"ce1ee2ba_8843fa0d","updated":"2022-01-12 07:46:42.000000000","message":"This seems to go in a different direction as the recently merged patch https://review.opendev.org/c/openstack/neutron/+/823568. Adding -1 to ensure discussion","commit_id":"be7b17b43c5d2c9b3b543cde19a6b50d55e2089b"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"cefa556937fdce2ee741ff3d3f280af2544feb34","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"5a99dd36_b08d39ec","updated":"2022-01-18 09:02:09.000000000","message":"This was discussed during the drivers meeting and was refused to go that direction by the drivers team. One physical bridge should be connected to the one physical network and we shouldn\u0027t relax that limitation.","commit_id":"be7b17b43c5d2c9b3b543cde19a6b50d55e2089b"}]}