Back to bug 2213126
| Who | When | What | Removed | Added |
|---|---|---|---|---|
| Eran Kuris | 2023-06-07 07:40:24 UTC | Status | NEW | ON_QA |
| Eran Kuris | 2023-06-07 07:40:46 UTC | Doc Type | If docs needed, set a value | Known Issue |
| Maor | 2023-06-07 07:57:12 UTC | Doc Text | Cause: Seems to originate from OVN, being checked. Consequence: Burst limit used in short time, for example 1 second, may not limit accurately, results in lower packet amount limit than expected. Notice that combination of burst limit and rate limit over longer periods of time, for example 1 minute, results in expected packet limit. Workaround (if any): Increase the configured burst limit until expected value reached when tested, so far the result was around 1/3 of the configured value. Result: |
|
| Red Hat One Jira (issues.redhat.com) | 2023-06-07 07:58:34 UTC | Link ID | Red Hat Issue Tracker OSP-25666 | |
| Maor | 2023-06-07 08:01:51 UTC | QA Contact | ekuris | mblue |
| Terry Wilson | 2023-06-08 13:44:31 UTC | CC | twilson | |
| Jenny-Anne Lynch | 2023-06-08 14:03:02 UTC | CC | jelynch | |
| Flags | needinfo?(mblue) | |||
| James Smith | 2023-06-09 04:08:00 UTC | Flags | needinfo?(mblue) needinfo?(egarciar) | |
| CC | jamsmith | |||
| Doc Text | Cause: Seems to originate from OVN, being checked. Consequence: Burst limit used in short time, for example 1 second, may not limit accurately, results in lower packet amount limit than expected. Notice that combination of burst limit and rate limit over longer periods of time, for example 1 minute, results in expected packet limit. Workaround (if any): Increase the configured burst limit until expected value reached when tested, so far the result was around 1/3 of the configured value. Result: | The logging burst limit function used to manage the transmission of security group logging data does not always work as expected. + When you set `NeutronOVNLoggingBurstLimit` to a low value such as 1 second, the actual packet queue limit might be lower than expected. + The problem does not manifest when you set the parameter to a higher value, such as 60 seconds. + For more accurate and predictable results, increase the value of `NeutronOVNLoggingBurstLimit` and test until the actual results match the expected value. |
||
| Maor | 2023-06-12 08:05:56 UTC | Flags | needinfo?(mblue) needinfo?(mblue) | |
| Elvira | 2023-06-12 14:29:48 UTC | Flags | needinfo?(egarciar) | |
| Elvira | 2023-06-12 15:02:53 UTC | Keywords | Tracking, Triaged | |
| Assignee | rhos-maint | egarciar | ||
| Component | python-networking-ovn | openstack-neutron | ||
| CC | chrisw | |||
| Target Milestone | --- | ga | ||
| Status | ON_QA | NEW | ||
| Gregory Thiemonge | 2023-06-12 15:04:40 UTC | CC | gthiemon | |
| Maor | 2023-06-12 15:42:38 UTC | Keywords | Tracking, Triaged | |
| Status | NEW | ON_QA | ||
| Target Milestone | ga | --- | ||
| Component | openstack-neutron | python-networking-ovn | ||
| Assignee | egarciar | rhos-maint | ||
| Maor | 2023-06-12 15:44:16 UTC | QA Contact | mblue | ekuris |
| Component | python-networking-ovn | openstack-neutron | ||
| Status | ON_QA | NEW | ||
| Target Milestone | --- | ga | ||
| Maor | 2023-06-12 15:52:10 UTC | Keywords | Tracking, Triaged | |
| Maor | 2023-06-12 15:52:48 UTC | QA Contact | ekuris | mblue |
| Assignee | rhos-maint | egarciar | ||
| James Smith | 2023-06-13 16:37:04 UTC | Flags | needinfo?(egarciar) needinfo?(mblue) | |
| Maor | 2023-06-14 09:26:19 UTC | Flags | needinfo?(mblue) | |
| James Smith | 2023-06-14 11:20:35 UTC | Doc Text | The logging burst limit function used to manage the transmission of security group logging data does not always work as expected. + When you set `NeutronOVNLoggingBurstLimit` to a low value such as 1 second, the actual packet queue limit might be lower than expected. + The problem does not manifest when you set the parameter to a higher value, such as 60 seconds. + For more accurate and predictable results, increase the value of `NeutronOVNLoggingBurstLimit` and test until the actual results match the expected value. | The logging queue that buffers excess security group log packets sometimes stops accepting packets before the specified limit is reached. As a workaround, you can set the queue length higher than the number of packets you want it to hold. + You can set the maximum number of log packets per second with the parameter `NeutronOVNLoggingRateLimit`. If the log traffic exceeds that rate, the excess is buffered in a queue up to the number of log packets that you specify in `NeutronOVNLoggingBurstLimit`. + The problem is especially evident over short periods of time, such as 1 second. Over longer periods of time, such as 60 seconds, the rate limit is more influential and compensates for burst limit inaccuracy. + Workaround: set `NeutronOVNLoggingBurstLimit` at a higher value than the target value. Observe and adjust as needed. |
| Flags | needinfo?(mblue) needinfo?(egarciar) | |||
| Elvira | 2023-06-14 14:05:59 UTC | Flags | needinfo?(egarciar) needinfo?(egarciar) | |
| James Smith | 2023-06-14 16:01:23 UTC | Doc Text | The logging queue that buffers excess security group log packets sometimes stops accepting packets before the specified limit is reached. As a workaround, you can set the queue length higher than the number of packets you want it to hold. + You can set the maximum number of log packets per second with the parameter `NeutronOVNLoggingRateLimit`. If the log traffic exceeds that rate, the excess is buffered in a queue up to the number of log packets that you specify in `NeutronOVNLoggingBurstLimit`. + The problem is especially evident over short periods of time, such as 1 second. Over longer periods of time, such as 60 seconds, the rate limit is more influential and compensates for burst limit inaccuracy. + Workaround: set `NeutronOVNLoggingBurstLimit` at a higher value than the target value. Observe and adjust as needed. | The logging queue that buffers excess security group log entries sometimes stops accepting entries before the specified limit is reached. As a workaround, you can set the queue length higher than the number of entries you want it to hold. + You can set the maximum number of log entries per second with the parameter `NeutronOVNLoggingRateLimit`. If the log entry creation exceeds that rate, the excess is buffered in a queue up to the number of log entries that you specify in `NeutronOVNLoggingBurstLimit`. + The problem is especially evident in the first second of a burst. In longer bursts, such as 60 seconds, the rate limit is more influential and compensates for burst limit inaccuracy. Thus, the problem has the greatest proportional effect in short bursts. + Workaround: set `NeutronOVNLoggingBurstLimit` at a higher value than the target value. Observe and adjust as needed. |
| Maor | 2023-06-14 18:40:33 UTC | Flags | needinfo?(mblue) | |
| Jenny-Anne Lynch | 2023-06-15 16:06:00 UTC | Doc Text | The logging queue that buffers excess security group log entries sometimes stops accepting entries before the specified limit is reached. As a workaround, you can set the queue length higher than the number of entries you want it to hold. + You can set the maximum number of log entries per second with the parameter `NeutronOVNLoggingRateLimit`. If the log entry creation exceeds that rate, the excess is buffered in a queue up to the number of log entries that you specify in `NeutronOVNLoggingBurstLimit`. + The problem is especially evident in the first second of a burst. In longer bursts, such as 60 seconds, the rate limit is more influential and compensates for burst limit inaccuracy. Thus, the problem has the greatest proportional effect in short bursts. + Workaround: set `NeutronOVNLoggingBurstLimit` at a higher value than the target value. Observe and adjust as needed. | The logging queue that buffers excess security group log entries sometimes stops accepting entries before the specified limit is reached. As a workaround, you can set the queue length higher than the number of entries you want it to hold. + You can set the maximum number of log entries per second with the parameter `NeutronOVNLoggingRateLimit`. If the log entry creation exceeds that rate, the excess is buffered in a queue up to the number of log entries that you specify in `NeutronOVNLoggingBurstLimit`. + The issue is especially evident in the first second of a burst. In longer bursts, such as 60 seconds, the rate limit is more influential and compensates for burst limit inaccuracy. Thus, the issue has the greatest proportional effect in short bursts. + Workaround: Set `NeutronOVNLoggingBurstLimit` at a higher value than the target value. Observe and adjust as needed. |
| Maor | 2023-06-25 16:00:04 UTC | Flags | needinfo?(jamsmith) | |
| Eran Kuris | 2023-07-12 07:49:47 UTC | Target Milestone | ga | z1 |
| Severity | high | medium | ||
| Jenny-Anne Lynch | 2023-07-12 09:26:26 UTC | CC | jelynch | |
| Elvira | 2023-07-24 07:52:56 UTC | Keywords | TestOnly, Tracking | |
| Status | NEW | ASSIGNED | ||
| Summary | [OSP Tracker] OVN security group logging - burst limit unexpected value | OVN security group logging - burst limit unexpected value | ||
| RHEL Program Management | 2023-07-24 07:53:07 UTC | Target Release | --- | 17.1 |
| Ian Frangs | 2023-08-03 15:46:23 UTC | Flags | needinfo?(egarciar) | |
| Elvira | 2023-08-04 13:57:29 UTC | Flags | needinfo?(egarciar) | |
| Mike Burns | 2023-08-11 13:59:33 UTC | Target Milestone | z1 | z2 |
| Mike Burns | 2023-08-11 15:01:36 UTC | Target Milestone | z2 | z1 |
| Paul Grist | 2023-08-14 13:46:08 UTC | CC | pgrist |
Back to bug 2213126