)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"9faf1b7f5b88d1aee7150d5846e126ae5b51e281","unresolved":true,"context_lines":[{"line_number":19,"context_line":"And, also, Devstack uses dvr_snat for single-node deployments:"},{"line_number":20,"context_line":"https://github.com/openstack/devstack/blob/ee629cc77554b18cfca77506d1531f99523d2a58/lib/neutron#L44-L49"},{"line_number":21,"context_line":""},{"line_number":22,"context_line":"This new messaging seems to be confusing: if agent_mode \u003d dvr_snat can"},{"line_number":23,"context_line":"work on single-node deployments like DevStack, it may work on compute"},{"line_number":24,"context_line":"nodes in a multi-node deployment as well, since a single-node deployment"},{"line_number":25,"context_line":"is a network node + compute node + control node."},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"While OVN is preferred going forward, there are existing ML2/OVS"},{"line_number":28,"context_line":"environments that rely on dvr_snat on compute nodes. It would be good"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"107e7b67_e87edefc","line":25,"range":{"start_line":22,"start_character":0,"end_line":25,"end_character":48},"updated":"2021-10-20 10:21:47.000000000","message":"As you said, single node deployment is not only a compute node, but also a network node.\n\n\"it may work\" is not a justification.","commit_id":"3a86e3d0bf65f8a553cd7eac41411eb5bbd2ca84"},{"author":{"_account_id":24824,"name":"Dmitrii Shcherbakov","username":"dmitriis"},"change_message_id":"56cf402f50e748c924fbb86c7ab0cb2f091523b1","unresolved":true,"context_lines":[{"line_number":19,"context_line":"And, also, Devstack uses dvr_snat for single-node deployments:"},{"line_number":20,"context_line":"https://github.com/openstack/devstack/blob/ee629cc77554b18cfca77506d1531f99523d2a58/lib/neutron#L44-L49"},{"line_number":21,"context_line":""},{"line_number":22,"context_line":"This new messaging seems to be confusing: if agent_mode \u003d dvr_snat can"},{"line_number":23,"context_line":"work on single-node deployments like DevStack, it may work on compute"},{"line_number":24,"context_line":"nodes in a multi-node deployment as well, since a single-node deployment"},{"line_number":25,"context_line":"is a network node + compute node + control node."},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"While OVN is preferred going forward, there are existing ML2/OVS"},{"line_number":28,"context_line":"environments that rely on dvr_snat on compute nodes. It would be good"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"baa04952_fb33a13d","line":25,"range":{"start_line":22,"start_character":0,"end_line":25,"end_character":48},"in_reply_to":"107e7b67_e87edefc","updated":"2021-10-20 12:07:03.000000000","message":"\u003e not only a compute node, but also a network node.\n\nWhich would make all nodes to be compute + network nodes in a multi-node environment if \"agent_mode \u003d dvr_snat\" was set. And where snat components would land would depend on the l3 agent scheduler.\n\n\u003e \"it may work\" is not a justification.\n\nI don\u0027t disagree about this bit but let me clarify why I am making the case for it.\n\nFrom what I read in the docs before (and here [1] recently), it was not explicitly prohibited to turn every node in a deployment into a network + compute node. There were operational concerns about having snat namespaces scheduled to compute nodes but I think this is a compromise one has to make when trying to avoid dedicated network nodes.\n\nAs such, the documentation focused on the centralized SNAT aspect when making a distinction between network nodes and compute nodes. And, historically, network nodes were the ones that had connectivity to provider networks (DVR with direct egress via FIP namespaces blurred that difference).\n\nImplementation-wise, DvrEdgeRouter builds on top of DvrLocalRouter (from early days of DVR [2]), and adds the SNAT-related functionality to it suggesting that network nodes (from the l3 agent perspective) have the compute node l3 agent feature-set + extra logic that may not be relevant to have on computes in all scenarios:\n\nhttps://github.com/openstack/neutron/blob/19.0.0/neutron/agent/l3/dvr_edge_router.py#L28\n\nThere were changes landed over the years that suggested that running dvr_snat on compute nodes is not an unsupported configuration:\n\nhttps://github.com/openstack/neutron/commit/ee7660f593f0f997fff457021b3d5feb5c71906d#diff-aa990bf693c149a004522c0230588eda8160ec9075ef05c8d8906fe45fb099a4R360-R362\n```\n# Cover mixed dvr_snat and compute node, aka a dvr_snat node has both\n# centralized and distributed floating IPs.        super(DvrEdgeRouter, self).process_floating_ip_nat_rules()\n```\n\nIn the absence of an explicit doc entry, the usage of a single-node approach with dvr_snat in the gate tests [2], the implementation structure and prior fixes suggested that it was not unsupported.\n\n\n[1] https://meetings.opendev.org/meetings/networking/2021/networking.2021-07-20-14.00.log.html#l-120\n[2] https://opendev.org/openstack/neutron/commit/35654ec23ef9db6bda313ea300ab76c287a98ceb\n[3] https://github.com/openstack/neutron/blob/19.0.0/zuul.d/tempest-singlenode.yaml#L74-L79x","commit_id":"3a86e3d0bf65f8a553cd7eac41411eb5bbd2ca84"},{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"9faf1b7f5b88d1aee7150d5846e126ae5b51e281","unresolved":true,"context_lines":[{"line_number":24,"context_line":"nodes in a multi-node deployment as well, since a single-node deployment"},{"line_number":25,"context_line":"is a network node + compute node + control node."},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"While OVN is preferred going forward, there are existing ML2/OVS"},{"line_number":28,"context_line":"environments that rely on dvr_snat on compute nodes. It would be good"},{"line_number":29,"context_line":"to be able to contribute bug fixes around the cases that are possible"},{"line_number":30,"context_line":"to support."},{"line_number":31,"context_line":""}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"edec4b11_db8f1ff5","line":28,"range":{"start_line":27,"start_character":38,"end_line":28,"end_character":51},"updated":"2021-10-20 10:21:47.000000000","message":"What environments?","commit_id":"3a86e3d0bf65f8a553cd7eac41411eb5bbd2ca84"},{"author":{"_account_id":24824,"name":"Dmitrii Shcherbakov","username":"dmitriis"},"change_message_id":"f42d599adcbaf60bfa8ccf2fa25069a20f16cbfc","unresolved":true,"context_lines":[{"line_number":24,"context_line":"nodes in a multi-node deployment as well, since a single-node deployment"},{"line_number":25,"context_line":"is a network node + compute node + control node."},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"While OVN is preferred going forward, there are existing ML2/OVS"},{"line_number":28,"context_line":"environments that rely on dvr_snat on compute nodes. It would be good"},{"line_number":29,"context_line":"to be able to contribute bug fixes around the cases that are possible"},{"line_number":30,"context_line":"to support."},{"line_number":31,"context_line":""}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"d25206f2_33f322f5","line":28,"range":{"start_line":27,"start_character":38,"end_line":28,"end_character":51},"in_reply_to":"ec89958a_26f03709","updated":"2021-10-20 12:23:11.000000000","message":"To clarify: OVN is used for new deployments - the concern is mainly about the existing deployments.","commit_id":"3a86e3d0bf65f8a553cd7eac41411eb5bbd2ca84"},{"author":{"_account_id":24824,"name":"Dmitrii Shcherbakov","username":"dmitriis"},"change_message_id":"56cf402f50e748c924fbb86c7ab0cb2f091523b1","unresolved":true,"context_lines":[{"line_number":24,"context_line":"nodes in a multi-node deployment as well, since a single-node deployment"},{"line_number":25,"context_line":"is a network node + compute node + control node."},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"While OVN is preferred going forward, there are existing ML2/OVS"},{"line_number":28,"context_line":"environments that rely on dvr_snat on compute nodes. It would be good"},{"line_number":29,"context_line":"to be able to contribute bug fixes around the cases that are possible"},{"line_number":30,"context_line":"to support."},{"line_number":31,"context_line":""}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"ec89958a_26f03709","line":28,"range":{"start_line":27,"start_character":38,"end_line":28,"end_character":51},"in_reply_to":"edec4b11_db8f1ff5","updated":"2021-10-20 12:07:03.000000000","message":"Existing clouds deployed via OpenStack Charms with this option enabled:\n\nhttps://opendev.org/openstack/charm-neutron-openvswitch/src/commit/2230c1e60f328e369e69afb6ece6a57b658a200c/config.yaml#L344-L363\n\nThere are a quite few users that rely on that to avoid having dedicated servers for network nodes. It has quite an impact on the cost in small clouds to have multiple network nodes dedicated to running a few network services.","commit_id":"3a86e3d0bf65f8a553cd7eac41411eb5bbd2ca84"},{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"9faf1b7f5b88d1aee7150d5846e126ae5b51e281","unresolved":true,"context_lines":[{"line_number":29,"context_line":"to be able to contribute bug fixes around the cases that are possible"},{"line_number":30,"context_line":"to support."},{"line_number":31,"context_line":""},{"line_number":32,"context_line":"The goal of this change is to allow contributions around dvr_snat on"},{"line_number":33,"context_line":"compute nodes instead of completely rendering this out of support in at"},{"line_number":34,"context_line":"a late stage."},{"line_number":35,"context_line":""},{"line_number":36,"context_line":"If there are known limitations (say specific to IPv6 or OVS firewall"},{"line_number":37,"context_line":"driver as described here"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"a00959e2_b0359266","line":34,"range":{"start_line":32,"start_character":0,"end_line":34,"end_character":13},"updated":"2021-10-20 10:21:47.000000000","message":"I agree with this, but first we provide the support and then we change the docs.","commit_id":"3a86e3d0bf65f8a553cd7eac41411eb5bbd2ca84"},{"author":{"_account_id":13686,"name":"Frode Nordahl","email":"fnordahl@ubuntu.com","username":"fnordahl"},"change_message_id":"0b2f6d182f63099b39834b88a87b693375edb375","unresolved":true,"context_lines":[{"line_number":29,"context_line":"to be able to contribute bug fixes around the cases that are possible"},{"line_number":30,"context_line":"to support."},{"line_number":31,"context_line":""},{"line_number":32,"context_line":"The goal of this change is to allow contributions around dvr_snat on"},{"line_number":33,"context_line":"compute nodes instead of completely rendering this out of support in at"},{"line_number":34,"context_line":"a late stage."},{"line_number":35,"context_line":""},{"line_number":36,"context_line":"If there are known limitations (say specific to IPv6 or OVS firewall"},{"line_number":37,"context_line":"driver as described here"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"ffcd1ed0_bbb1eb2d","line":34,"range":{"start_line":32,"start_character":0,"end_line":34,"end_character":13},"in_reply_to":"a00959e2_b0359266","updated":"2021-10-20 12:25:41.000000000","message":"I guess what we are contending is the blanket not supported stance here, when there is evidence that it has been in use for a long time and is present in many in the wild OpenStack deployments. \n\nThere has been issues for sure, and we have pitched in and provided fixes for some of the issues our users have hit, and will continue to do so.\n\nWe have also bought into the move to OVN and are steering our user base in that direction, but we can\u0027t drop our existing user base on the floor until we get there.","commit_id":"3a86e3d0bf65f8a553cd7eac41411eb5bbd2ca84"}]}