)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":11600,"name":"Michał Dulko","email":"michal.dulko@gmail.com","username":"dulek"},"change_message_id":"dd6ff8ff86bc768dfd0844a455573b4e444de40b","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":5,"id":"26863cb7_ca7ddc46","updated":"2022-04-05 11:07:31.000000000","message":"We\u0027ve tried something similar with our nested setup (when Kubernetes nodes are VM) and failed due to ARP issues. Is this targeting a baremetal use case (Kubernetes is running on servers that have neutron-agent running)? Do you have a working PoC of this? What are the network policy considerations here, i.e. what is taking care of them?","commit_id":"f532cf358d4b7760e8290b0f6d020c6b91284597"},{"author":{"_account_id":28329,"name":"yangjianfeng","display_name":"JeffYang","email":"yjf1970231893@gmail.com","username":"yangjianfeng"},"change_message_id":"6e5dbd69d6a3f1197be06d6ac20574a6fd0e1a74","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":5,"id":"cbbe4d20_52f7cb0a","in_reply_to":"26863cb7_ca7ddc46","updated":"2022-04-06 11:15:45.000000000","message":"I noticed that you mention \u0027ARP issues\u0027, Do you have more informations for this issues? I already committed a code patch [1] for this spec, I noticed that you already left some comments ont it. It work fine on sngle node, but I haven\u0027t test it for multle nodes scenario.\n\n[1] https://review.opendev.org/c/openstack/kuryr-kubernetes/+/834637","commit_id":"f532cf358d4b7760e8290b0f6d020c6b91284597"}],"doc/source/devref/kube_proxy_support.rst":[{"author":{"_account_id":11600,"name":"Michał Dulko","email":"michal.dulko@gmail.com","username":"dulek"},"change_message_id":"dd6ff8ff86bc768dfd0844a455573b4e444de40b","unresolved":true,"context_lines":[{"line_number":70,"context_line":"         |                |              |                     |"},{"line_number":71,"context_line":"    +----+-----+    +-----+----+       +-+--+                +-+--+"},{"line_number":72,"context_line":"    |          |    |          |       |    |                |    |"},{"line_number":73,"context_line":"    |host node1|    |host node2|       |pod1|                |pod2|"},{"line_number":74,"context_line":"    |          |    |          |       |    |                |    |"},{"line_number":75,"context_line":"    +----------+    +----------+       +----+                +----+"},{"line_number":76,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"e0c68d8e_c915014c","line":73,"range":{"start_line":73,"start_character":5,"end_line":73,"end_character":15},"updated":"2022-04-05 11:07:31.000000000","message":"Is this a VM in OpenStack or a baremetal node?","commit_id":"f532cf358d4b7760e8290b0f6d020c6b91284597"},{"author":{"_account_id":28329,"name":"yangjianfeng","display_name":"JeffYang","email":"yjf1970231893@gmail.com","username":"yangjianfeng"},"change_message_id":"6e5dbd69d6a3f1197be06d6ac20574a6fd0e1a74","unresolved":true,"context_lines":[{"line_number":70,"context_line":"         |                |              |                     |"},{"line_number":71,"context_line":"    +----+-----+    +-----+----+       +-+--+                +-+--+"},{"line_number":72,"context_line":"    |          |    |          |       |    |                |    |"},{"line_number":73,"context_line":"    |host node1|    |host node2|       |pod1|                |pod2|"},{"line_number":74,"context_line":"    |          |    |          |       |    |                |    |"},{"line_number":75,"context_line":"    +----------+    +----------+       +----+                +----+"},{"line_number":76,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"ef86d95b_890128cc","line":73,"range":{"start_line":73,"start_character":5,"end_line":73,"end_character":15},"in_reply_to":"e0c68d8e_c915014c","updated":"2022-04-06 11:15:45.000000000","message":"This is a baremetal node, this spec just used to baremetal case.","commit_id":"f532cf358d4b7760e8290b0f6d020c6b91284597"}],"doc/source/devref/kuryr_proxy_support.rst":[{"author":{"_account_id":23567,"name":"Luis Tomas Bolivar","email":"ltomasbo@redhat.com","username":"ltomasbo"},"change_message_id":"9cba557685006b8d9f7962851d85c1055722bd52","unresolved":true,"context_lines":[{"line_number":91,"context_line":""},{"line_number":92,"context_line":"Because the k8s service\u0027s cluster IP located in each host node, so"},{"line_number":93,"context_line":"`kuryr-kubernetes` should add the below route on the pod router::"},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"  172.18.0.0/16 via 10.0.1.1"},{"line_number":96,"context_line":"                    10.0.1.2"},{"line_number":97,"context_line":""},{"line_number":98,"context_line":"This is a ECMP route, by the route the pod can access any host node\u0027s k8s"},{"line_number":99,"context_line":"service cluster ip."}],"source_content_type":"text/x-rst","patch_set":2,"id":"54941d0c_5b4fbfe3","line":96,"range":{"start_line":94,"start_character":0,"end_line":96,"end_character":28},"updated":"2022-03-16 12:54:04.000000000","message":"why ECMP here? each node will have its own tap device, right? So in each node there will be a different ip, right?\nnode 1 --\u003e 172.18.0.0/16 via 10.0.1.1\nnode 2 --\u003e 172.18.0.0/16 via 10.0.1.2","commit_id":"c267ef499051cd2b33adc7fd38d4fefd63b8d122"},{"author":{"_account_id":28329,"name":"yangjianfeng","display_name":"JeffYang","email":"yjf1970231893@gmail.com","username":"yangjianfeng"},"change_message_id":"1c7129335519dd5701b0aedb1bcb2db36d3a855a","unresolved":true,"context_lines":[{"line_number":91,"context_line":""},{"line_number":92,"context_line":"Because the k8s service\u0027s cluster IP located in each host node, so"},{"line_number":93,"context_line":"`kuryr-kubernetes` should add the below route on the pod router::"},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"  172.18.0.0/16 via 10.0.1.1"},{"line_number":96,"context_line":"                    10.0.1.2"},{"line_number":97,"context_line":""},{"line_number":98,"context_line":"This is a ECMP route, by the route the pod can access any host node\u0027s k8s"},{"line_number":99,"context_line":"service cluster ip."}],"source_content_type":"text/x-rst","patch_set":2,"id":"e196021b_02d2f0f2","line":96,"range":{"start_line":94,"start_character":0,"end_line":96,"end_character":28},"in_reply_to":"54941d0c_5b4fbfe3","updated":"2022-03-17 02:09:24.000000000","message":"Yep, each node need have its own tap device. The ECMP route is for High Available and High Performance, each node has its own kube-proxy and this kube-proxy is identical, so kuryr can forward the traffic to any host node. it user add a third host node, the route should like this:\n172.18.0.0/16 via 10.0.1.1\n                  10.0.1.2\n                  10.0.1.3","commit_id":"c267ef499051cd2b33adc7fd38d4fefd63b8d122"},{"author":{"_account_id":23567,"name":"Luis Tomas Bolivar","email":"ltomasbo@redhat.com","username":"ltomasbo"},"change_message_id":"9cba557685006b8d9f7962851d85c1055722bd52","unresolved":true,"context_lines":[{"line_number":99,"context_line":"service cluster ip."},{"line_number":100,"context_line":""},{"line_number":101,"context_line":"Suppose, the request traffic be forwarded to host node1, and the host node1"},{"line_number":102,"context_line":"forward it to pod2, in order to ensuser the response traffic can reture host"},{"line_number":103,"context_line":"node1, we need to modify the traffic\u0027s source ip to address of tap device of"},{"line_number":104,"context_line":"host node1. So, the below iptables rule should be added in host node1"},{"line_number":105,"context_line":"by `kuryr-daemon`::"}],"source_content_type":"text/x-rst","patch_set":2,"id":"19b1a64e_99509c4f","line":102,"range":{"start_line":102,"start_character":32,"end_line":102,"end_character":39},"updated":"2022-03-16 12:54:04.000000000","message":"ensure","commit_id":"c267ef499051cd2b33adc7fd38d4fefd63b8d122"},{"author":{"_account_id":23567,"name":"Luis Tomas Bolivar","email":"ltomasbo@redhat.com","username":"ltomasbo"},"change_message_id":"9cba557685006b8d9f7962851d85c1055722bd52","unresolved":true,"context_lines":[{"line_number":99,"context_line":"service cluster ip."},{"line_number":100,"context_line":""},{"line_number":101,"context_line":"Suppose, the request traffic be forwarded to host node1, and the host node1"},{"line_number":102,"context_line":"forward it to pod2, in order to ensuser the response traffic can reture host"},{"line_number":103,"context_line":"node1, we need to modify the traffic\u0027s source ip to address of tap device of"},{"line_number":104,"context_line":"host node1. So, the below iptables rule should be added in host node1"},{"line_number":105,"context_line":"by `kuryr-daemon`::"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9a9ffea5_1c21a8bb","line":102,"range":{"start_line":102,"start_character":65,"end_line":102,"end_character":71},"updated":"2022-03-16 12:54:04.000000000","message":"return","commit_id":"c267ef499051cd2b33adc7fd38d4fefd63b8d122"},{"author":{"_account_id":28329,"name":"yangjianfeng","display_name":"JeffYang","email":"yjf1970231893@gmail.com","username":"yangjianfeng"},"change_message_id":"1c7129335519dd5701b0aedb1bcb2db36d3a855a","unresolved":true,"context_lines":[{"line_number":99,"context_line":"service cluster ip."},{"line_number":100,"context_line":""},{"line_number":101,"context_line":"Suppose, the request traffic be forwarded to host node1, and the host node1"},{"line_number":102,"context_line":"forward it to pod2, in order to ensuser the response traffic can reture host"},{"line_number":103,"context_line":"node1, we need to modify the traffic\u0027s source ip to address of tap device of"},{"line_number":104,"context_line":"host node1. So, the below iptables rule should be added in host node1"},{"line_number":105,"context_line":"by `kuryr-daemon`::"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5f811b1c_28b47c30","line":102,"range":{"start_line":102,"start_character":32,"end_line":102,"end_character":39},"in_reply_to":"19b1a64e_99509c4f","updated":"2022-03-17 02:09:24.000000000","message":"thanks","commit_id":"c267ef499051cd2b33adc7fd38d4fefd63b8d122"},{"author":{"_account_id":28329,"name":"yangjianfeng","display_name":"JeffYang","email":"yjf1970231893@gmail.com","username":"yangjianfeng"},"change_message_id":"1c7129335519dd5701b0aedb1bcb2db36d3a855a","unresolved":true,"context_lines":[{"line_number":99,"context_line":"service cluster ip."},{"line_number":100,"context_line":""},{"line_number":101,"context_line":"Suppose, the request traffic be forwarded to host node1, and the host node1"},{"line_number":102,"context_line":"forward it to pod2, in order to ensuser the response traffic can reture host"},{"line_number":103,"context_line":"node1, we need to modify the traffic\u0027s source ip to address of tap device of"},{"line_number":104,"context_line":"host node1. So, the below iptables rule should be added in host node1"},{"line_number":105,"context_line":"by `kuryr-daemon`::"}],"source_content_type":"text/x-rst","patch_set":2,"id":"70da52aa_1b1a53ac","line":102,"range":{"start_line":102,"start_character":65,"end_line":102,"end_character":71},"in_reply_to":"9a9ffea5_1c21a8bb","updated":"2022-03-17 02:09:24.000000000","message":"thanks","commit_id":"c267ef499051cd2b33adc7fd38d4fefd63b8d122"},{"author":{"_account_id":23567,"name":"Luis Tomas Bolivar","email":"ltomasbo@redhat.com","username":"ltomasbo"},"change_message_id":"9cba557685006b8d9f7962851d85c1055722bd52","unresolved":true,"context_lines":[{"line_number":123,"context_line":"    |    |               |          |                   |          |"},{"line_number":124,"context_line":"    +----+               +----------+                   +----+-----+"},{"line_number":125,"context_line":"                                                             |     3"},{"line_number":126,"context_line":"                                                             |s:10.0.1.1"},{"line_number":127,"context_line":"                                                             |d:10.0.3.1"},{"line_number":128,"context_line":"                       5                      4              v"},{"line_number":129,"context_line":"      +----------+ s:10.0.3.1  +----+    s:10.0.1.1     +----+-----+"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3a348f63_3e06a161","line":126,"updated":"2022-03-16 12:54:04.000000000","message":"missing the geneve/vxlan tunneling information to move from host_node1 to host_node2","commit_id":"c267ef499051cd2b33adc7fd38d4fefd63b8d122"},{"author":{"_account_id":28329,"name":"yangjianfeng","display_name":"JeffYang","email":"yjf1970231893@gmail.com","username":"yangjianfeng"},"change_message_id":"66109dc2657bd367892b800a8ae9ab4ca73a8922","unresolved":true,"context_lines":[{"line_number":123,"context_line":"    |    |               |          |                   |          |"},{"line_number":124,"context_line":"    +----+               +----------+                   +----+-----+"},{"line_number":125,"context_line":"                                                             |     3"},{"line_number":126,"context_line":"                                                             |s:10.0.1.1"},{"line_number":127,"context_line":"                                                             |d:10.0.3.1"},{"line_number":128,"context_line":"                       5                      4              v"},{"line_number":129,"context_line":"      +----------+ s:10.0.3.1  +----+    s:10.0.1.1     +----+-----+"}],"source_content_type":"text/x-rst","patch_set":2,"id":"34ab508c_e8a729ac","line":126,"in_reply_to":"28c2e0fc_3c8f2899","updated":"2022-03-17 09:03:32.000000000","message":"Well, I think I understand your menas. But I still have some confusion for your comment. The document\u0027s main purpose is how to use raw kube-proxy with kuryr, means that this document should focus on the traffic that pod to service to pod. The traffic of pod to pod (don\u0027t pass through k8s service) needn\u0027t kuryr make any special process, right? This should is a neutron\u0027s issue, so we needn\u0027t illustrate it here.","commit_id":"c267ef499051cd2b33adc7fd38d4fefd63b8d122"},{"author":{"_account_id":28329,"name":"yangjianfeng","display_name":"JeffYang","email":"yjf1970231893@gmail.com","username":"yangjianfeng"},"change_message_id":"aacd34fb8cc550e6501d232e8142385504e0a2c9","unresolved":true,"context_lines":[{"line_number":123,"context_line":"    |    |               |          |                   |          |"},{"line_number":124,"context_line":"    +----+               +----------+                   +----+-----+"},{"line_number":125,"context_line":"                                                             |     3"},{"line_number":126,"context_line":"                                                             |s:10.0.1.1"},{"line_number":127,"context_line":"                                                             |d:10.0.3.1"},{"line_number":128,"context_line":"                       5                      4              v"},{"line_number":129,"context_line":"      +----------+ s:10.0.3.1  +----+    s:10.0.1.1     +----+-----+"}],"source_content_type":"text/x-rst","patch_set":2,"id":"d56e0916_141ede3e","line":126,"in_reply_to":"34ab508c_e8a729ac","updated":"2022-03-17 09:31:21.000000000","message":"This is a L3 traffic diagram. So I ignore the L2 traffic processing, this shouldn\u0027t be this document\u0027s concern, I tried to add L2 network element to it, but then the graph would be bloated. Maybe, I should rename `host node1` to `host node` in this graph, this might clear up potential ambiguity.","commit_id":"c267ef499051cd2b33adc7fd38d4fefd63b8d122"},{"author":{"_account_id":28329,"name":"yangjianfeng","display_name":"JeffYang","email":"yjf1970231893@gmail.com","username":"yangjianfeng"},"change_message_id":"1c7129335519dd5701b0aedb1bcb2db36d3a855a","unresolved":true,"context_lines":[{"line_number":123,"context_line":"    |    |               |          |                   |          |"},{"line_number":124,"context_line":"    +----+               +----------+                   +----+-----+"},{"line_number":125,"context_line":"                                                             |     3"},{"line_number":126,"context_line":"                                                             |s:10.0.1.1"},{"line_number":127,"context_line":"                                                             |d:10.0.3.1"},{"line_number":128,"context_line":"                       5                      4              v"},{"line_number":129,"context_line":"      +----------+ s:10.0.3.1  +----+    s:10.0.1.1     +----+-----+"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9af1a2cf_75b2ea8a","line":126,"in_reply_to":"3a348f63_3e06a161","updated":"2022-03-17 02:09:24.000000000","message":"Well, the provider network type has no effect for this traffic path, vlan is also ok. This is ACTIVE-ACTIVE architecture, just need one host node process the traffic forward.","commit_id":"c267ef499051cd2b33adc7fd38d4fefd63b8d122"},{"author":{"_account_id":23567,"name":"Luis Tomas Bolivar","email":"ltomasbo@redhat.com","username":"ltomasbo"},"change_message_id":"69b654b6c1c20da28862cb6cd89c6a6dcb1cecff","unresolved":true,"context_lines":[{"line_number":123,"context_line":"    |    |               |          |                   |          |"},{"line_number":124,"context_line":"    +----+               +----------+                   +----+-----+"},{"line_number":125,"context_line":"                                                             |     3"},{"line_number":126,"context_line":"                                                             |s:10.0.1.1"},{"line_number":127,"context_line":"                                                             |d:10.0.3.1"},{"line_number":128,"context_line":"                       5                      4              v"},{"line_number":129,"context_line":"      +----------+ s:10.0.3.1  +----+    s:10.0.1.1     +----+-----+"}],"source_content_type":"text/x-rst","patch_set":2,"id":"28c2e0fc_3c8f2899","line":126,"in_reply_to":"9af1a2cf_75b2ea8a","updated":"2022-03-17 07:31:15.000000000","message":"this is not about N/S (provider) traffic but about E/W. And if pod1 is in different node than pod2, they need to go through a geneve (for ovn) or vxlan (for ovs) tunnel. In your example you represent host node1, but not host node2","commit_id":"c267ef499051cd2b33adc7fd38d4fefd63b8d122"},{"author":{"_account_id":23567,"name":"Luis Tomas Bolivar","email":"ltomasbo@redhat.com","username":"ltomasbo"},"change_message_id":"9cba557685006b8d9f7962851d85c1055722bd52","unresolved":true,"context_lines":[{"line_number":143,"context_line":"     +----------+              +----------+             +----+"},{"line_number":144,"context_line":""},{"line_number":145,"context_line":"As above graph, the source ip of the response traffic from host node1 to pod1"},{"line_number":146,"context_line":"is 172.18.0.1, so the allowed address 172.18.0.0/16 should be added to the"},{"line_number":147,"context_line":"neutron port which corresponding to host node tap device. The ingress rule"},{"line_number":148,"context_line":"which has remote ip 172.18.0.0/16 should be added to the neutron port\u0027s"},{"line_number":149,"context_line":"security group."}],"source_content_type":"text/x-rst","patch_set":2,"id":"c879d372_b567390f","line":146,"range":{"start_line":146,"start_character":21,"end_line":146,"end_character":51},"updated":"2022-03-16 12:54:04.000000000","message":"allow address pairs is for IPs, not for subnets AFAIK. Perhaps this tap device should have security disabled instead","commit_id":"c267ef499051cd2b33adc7fd38d4fefd63b8d122"},{"author":{"_account_id":28329,"name":"yangjianfeng","display_name":"JeffYang","email":"yjf1970231893@gmail.com","username":"yangjianfeng"},"change_message_id":"bda838f6484efa38cc3d4cbd6275c4faf30b152a","unresolved":true,"context_lines":[{"line_number":143,"context_line":"     +----------+              +----------+             +----+"},{"line_number":144,"context_line":""},{"line_number":145,"context_line":"As above graph, the source ip of the response traffic from host node1 to pod1"},{"line_number":146,"context_line":"is 172.18.0.1, so the allowed address 172.18.0.0/16 should be added to the"},{"line_number":147,"context_line":"neutron port which corresponding to host node tap device. The ingress rule"},{"line_number":148,"context_line":"which has remote ip 172.18.0.0/16 should be added to the neutron port\u0027s"},{"line_number":149,"context_line":"security group."}],"source_content_type":"text/x-rst","patch_set":2,"id":"03b0ce7e_d320d643","line":146,"range":{"start_line":146,"start_character":21,"end_line":146,"end_character":51},"in_reply_to":"a23783e2_93cd9cff","updated":"2022-03-18 06:17:01.000000000","message":"As the document title described, the solution should don\u0027t adapt OVN backend (The ovn backend also not support ECMP route). Moreover, if add allowed address to port one by one, this will generate a mass of database records and ovs flow entries or iptables rules, I worry this will result in some potential performance issues.","commit_id":"c267ef499051cd2b33adc7fd38d4fefd63b8d122"},{"author":{"_account_id":28329,"name":"yangjianfeng","display_name":"JeffYang","email":"yjf1970231893@gmail.com","username":"yangjianfeng"},"change_message_id":"1c7129335519dd5701b0aedb1bcb2db36d3a855a","unresolved":true,"context_lines":[{"line_number":143,"context_line":"     +----------+              +----------+             +----+"},{"line_number":144,"context_line":""},{"line_number":145,"context_line":"As above graph, the source ip of the response traffic from host node1 to pod1"},{"line_number":146,"context_line":"is 172.18.0.1, so the allowed address 172.18.0.0/16 should be added to the"},{"line_number":147,"context_line":"neutron port which corresponding to host node tap device. The ingress rule"},{"line_number":148,"context_line":"which has remote ip 172.18.0.0/16 should be added to the neutron port\u0027s"},{"line_number":149,"context_line":"security group."}],"source_content_type":"text/x-rst","patch_set":2,"id":"f4ec0e69_9a4e1b8d","line":146,"range":{"start_line":146,"start_character":21,"end_line":146,"end_character":51},"in_reply_to":"c879d372_b567390f","updated":"2022-03-17 02:09:24.000000000","message":"Well, the cidr also is ok for neutron. IMO, the pord security group should be enable in order to avoid some potential security issues.","commit_id":"c267ef499051cd2b33adc7fd38d4fefd63b8d122"},{"author":{"_account_id":23567,"name":"Luis Tomas Bolivar","email":"ltomasbo@redhat.com","username":"ltomasbo"},"change_message_id":"69b654b6c1c20da28862cb6cd89c6a6dcb1cecff","unresolved":true,"context_lines":[{"line_number":143,"context_line":"     +----------+              +----------+             +----+"},{"line_number":144,"context_line":""},{"line_number":145,"context_line":"As above graph, the source ip of the response traffic from host node1 to pod1"},{"line_number":146,"context_line":"is 172.18.0.1, so the allowed address 172.18.0.0/16 should be added to the"},{"line_number":147,"context_line":"neutron port which corresponding to host node tap device. The ingress rule"},{"line_number":148,"context_line":"which has remote ip 172.18.0.0/16 should be added to the neutron port\u0027s"},{"line_number":149,"context_line":"security group."}],"source_content_type":"text/x-rst","patch_set":2,"id":"a23783e2_93cd9cff","line":146,"range":{"start_line":146,"start_character":21,"end_line":146,"end_character":51},"in_reply_to":"f4ec0e69_9a4e1b8d","updated":"2022-03-17 07:31:15.000000000","message":"At least this is not fully supported by ml2/ovn (when FIPs are associated with those VIPs), as the allow_address_pair associated an IP and a MAC address to sent the GARPs","commit_id":"c267ef499051cd2b33adc7fd38d4fefd63b8d122"}]}