)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":32688,"name":"Victor Chembaev","email":"chembervint@gmail.com","username":"chembervint"},"change_message_id":"e5e3abdc69a8e611332110d114832d0ff76cfcfa","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"523c47ce_7e3231a2","updated":"2024-05-24 12:50:59.000000000","message":"recheck galaxy collection could not be installed due to network timeout","commit_id":"009aa0d93522bb0bac4fd18504358a95c45045b0"},{"author":{"_account_id":14200,"name":"Maksim Malchuk","email":"maksim.malchuk@gmail.com","username":"mmalchuk"},"change_message_id":"04d1731a05103faef3b380335ce2723f53869074","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"7fb672c3_b878a37d","updated":"2024-05-24 12:46:53.000000000","message":"recheck galaxy timed out","commit_id":"009aa0d93522bb0bac4fd18504358a95c45045b0"},{"author":{"_account_id":32398,"name":"Gaël THEROND","display_name":"Fl1nt","email":"gael.therond@bitswalk.com","username":"Fl1nt"},"change_message_id":"1f62c931e86f73d54323e3fe9802b4e80395acd6","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":5,"id":"dea72fb9_f62d6545","updated":"2024-07-31 13:51:02.000000000","message":"LGTM as a first step to stabilize the current design and then work an alternative.","commit_id":"a3fcc07c7a52d72cee497f1abc8e4b8bb661557a"},{"author":{"_account_id":22629,"name":"Michal Nasiadka","email":"mnasiadka@gmail.com","username":"mnasiadka"},"change_message_id":"9a68d895b72fb422b923889e2dbcec833114069b","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":5,"id":"bf1c0a91_d40811ca","updated":"2024-07-22 07:47:41.000000000","message":"Not saying this is not the right fix, but can you rework this functionality in master so that we stop getting those ips via DHCP, but statically - and this is not an issue anymore?","commit_id":"a3fcc07c7a52d72cee497f1abc8e4b8bb661557a"},{"author":{"_account_id":26285,"name":"wu.chunyang","email":"wchy1001@gmail.com","username":"wu.chunyang"},"change_message_id":"cd5b4f3d9682a793fd23d81a7b1a1f0ef9cc152a","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":5,"id":"f4727417_90e2585e","updated":"2024-08-02 08:00:32.000000000","message":"This fix LGTM, but I think you should not use this way in a large cluster. because octavia-interface may not be reliable enough(may be affect by neutron or OpenVswitch openflow), if this port was broken for some reason, this may cause all amphoras to be failover, which may not be what we want to see. \nIn my opinion, A vlan（or flat）provider network is more preferred for production.","commit_id":"a3fcc07c7a52d72cee497f1abc8e4b8bb661557a"},{"author":{"_account_id":26285,"name":"wu.chunyang","email":"wchy1001@gmail.com","username":"wu.chunyang"},"change_message_id":"a72c0b1782d32d5e99af1d761428dfc37442c72f","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":5,"id":"7a7aa5a8_9cb28168","in_reply_to":"1799bade_d303815c","updated":"2024-08-21 08:28:28.000000000","message":"Hi Victor, both tenant network and provider network are attached in the OVS bridge though, but octavia interface needs to get the ip address from the neutron DHCP agent and need to be configured by the neutron OVS agent. some times, we may encounter the problem of OVS/Neutron(eg. lost one or more flows) on controller nodes which may affect the interface, This is what i concern.\nBy the contrast, provider network is a lay-2 network, octavia interface can be set to a physical network nic with a static address. in this case, octavia interface are not depended on the OVS but the external physical Switch.\nOn the other side, if we use bridge or OVN driver, this way will not work, so i prefer to regard the octavia-interface as a testing purpose.\n\n\n\u003e And also for the reliability we have deploy at least 2 health monitor containers on different nodes. So even if we will experience network problems on one of it it seams it should not affect all LBs?\n\nyes, unless all the interface are not accessible, there is no effect on amphoras.","commit_id":"a3fcc07c7a52d72cee497f1abc8e4b8bb661557a"},{"author":{"_account_id":32688,"name":"Victor Chembaev","email":"chembervint@gmail.com","username":"chembervint"},"change_message_id":"e940f28ad5a740b6c6f357883f36a1404fae7e7e","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":5,"id":"cb1c122d_4faaccf0","in_reply_to":"7a7aa5a8_9cb28168","updated":"2024-09-03 14:18:06.000000000","message":"Hi, I\u0027m agree with you. so what do you think - should we add something to documentation regarding this patch? My opinion, that connecting amphoras to L2 lbaas-mgmt network is not a subject of kolla-ansible right now. At least we can\u0027t automatically configure o-hm interfaces for such config.","commit_id":"a3fcc07c7a52d72cee497f1abc8e4b8bb661557a"},{"author":{"_account_id":22629,"name":"Michal Nasiadka","email":"mnasiadka@gmail.com","username":"mnasiadka"},"change_message_id":"dd43004b7dbab04fb2dbde1abb029b6282b30251","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":5,"id":"8f83a8a7_92d89178","in_reply_to":"85baaa17_f8971a7e","updated":"2024-09-12 11:22:55.000000000","message":"We\u0027re not talking customers here, at most operators - that\u0027s one thing.\n\nSecond thing is - we always recommended using VLAN type L2 network, at least that\u0027s what I thought - this feature was rather a way to get it working in CI and for some dev environments.\n\nThird thing is - configuring OS level networking things is rather Kayobe job, not Kolla-Ansible.\n\nThe addition in the docs made in this patch still is under \"Development and Testing\" section, and then we mention on large deployments. I don\u0027t think anybody has large Development and Testing deployments - with this knob we\u0027re basically promoting people to use that ,,feature\u0027\u0027.\nI don\u0027t know if that\u0027s good or bad - but if we want to say that this is ,,production ready\u0027\u0027 - then we need more changes in the docs.\nI think best would be discuss that on one of the Kolla weekly meetings.","commit_id":"a3fcc07c7a52d72cee497f1abc8e4b8bb661557a"},{"author":{"_account_id":22629,"name":"Michal Nasiadka","email":"mnasiadka@gmail.com","username":"mnasiadka"},"change_message_id":"7885649a11c727c6fb59454787601ba844b62eea","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":5,"id":"02929419_2ae40153","in_reply_to":"8f83a8a7_92d89178","updated":"2024-09-18 13:24:44.000000000","message":"Agreed on the meeting to leave it under test/dev.","commit_id":"a3fcc07c7a52d72cee497f1abc8e4b8bb661557a"},{"author":{"_account_id":32688,"name":"Victor Chembaev","email":"chembervint@gmail.com","username":"chembervint"},"change_message_id":"69f731fa08e530596faf810fdce4f519ac9d6264","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":5,"id":"1e5857f2_3971396a","in_reply_to":"bf1c0a91_d40811ca","updated":"2024-07-22 10:23:30.000000000","message":"Hi,\nit\u0027s not actually clear how to do it statically in the best way. To config this interface statically we have to put somewhere network config, which could depends on \n - linux distro (Debian, Ubuntu or RH-based)\n - in case debian - it will be debian network config\n - in case of ubuntu - netplan\n - in case of RH-based - NM is used or network-scripts\n\nAnother way I\u0027ve thought about - systemd-networkd. But again - it could be not at all linux distros\n\nWhat we can do? Just change current systemd unit file not to start dhcp, but to execute \"ip a a \u003cip_address\u003e o-hm0\", but it looks like hard-code, and actually not better then current dhcp, as for me, because:\n- anyway we have to wait OVS is up and running, to appear o-hm0 interface in the system\n- in case of neutron will not be able to finish sync properly - static address will not help us.\n\nSo may be somebody has good ideas how we can implement it?","commit_id":"a3fcc07c7a52d72cee497f1abc8e4b8bb661557a"},{"author":{"_account_id":32688,"name":"Victor Chembaev","email":"chembervint@gmail.com","username":"chembervint"},"change_message_id":"c61a0083ab355b574f6036959720e846e732782c","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":5,"id":"85baaa17_f8971a7e","in_reply_to":"cb1c122d_4faaccf0","updated":"2024-09-12 11:13:39.000000000","message":"And also I wanted to add, that connecting Amphoras to phys net requires L2 connectivity on all compute nodes, which not a target architecture for number of deployments. So, my option, that we have to\n1. solve current problem (with this patch)\n2. may be, provide some arch planning guide for octavia, but it seams to me another task. or let\u0027s decide what we have to add to the docs. I\u0027m not sure that we have to recommend l2 connectivity for \"production\" on for \"high-load\". It is just one of available options, but is is not applicable for number of customers.","commit_id":"a3fcc07c7a52d72cee497f1abc8e4b8bb661557a"},{"author":{"_account_id":32688,"name":"Victor Chembaev","email":"chembervint@gmail.com","username":"chembervint"},"change_message_id":"e1ca47ecfedc358301190d7675ecc881c3852ad6","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":5,"id":"1799bade_d303815c","in_reply_to":"f4727417_90e2585e","updated":"2024-08-13 18:45:00.000000000","message":"Hi, sounds reasonable. But how vlan\\flat provider network will increase reliability, if they are also should be connected to the OVS bridge? And so the same way depends on OVS readiness, and possible lags?\nAnd also for the reliability we have deploy at least 2 health monitor containers on different nodes. So even if we will experience network problems on one of it it seams it should not affect all LBs?","commit_id":"a3fcc07c7a52d72cee497f1abc8e4b8bb661557a"}],"ansible/roles/octavia/templates/octavia-interface.service.j2":[{"author":{"_account_id":22629,"name":"Michal Nasiadka","email":"mnasiadka@gmail.com","username":"mnasiadka"},"change_message_id":"b09b0c8540d3d1c419e07a52b0d6abf271b65968","unresolved":true,"context_lines":[{"line_number":7,"context_line":"Type\u003doneshot"},{"line_number":8,"context_line":"User\u003droot"},{"line_number":9,"context_line":"Group\u003droot"},{"line_number":10,"context_line":"TimeoutStartSec\u003d1800"},{"line_number":11,"context_line":"RemainAfterExit\u003dtrue"},{"line_number":12,"context_line":"ExecStartPre\u003d/sbin/ip link set dev {{ octavia_network_interface }} address {{ port_info.port.mac_address }}"},{"line_number":13,"context_line":"ExecStart\u003d/sbin/dhclient -v {{ octavia_network_interface }} -cf /etc/dhcp/octavia-dhclient.conf"}],"source_content_type":"text/x-jinja2","patch_set":2,"id":"70cb01e8_033028e3","line":10,"updated":"2024-05-26 06:24:28.000000000","message":"Can we make that configurable and default to systemd default (instead of hardcoding)? And document that on some environments that timeout needs to be as high as this?","commit_id":"c2001dc358c0ad799a989e2685ddb673f2c0e627"},{"author":{"_account_id":32688,"name":"Victor Chembaev","email":"chembervint@gmail.com","username":"chembervint"},"change_message_id":"5afd5bafcadf9f96e9bd05de40de6ba73b1e141d","unresolved":false,"context_lines":[{"line_number":7,"context_line":"Type\u003doneshot"},{"line_number":8,"context_line":"User\u003droot"},{"line_number":9,"context_line":"Group\u003droot"},{"line_number":10,"context_line":"TimeoutStartSec\u003d1800"},{"line_number":11,"context_line":"RemainAfterExit\u003dtrue"},{"line_number":12,"context_line":"ExecStartPre\u003d/sbin/ip link set dev {{ octavia_network_interface }} address {{ port_info.port.mac_address }}"},{"line_number":13,"context_line":"ExecStart\u003d/sbin/dhclient -v {{ octavia_network_interface }} -cf /etc/dhcp/octavia-dhclient.conf"}],"source_content_type":"text/x-jinja2","patch_set":2,"id":"e7b57294_5ab1114e","line":10,"in_reply_to":"70cb01e8_033028e3","updated":"2024-06-24 14:23:51.000000000","message":"Done, thank you for your comment!","commit_id":"c2001dc358c0ad799a989e2685ddb673f2c0e627"}],"doc/source/reference/networking/octavia.rst":[{"author":{"_account_id":22629,"name":"Michal Nasiadka","email":"mnasiadka@gmail.com","username":"mnasiadka"},"change_message_id":"1b1e5481b432706439d44dc36fb4d2e16d08c6d4","unresolved":true,"context_lines":[{"line_number":437,"context_line":""},{"line_number":438,"context_line":"Next，follow the deployment instructions as normal."},{"line_number":439,"context_line":""},{"line_number":440,"context_line":"Failure handling"},{"line_number":441,"context_line":"----------------"},{"line_number":442,"context_line":""},{"line_number":443,"context_line":"On large deployments, where neutron-openvswitch-agent sync could takes"}],"source_content_type":"text/x-rst","patch_set":5,"id":"fef0061a_7657e1cf","line":440,"updated":"2024-08-13 16:06:36.000000000","message":"Can we also add the notes from wuchunyang\u0027s comment (that during that time you may experience Amphoras being constantly failed over due to failing health checks from the Octavia service)?","commit_id":"a3fcc07c7a52d72cee497f1abc8e4b8bb661557a"},{"author":{"_account_id":22629,"name":"Michal Nasiadka","email":"mnasiadka@gmail.com","username":"mnasiadka"},"change_message_id":"7885649a11c727c6fb59454787601ba844b62eea","unresolved":false,"context_lines":[{"line_number":437,"context_line":""},{"line_number":438,"context_line":"Next，follow the deployment instructions as normal."},{"line_number":439,"context_line":""},{"line_number":440,"context_line":"Failure handling"},{"line_number":441,"context_line":"----------------"},{"line_number":442,"context_line":""},{"line_number":443,"context_line":"On large deployments, where neutron-openvswitch-agent sync could takes"}],"source_content_type":"text/x-rst","patch_set":5,"id":"0d87fa2c_2ce25bdc","line":440,"in_reply_to":"fef0061a_7657e1cf","updated":"2024-09-18 13:24:44.000000000","message":"Done","commit_id":"a3fcc07c7a52d72cee497f1abc8e4b8bb661557a"}],"releasenotes/notes/fix-octavia-interface-timeout-5e87ea2501d5ab3c.yaml":[{"author":{"_account_id":32553,"name":"Sven Kieske","email":"sven_oss@posteo.de","username":"skieske"},"change_message_id":"69b79efbc439ff4c5593040234190df8a844f662","unresolved":true,"context_lines":[{"line_number":2,"context_line":"fixes:"},{"line_number":3,"context_line":"  - |"},{"line_number":4,"context_line":"    Fixes 2067036."},{"line_number":5,"context_line":"    Raise octavia-interface.service timeout to 30m to wait"},{"line_number":6,"context_line":"    openvswitch agent sync has been finished and"},{"line_number":7,"context_line":"    octavia-lb-net is reachable from the host."},{"line_number":8,"context_line":"    `LP#2067036 \u003chttps://launchpad.net/bugs/2067036\u003e`__"}],"source_content_type":"text/x-yaml","patch_set":4,"id":"e84cc779_cb7660c6","line":7,"range":{"start_line":5,"start_character":0,"end_line":7,"end_character":46},"updated":"2024-07-17 13:25:19.000000000","message":"please adjust the release note to the latest patchset.\n\nmention the changed restart policy and that the default timeout is not changed (thus not fixed, technically), but the user can now adjust this.\n\nThanks","commit_id":"87ecfe03a0d1874bde3e7ab588987e46622653fb"},{"author":{"_account_id":32688,"name":"Victor Chembaev","email":"chembervint@gmail.com","username":"chembervint"},"change_message_id":"132eff19c5b9bb6b15575603190b22025b0ea085","unresolved":false,"context_lines":[{"line_number":2,"context_line":"fixes:"},{"line_number":3,"context_line":"  - |"},{"line_number":4,"context_line":"    Fixes 2067036."},{"line_number":5,"context_line":"    Raise octavia-interface.service timeout to 30m to wait"},{"line_number":6,"context_line":"    openvswitch agent sync has been finished and"},{"line_number":7,"context_line":"    octavia-lb-net is reachable from the host."},{"line_number":8,"context_line":"    `LP#2067036 \u003chttps://launchpad.net/bugs/2067036\u003e`__"}],"source_content_type":"text/x-yaml","patch_set":4,"id":"6ebe9ce8_48d30149","line":7,"range":{"start_line":5,"start_character":0,"end_line":7,"end_character":46},"in_reply_to":"e84cc779_cb7660c6","updated":"2024-07-17 13:58:56.000000000","message":"Thank you for your comment! I\u0027ve fixed the reno","commit_id":"87ecfe03a0d1874bde3e7ab588987e46622653fb"}]}