)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":35432,"name":"Roberto Acosta","display_name":"rbartzen","email":"rbartzen@gmail.com","username":"rbartzen"},"change_message_id":"05a5d0ae186cc286bf24ecfa2f5cb37f99e167ba","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"efc06504_ed939020","updated":"2023-10-30 18:56:34.000000000","message":"Thanks for the review :)","commit_id":"fd59bc8ded5aa317748af3b9f7be6ba3751f12e6"},{"author":{"_account_id":16137,"name":"Tobias Urdin","email":"tobias.urdin@binero.com","username":"tobasco"},"change_message_id":"5e96e7cc3e943afd88a23b93ad5040f0c69679b4","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"4cfadc9c_335a117f","updated":"2023-11-08 08:28:30.000000000","message":"I think this makes sense as impact on dataplane due to RPC issues is really bad, I have a question about the timeout though, being 300 seconds I assume it more to prevent a flapping behaviour and not be resilient against a longer outage?\n\nI.e if the RPC outage is more than 300 seconds, are we causing an outage on dataplane?","commit_id":"0c42ee66a51f58c2362aceb39c7f20e2fe7b986f"},{"author":{"_account_id":35432,"name":"Roberto Acosta","display_name":"rbartzen","email":"rbartzen@gmail.com","username":"rbartzen"},"change_message_id":"b19e3469f6438a9a30cf62dd2a7102522d08363f","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"032e2cb9_e5ba240c","in_reply_to":"4cfadc9c_335a117f","updated":"2023-11-08 13:04:19.000000000","message":"Thanks for the review Tobias.\n\nThe main idea of this RFE is to prevent flapping that cause the removal of BGP peers. There are no link between this RFE and the total outage time. I mean, if the RMQ is offline/instable for a whole day, no problem, the dataplane will continue working after apply the proposed change because each time an exceptions or communication issues with RMQ occur, a new cache timeout timer will start and will not delete BGP peers until the timer expires.\n\nTherefore, the timeout time is configurable and can be adjusted according to the time it actually takes for the RMQ to respond correctly again (transient time after RMQ comes back - cluster convergence, mysql, etc.)","commit_id":"0c42ee66a51f58c2362aceb39c7f20e2fe7b986f"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"0a965d303dd1ce0118ea7fc121f03b28d0ddbc64","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"41e6d7d1_3ca09646","updated":"2023-11-15 13:11:26.000000000","message":"I agree that this can be helpful to work around our dependency on the MQ. I just left two nits, not meant to block this spec in any way.","commit_id":"a6a7ff31fad0d860625da995c53f77bfe8b7cb6f"},{"author":{"_account_id":4694,"name":"Miguel Lavalle","email":"miguel@mlavalle.com","username":"minsel"},"change_message_id":"d4cd53e4c566ae6cfb5136d166bcae66f5ab39d6","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":8,"id":"93cc19f3_16dc4e24","updated":"2024-04-05 22:53:34.000000000","message":"As indicated during the Neutron IRC meeting, merging this request at the end of this week since there are no more comments from reviewers","commit_id":"9623a1c850b139ee42f2facaa31b61aed18c0bbc"}],"specs/2024.1/l3bgp-resilient-peer-sessions.rst":[{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"258223ababe440b87a2a160100bb54e63757ec9a","unresolved":true,"context_lines":[{"line_number":30,"context_line":"in a North/South communication, being a single point of vulnerability for the"},{"line_number":31,"context_line":"cloud operation."},{"line_number":32,"context_line":""},{"line_number":33,"context_line":"The current DRAgent reference design [1]_ using two separated FSMs is described"},{"line_number":34,"context_line":"below:"},{"line_number":35,"context_line":""},{"line_number":36,"context_line":"State Report FSM::"}],"source_content_type":"text/x-rst","patch_set":1,"id":"259a9b3d_ad535dda","line":33,"range":{"start_line":33,"start_character":62,"end_line":33,"end_character":66},"updated":"2023-10-30 14:25:03.000000000","message":"can You explain what FSMs are?","commit_id":"fd59bc8ded5aa317748af3b9f7be6ba3751f12e6"},{"author":{"_account_id":35432,"name":"Roberto Acosta","display_name":"rbartzen","email":"rbartzen@gmail.com","username":"rbartzen"},"change_message_id":"05a5d0ae186cc286bf24ecfa2f5cb37f99e167ba","unresolved":false,"context_lines":[{"line_number":30,"context_line":"in a North/South communication, being a single point of vulnerability for the"},{"line_number":31,"context_line":"cloud operation."},{"line_number":32,"context_line":""},{"line_number":33,"context_line":"The current DRAgent reference design [1]_ using two separated FSMs is described"},{"line_number":34,"context_line":"below:"},{"line_number":35,"context_line":""},{"line_number":36,"context_line":"State Report FSM::"}],"source_content_type":"text/x-rst","patch_set":1,"id":"58a77e1b_4ca52f9e","line":33,"range":{"start_line":33,"start_character":62,"end_line":33,"end_character":66},"in_reply_to":"259a9b3d_ad535dda","updated":"2023-10-30 18:56:34.000000000","message":"I changed the term FSM to \u0027periodic task\u0027 because it seems more in line with the flowchart explanation.","commit_id":"fd59bc8ded5aa317748af3b9f7be6ba3751f12e6"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"258223ababe440b87a2a160100bb54e63757ec9a","unresolved":true,"context_lines":[{"line_number":113,"context_line":""},{"line_number":114,"context_line":"This problem can be manifested in two different ways:"},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"* The first one: when the messaging service/RabbitMQ is offline and does not"},{"line_number":117,"context_line":"  respond for a long interval `AMQP server is unreachable` (note the timeouts"},{"line_number":118,"context_line":"  configured for Neutron agent_down); and then RMQ/RPC becomes active again."},{"line_number":119,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"e088d331_65035a08","line":116,"range":{"start_line":116,"start_character":2,"end_line":116,"end_character":16},"updated":"2023-10-30 14:25:03.000000000","message":"nitty nit: I don\u0027t think You really need this sentence, as well as the \"The second one\" below","commit_id":"fd59bc8ded5aa317748af3b9f7be6ba3751f12e6"},{"author":{"_account_id":35432,"name":"Roberto Acosta","display_name":"rbartzen","email":"rbartzen@gmail.com","username":"rbartzen"},"change_message_id":"05a5d0ae186cc286bf24ecfa2f5cb37f99e167ba","unresolved":false,"context_lines":[{"line_number":113,"context_line":""},{"line_number":114,"context_line":"This problem can be manifested in two different ways:"},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"* The first one: when the messaging service/RabbitMQ is offline and does not"},{"line_number":117,"context_line":"  respond for a long interval `AMQP server is unreachable` (note the timeouts"},{"line_number":118,"context_line":"  configured for Neutron agent_down); and then RMQ/RPC becomes active again."},{"line_number":119,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a67dc9d_c470c3b8","line":116,"range":{"start_line":116,"start_character":2,"end_line":116,"end_character":16},"in_reply_to":"e088d331_65035a08","updated":"2023-10-30 18:56:34.000000000","message":"Makes sense to me, thanks!","commit_id":"fd59bc8ded5aa317748af3b9f7be6ba3751f12e6"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"258223ababe440b87a2a160100bb54e63757ec9a","unresolved":true,"context_lines":[{"line_number":162,"context_line":"* Cache timeout task: if another `revived` or `Exception` event occurs during"},{"line_number":163,"context_line":"  the timer count, the cache task must reset the timeout interval count and"},{"line_number":164,"context_line":"  start again. Otherwise, the cache task must terminate at the expiry of the"},{"line_number":165,"context_line":"  configured timeout, and set the cache_timeout_state flag to False."},{"line_number":166,"context_line":""},{"line_number":167,"context_line":"DB Impact"},{"line_number":168,"context_line":"---------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"655adc5d_0b5395a3","line":165,"updated":"2023-10-30 14:25:03.000000000","message":"sorry, maybe I\u0027m missing something but when after those 3 cases really full sync should be run actually?","commit_id":"fd59bc8ded5aa317748af3b9f7be6ba3751f12e6"},{"author":{"_account_id":35432,"name":"Roberto Acosta","display_name":"rbartzen","email":"rbartzen@gmail.com","username":"rbartzen"},"change_message_id":"05a5d0ae186cc286bf24ecfa2f5cb37f99e167ba","unresolved":false,"context_lines":[{"line_number":162,"context_line":"* Cache timeout task: if another `revived` or `Exception` event occurs during"},{"line_number":163,"context_line":"  the timer count, the cache task must reset the timeout interval count and"},{"line_number":164,"context_line":"  start again. Otherwise, the cache task must terminate at the expiry of the"},{"line_number":165,"context_line":"  configured timeout, and set the cache_timeout_state flag to False."},{"line_number":166,"context_line":""},{"line_number":167,"context_line":"DB Impact"},{"line_number":168,"context_line":"---------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"cfa4f73f_c439994a","line":165,"in_reply_to":"655adc5d_0b5395a3","updated":"2023-10-30 18:56:34.000000000","message":"Yeap, definitely yes, I added a new paragraph to make this clear.","commit_id":"fd59bc8ded5aa317748af3b9f7be6ba3751f12e6"},{"author":{"_account_id":29074,"name":"Felix Huettner","email":"felix.huettner@digits.schwarz","username":"felix.huettner"},"change_message_id":"c0a7761528bb76c90c28580e472db45bd2d6f92f","unresolved":true,"context_lines":[{"line_number":111,"context_line":""},{"line_number":112,"context_line":"Unless a full configuration reset is requested, the DRAgent must keep the"},{"line_number":113,"context_line":"session with the BGP peer, even if the messaging service (RMQ) is offline."},{"line_number":114,"context_line":"Exceptions in RPC messages should not start a full sync unless it is requested"},{"line_number":115,"context_line":"after reestablishing communication with Neutron server."},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"This problem can be manifested in two different ways:"}],"source_content_type":"text/x-rst","patch_set":2,"id":"aca320d0_e264f6c8","line":114,"updated":"2023-11-08 13:57:57.000000000","message":"isn\u0027t the goal to not remove the bgp sessions instead of not doing a full sync?\nWhile that might be the same implementation wise its a different goal from my perspective","commit_id":"0c42ee66a51f58c2362aceb39c7f20e2fe7b986f"},{"author":{"_account_id":35432,"name":"Roberto Acosta","display_name":"rbartzen","email":"rbartzen@gmail.com","username":"rbartzen"},"change_message_id":"1f8aded95458112008cd3e39f5dcaaedee9985e4","unresolved":false,"context_lines":[{"line_number":111,"context_line":""},{"line_number":112,"context_line":"Unless a full configuration reset is requested, the DRAgent must keep the"},{"line_number":113,"context_line":"session with the BGP peer, even if the messaging service (RMQ) is offline."},{"line_number":114,"context_line":"Exceptions in RPC messages should not start a full sync unless it is requested"},{"line_number":115,"context_line":"after reestablishing communication with Neutron server."},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"This problem can be manifested in two different ways:"}],"source_content_type":"text/x-rst","patch_set":2,"id":"174b2882_cc58054f","line":114,"in_reply_to":"aca320d0_e264f6c8","updated":"2023-11-08 14:40:03.000000000","message":"The goal is both cases because: \n\n1) full resync could remove BGP peers [1] considering instabilities/inconsistencies in RPC responses via RMQ.\n2) Exceptions or timeouts (empty list) could remove the BGP speaker [1] or [2] considering instabilities/inconsistencies in RPC responses via RMQ.\n\nSo, the proposed change is \"keep the speaker settings and the BGP peer sessions in case of RPC Exceptions, and/or reestablishment of communication via RPC.\"\n\n[1] https://opendev.org/openstack/neutron-dynamic-routing/src/commit/00a83aa706225871fc9f3db5d79be324b4e84383/neutron_dynamic_routing/services/bgp/agent/bgp_dragent.py#L118\n[2] https://opendev.org/openstack/neutron-dynamic-routing/src/commit/00a83aa706225871fc9f3db5d79be324b4e84383/neutron_dynamic_routing/services/bgp/agent/bgp_dragent.py#L107","commit_id":"0c42ee66a51f58c2362aceb39c7f20e2fe7b986f"},{"author":{"_account_id":29074,"name":"Felix Huettner","email":"felix.huettner@digits.schwarz","username":"felix.huettner"},"change_message_id":"c0a7761528bb76c90c28580e472db45bd2d6f92f","unresolved":true,"context_lines":[{"line_number":131,"context_line":"To solve the problem described above, the proposal is to introduce a new"},{"line_number":132,"context_line":"speaker cache logic for the DRAgent can keep the speaker settings and the BGP"},{"line_number":133,"context_line":"peer sessions in case of RPC Exceptions, and/or reestablishment of"},{"line_number":134,"context_line":"communication via RPC."},{"line_number":135,"context_line":""},{"line_number":136,"context_line":"To enable the new DRAgent speaker cache mechanism, a new config option should"},{"line_number":137,"context_line":"be enabled via [BGP] section in bgp_dragent.ini file."}],"source_content_type":"text/x-rst","patch_set":2,"id":"0029ce76_40d16032","line":134,"updated":"2023-11-08 13:57:57.000000000","message":"would it maybe be easier to just not touch the existing state if we notice an exception or broken connection?\nThe we could skip all the caching logic","commit_id":"0c42ee66a51f58c2362aceb39c7f20e2fe7b986f"},{"author":{"_account_id":35432,"name":"Roberto Acosta","display_name":"rbartzen","email":"rbartzen@gmail.com","username":"rbartzen"},"change_message_id":"1f8aded95458112008cd3e39f5dcaaedee9985e4","unresolved":false,"context_lines":[{"line_number":131,"context_line":"To solve the problem described above, the proposal is to introduce a new"},{"line_number":132,"context_line":"speaker cache logic for the DRAgent can keep the speaker settings and the BGP"},{"line_number":133,"context_line":"peer sessions in case of RPC Exceptions, and/or reestablishment of"},{"line_number":134,"context_line":"communication via RPC."},{"line_number":135,"context_line":""},{"line_number":136,"context_line":"To enable the new DRAgent speaker cache mechanism, a new config option should"},{"line_number":137,"context_line":"be enabled via [BGP] section in bgp_dragent.ini file."}],"source_content_type":"text/x-rst","patch_set":2,"id":"cffd3334_04e29554","line":134,"in_reply_to":"0029ce76_40d16032","updated":"2023-11-08 14:40:03.000000000","message":"It could be a good alternative, but we would need a cache timeout timer anyway, since after reconnecting with the RMQ, the messages received may be inconsistent until the cluster is operating correctly.\n\nI can change the spec to: \n1) block the sync when a failure is observed (I need to see how to do this because oslo_messaging catch and handle the exceptions...)\n2) start the timer when the connection with the RMQ is reestablished\n3) Release the sync after the cache timeout expires.\n\nDoes it make sense to you?","commit_id":"0c42ee66a51f58c2362aceb39c7f20e2fe7b986f"},{"author":{"_account_id":35432,"name":"Roberto Acosta","display_name":"rbartzen","email":"rbartzen@gmail.com","username":"rbartzen"},"change_message_id":"5ca2a8003e832a228b254abc788e326b0717d2d8","unresolved":false,"context_lines":[{"line_number":131,"context_line":"To solve the problem described above, the proposal is to introduce a new"},{"line_number":132,"context_line":"speaker cache logic for the DRAgent can keep the speaker settings and the BGP"},{"line_number":133,"context_line":"peer sessions in case of RPC Exceptions, and/or reestablishment of"},{"line_number":134,"context_line":"communication via RPC."},{"line_number":135,"context_line":""},{"line_number":136,"context_line":"To enable the new DRAgent speaker cache mechanism, a new config option should"},{"line_number":137,"context_line":"be enabled via [BGP] section in bgp_dragent.ini file."}],"source_content_type":"text/x-rst","patch_set":2,"id":"fded0d11_a075d9ba","line":134,"in_reply_to":"6664b1f7_58fdd713","updated":"2023-11-08 22:06:52.000000000","message":"Just to give some context, from the oslo_messaging documentation, it doesn\u0027t seem possible to know when the RMQ is offline or comes back because it\u0027s internal to impl_rabbit driver. So this alternative solution to monitor the RMQ connection to block/unblock the BGP sync may not seem feasible.","commit_id":"0c42ee66a51f58c2362aceb39c7f20e2fe7b986f"},{"author":{"_account_id":29074,"name":"Felix Huettner","email":"felix.huettner@digits.schwarz","username":"felix.huettner"},"change_message_id":"ed03a2eb626faa3b25ba8d5a01200cb1f30214e7","unresolved":true,"context_lines":[{"line_number":131,"context_line":"To solve the problem described above, the proposal is to introduce a new"},{"line_number":132,"context_line":"speaker cache logic for the DRAgent can keep the speaker settings and the BGP"},{"line_number":133,"context_line":"peer sessions in case of RPC Exceptions, and/or reestablishment of"},{"line_number":134,"context_line":"communication via RPC."},{"line_number":135,"context_line":""},{"line_number":136,"context_line":"To enable the new DRAgent speaker cache mechanism, a new config option should"},{"line_number":137,"context_line":"be enabled via [BGP] section in bgp_dragent.ini file."}],"source_content_type":"text/x-rst","patch_set":2,"id":"6664b1f7_58fdd713","line":134,"in_reply_to":"cffd3334_04e29554","updated":"2023-11-08 14:52:31.000000000","message":"sounds valid.\nI\u0027m not sure if oslo messaging includes a \"sender\" time in the messages. If that would be the case then we could just drop all messages before the reconnect and do a full sync","commit_id":"0c42ee66a51f58c2362aceb39c7f20e2fe7b986f"},{"author":{"_account_id":29074,"name":"Felix Huettner","email":"felix.huettner@digits.schwarz","username":"felix.huettner"},"change_message_id":"dd07ac64fc11e9dada1927d8aeaa6f0a83721186","unresolved":false,"context_lines":[{"line_number":131,"context_line":"To solve the problem described above, the proposal is to introduce a new"},{"line_number":132,"context_line":"speaker cache logic for the DRAgent can keep the speaker settings and the BGP"},{"line_number":133,"context_line":"peer sessions in case of RPC Exceptions, and/or reestablishment of"},{"line_number":134,"context_line":"communication via RPC."},{"line_number":135,"context_line":""},{"line_number":136,"context_line":"To enable the new DRAgent speaker cache mechanism, a new config option should"},{"line_number":137,"context_line":"be enabled via [BGP] section in bgp_dragent.ini file."}],"source_content_type":"text/x-rst","patch_set":2,"id":"461cfbce_0f0028d9","line":134,"in_reply_to":"fded0d11_a075d9ba","updated":"2023-11-09 10:15:55.000000000","message":"ok, thats unfortunate","commit_id":"0c42ee66a51f58c2362aceb39c7f20e2fe7b986f"},{"author":{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},"change_message_id":"d26bcba6afeccef32b8e2d3057df0785ba4c85af","unresolved":true,"context_lines":[{"line_number":23,"context_line":"Problem Description"},{"line_number":24,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":25,"context_line":""},{"line_number":26,"context_line":"When we are using dynamic routing with BPG to advertise network address"},{"line_number":27,"context_line":"prefixes in a cloud infrastructure, all the network traffic depends on the"},{"line_number":28,"context_line":"correct operation by the BGP peer elements. The DRAgent has a crucial role in"},{"line_number":29,"context_line":"that scenario because this service is responsible for advirtise all L3 prefixes"}],"source_content_type":"text/x-rst","patch_set":3,"id":"29cfff46_a06eb2c1","line":26,"range":{"start_line":26,"start_character":39,"end_line":26,"end_character":42},"updated":"2023-11-10 14:43:15.000000000","message":"s/BGP","commit_id":"a6a7ff31fad0d860625da995c53f77bfe8b7cb6f"},{"author":{"_account_id":35432,"name":"Roberto Acosta","display_name":"rbartzen","email":"rbartzen@gmail.com","username":"rbartzen"},"change_message_id":"afde73dd8aeb0d0bddc0d6f5f06032e453b60f5e","unresolved":false,"context_lines":[{"line_number":23,"context_line":"Problem Description"},{"line_number":24,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":25,"context_line":""},{"line_number":26,"context_line":"When we are using dynamic routing with BPG to advertise network address"},{"line_number":27,"context_line":"prefixes in a cloud infrastructure, all the network traffic depends on the"},{"line_number":28,"context_line":"correct operation by the BGP peer elements. The DRAgent has a crucial role in"},{"line_number":29,"context_line":"that scenario because this service is responsible for advirtise all L3 prefixes"}],"source_content_type":"text/x-rst","patch_set":3,"id":"def0db53_b927b350","line":26,"range":{"start_line":26,"start_character":39,"end_line":26,"end_character":42},"in_reply_to":"29cfff46_a06eb2c1","updated":"2023-11-24 19:58:15.000000000","message":"Done","commit_id":"a6a7ff31fad0d860625da995c53f77bfe8b7cb6f"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"0a965d303dd1ce0118ea7fc121f03b28d0ddbc64","unresolved":true,"context_lines":[{"line_number":149,"context_line":"as described below:"},{"line_number":150,"context_line":""},{"line_number":151,"context_line":"* State Report periodic task: with the `revived` RPC status, the DRAgent must"},{"line_number":152,"context_line":"  be start the cache timeout timer, and set the cache_timeout_state flag as"},{"line_number":153,"context_line":"  True. If the DRAgent performs the sync_state method before the"},{"line_number":154,"context_line":"  cache_timeout_state becomes to False, then the full sync process must be"},{"line_number":155,"context_line":"  ignored, and wait for the next periodic check."}],"source_content_type":"text/x-rst","patch_set":3,"id":"0f264f47_88693c1d","line":152,"range":{"start_line":152,"start_character":48,"end_line":152,"end_character":67},"updated":"2023-11-15 13:11:26.000000000","message":"Two notes on this:\n\n1) When implementing this please make sure that this internal state is observable through log messages even on the default log level.\n\n2) Maybe consider a different name like \"speaker_cache_stale \u003d True/False\" or \"speaker_cache_out_of_sync\". I\u0027m hoping this makes it more self-explanatory what this state is.","commit_id":"a6a7ff31fad0d860625da995c53f77bfe8b7cb6f"},{"author":{"_account_id":35432,"name":"Roberto Acosta","display_name":"rbartzen","email":"rbartzen@gmail.com","username":"rbartzen"},"change_message_id":"afde73dd8aeb0d0bddc0d6f5f06032e453b60f5e","unresolved":false,"context_lines":[{"line_number":149,"context_line":"as described below:"},{"line_number":150,"context_line":""},{"line_number":151,"context_line":"* State Report periodic task: with the `revived` RPC status, the DRAgent must"},{"line_number":152,"context_line":"  be start the cache timeout timer, and set the cache_timeout_state flag as"},{"line_number":153,"context_line":"  True. If the DRAgent performs the sync_state method before the"},{"line_number":154,"context_line":"  cache_timeout_state becomes to False, then the full sync process must be"},{"line_number":155,"context_line":"  ignored, and wait for the next periodic check."}],"source_content_type":"text/x-rst","patch_set":3,"id":"44a819ac_8fc7cc0c","line":152,"range":{"start_line":152,"start_character":48,"end_line":152,"end_character":67},"in_reply_to":"0f264f47_88693c1d","updated":"2023-11-24 19:58:15.000000000","message":"Thanks for the review Bence.\n\n1) Sure, I\u0027ll implement it this way.\n\n2) It makes sense to me, I\u0027ll change it as suggested. Thanks","commit_id":"a6a7ff31fad0d860625da995c53f77bfe8b7cb6f"},{"author":{"_account_id":8313,"name":"Lajos Katona","display_name":"lajoskatona","email":"katonalala@gmail.com","username":"elajkat","status":"Ericsson Software Technology"},"change_message_id":"d1645e62d9b9cb7fc1769ffa2d4957e83175575c","unresolved":true,"context_lines":[{"line_number":22,"context_line":""},{"line_number":23,"context_line":"Problem Description"},{"line_number":24,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":25,"context_line":""},{"line_number":26,"context_line":"When we are using dynamic routing with BGP to advertise network address"},{"line_number":27,"context_line":"prefixes in a cloud infrastructure, all the network traffic depends on the"},{"line_number":28,"context_line":"correct operation by the BGP peer elements. The DRAgent has a crucial role in"}],"source_content_type":"text/x-rst","patch_set":5,"id":"9d39456b_b92e8376","line":25,"updated":"2024-01-23 09:56:17.000000000","message":"very good summary of the current situation, thanks","commit_id":"3d2708ffddab3aa62946c739a7c9f4e25fab9a75"},{"author":{"_account_id":35432,"name":"Roberto Acosta","display_name":"rbartzen","email":"rbartzen@gmail.com","username":"rbartzen"},"change_message_id":"e1fe193c93a4792e0f38665bf3020fe07840a89b","unresolved":false,"context_lines":[{"line_number":22,"context_line":""},{"line_number":23,"context_line":"Problem Description"},{"line_number":24,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":25,"context_line":""},{"line_number":26,"context_line":"When we are using dynamic routing with BGP to advertise network address"},{"line_number":27,"context_line":"prefixes in a cloud infrastructure, all the network traffic depends on the"},{"line_number":28,"context_line":"correct operation by the BGP peer elements. The DRAgent has a crucial role in"}],"source_content_type":"text/x-rst","patch_set":5,"id":"e8b238db_026dac88","line":25,"in_reply_to":"9d39456b_b92e8376","updated":"2024-01-24 12:13:51.000000000","message":"Thanks for your feedback ;)","commit_id":"3d2708ffddab3aa62946c739a7c9f4e25fab9a75"},{"author":{"_account_id":8313,"name":"Lajos Katona","display_name":"lajoskatona","email":"katonalala@gmail.com","username":"elajkat","status":"Ericsson Software Technology"},"change_message_id":"d1645e62d9b9cb7fc1769ffa2d4957e83175575c","unresolved":true,"context_lines":[{"line_number":30,"context_line":"in a North/South communication, being a single point of vulnerability for the"},{"line_number":31,"context_line":"cloud operation."},{"line_number":32,"context_line":""},{"line_number":33,"context_line":"The current DRAgent reference design [1]_ using two separated periodic tasks is"},{"line_number":34,"context_line":"described below:"},{"line_number":35,"context_line":""},{"line_number":36,"context_line":"State Report periodic task (DrAgentWithStateReport class)::"}],"source_content_type":"text/x-rst","patch_set":5,"id":"547e6e4d_94e7e2d2","line":33,"range":{"start_line":33,"start_character":77,"end_line":33,"end_character":79},"updated":"2024-01-23 09:56:17.000000000","message":"nit: is -\u003e as (if my poor English is correct)","commit_id":"3d2708ffddab3aa62946c739a7c9f4e25fab9a75"},{"author":{"_account_id":35432,"name":"Roberto Acosta","display_name":"rbartzen","email":"rbartzen@gmail.com","username":"rbartzen"},"change_message_id":"e1fe193c93a4792e0f38665bf3020fe07840a89b","unresolved":false,"context_lines":[{"line_number":30,"context_line":"in a North/South communication, being a single point of vulnerability for the"},{"line_number":31,"context_line":"cloud operation."},{"line_number":32,"context_line":""},{"line_number":33,"context_line":"The current DRAgent reference design [1]_ using two separated periodic tasks is"},{"line_number":34,"context_line":"described below:"},{"line_number":35,"context_line":""},{"line_number":36,"context_line":"State Report periodic task (DrAgentWithStateReport class)::"}],"source_content_type":"text/x-rst","patch_set":5,"id":"20720763_916ed625","line":33,"range":{"start_line":33,"start_character":77,"end_line":33,"end_character":79},"in_reply_to":"547e6e4d_94e7e2d2","updated":"2024-01-24 12:13:51.000000000","message":"You\u0027re right, thank you!","commit_id":"3d2708ffddab3aa62946c739a7c9f4e25fab9a75"}]}