)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"change_message_id":"1bec1127d10604ce2d7310cf6728a65934061461","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":4,"id":"ac28bf65_f164e830","updated":"2022-04-26 22:25:46.000000000","message":"So digging back through the rsyslog mailing list, this changed in 2020, about a year after the log offloading patch was added to Octavia. I guess local queuing is no longer an option.","commit_id":"911300d688c75ca0f2367fca23251f084d6f223e"}],"doc/source/admin/log-offloading.rst":[{"author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"change_message_id":"1bf7a641f05ba4b3c7d526f3f8b4d6276e1101b3","unresolved":true,"context_lines":[{"line_number":222,"context_line":"Also pay attention to the *log_retry_count* and *log_retry_interval* settings"},{"line_number":223,"context_line":"when using multiple log targets. You might want to set *log_retry_count* to 0"},{"line_number":224,"context_line":"and use a higher value for *log_retry_interval*. Values up to 1800 (30 minutes)"},{"line_number":225,"context_line":"are possible."},{"line_number":226,"context_line":"That way the failover will happen immediately after the client detects"},{"line_number":227,"context_line":"that the server became unavailable. In such case, that server won\u0027t be"},{"line_number":228,"context_line":"used again for at least *log_retry_interval* seconds after that event."}],"source_content_type":"text/x-rst","patch_set":4,"id":"8176a516_53473ef6","line":225,"updated":"2022-03-11 16:16:30.000000000","message":"So previously the amphora rsyslog would buffer up to a certain number of messages before failing over to the other server, does the amp continue to buffer messages locally? If so, under what conditions?","commit_id":"911300d688c75ca0f2367fca23251f084d6f223e"},{"author":{"_account_id":34429,"name":"Tom Weininger","email":"dienste@weinimo.de","username":"tweining"},"change_message_id":"8fd17f9776bf28ed38c309ae748b6bf24e74404c","unresolved":false,"context_lines":[{"line_number":222,"context_line":"Also pay attention to the *log_retry_count* and *log_retry_interval* settings"},{"line_number":223,"context_line":"when using multiple log targets. You might want to set *log_retry_count* to 0"},{"line_number":224,"context_line":"and use a higher value for *log_retry_interval*. Values up to 1800 (30 minutes)"},{"line_number":225,"context_line":"are possible."},{"line_number":226,"context_line":"That way the failover will happen immediately after the client detects"},{"line_number":227,"context_line":"that the server became unavailable. In such case, that server won\u0027t be"},{"line_number":228,"context_line":"used again for at least *log_retry_interval* seconds after that event."}],"source_content_type":"text/x-rst","patch_set":4,"id":"be744f28_266907e4","line":225,"in_reply_to":"8176a516_53473ef6","updated":"2022-03-14 09:42:52.000000000","message":"Before the change https://review.opendev.org/c/openstack/octavia/+/831203 rsyslog failover was broken in the amp. With UDP it would just never fail over and with TCP the previous rsyslog configuration generated by Octavia did not work with multiple servers (https://storyboard.openstack.org/#!/story/2009876). Rsyslog clients do not support the \"one queue per action\" configuration like it was before. See https://www.rsyslog.com/doc/master/tutorials/failover_syslog_server.html.\n\nRegarding buffering: The queues are still there and buffer messages. Failover does not depend on how many messages are in the queues, but on the number of \"connection refused\" errors the client sees. log_retry_interval defines after which time interval a failed server gets tried again. Buffering itself works like before.","commit_id":"911300d688c75ca0f2367fca23251f084d6f223e"},{"author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"change_message_id":"d6940f5b1a3750a8e4d4fe0bc39a99881412a594","unresolved":false,"context_lines":[{"line_number":222,"context_line":"Also pay attention to the *log_retry_count* and *log_retry_interval* settings"},{"line_number":223,"context_line":"when using multiple log targets. You might want to set *log_retry_count* to 0"},{"line_number":224,"context_line":"and use a higher value for *log_retry_interval*. Values up to 1800 (30 minutes)"},{"line_number":225,"context_line":"are possible."},{"line_number":226,"context_line":"That way the failover will happen immediately after the client detects"},{"line_number":227,"context_line":"that the server became unavailable. In such case, that server won\u0027t be"},{"line_number":228,"context_line":"used again for at least *log_retry_interval* seconds after that event."}],"source_content_type":"text/x-rst","patch_set":4,"id":"512e0573_573c1f20","line":225,"in_reply_to":"be744f28_266907e4","updated":"2022-04-26 22:15:26.000000000","message":"No, that is my point and concern here. This did work and was taken directly from the rsyslog documentation, so I\u0027m a bit concerned that there is a major change in behavior here.\nObviously UDP could not fail over, and this was documented in the previous version. But TCP supported server failover and with buffering.\nSomething has changed here that is confusing.","commit_id":"911300d688c75ca0f2367fca23251f084d6f223e"}]}