SPK Fixes and Known IssuesΒΆ
This list highlights fixes and known issues for this SPK release.
Version: 1.7.12
Build: 1.7.12
Note: This content is current as of the software release date
Updates to bug information occur periodically. For the most up-to-date bug data, see Bug Tracker.
| ID Number | Severity | Links to More Info | Description |
| 1584457-2 | 2-Critical | BT1584457 | F5SPKIngressHTTP2 does not handle deployment scale-down or f5-tmm scale-up |
| 1624825 | 2-Critical | Helm rollback does not revert dSSM pods to the previous version. | |
| 1294277-1 | 3-Major | The external session database is encountering an error during Lua script execution when provided with incorrect input arguments. | |
| 1622705-1 | 1-Blocking | Resolved BGP Neighborship Flapping Due to Link State Polling Overload | |
| 1670313 | 3-Major | BT1670313 | Missing self IP mappings in the ConfigMap used for persistence by the control plane (F5ingress Controller) |
Cumulative fix details for SPK v1.7.12 that are included in this release
1584457-2 : F5SPKIngressHTTP2 does not handle deployment scale-down or f5-tmm scale-up
Links to More Info: BT1584457
Component: SPK
Symptoms:
When an F5SPKIngressHTTP2 Custom Resource instance is configured for a service, if the deployment(s) for that service are scaled down, the configuration remains in the f5-tmm. Additionally, if the f5-tmm is scaled up, the configuration is not applied to new f5-tmm pods.
Conditions:
- F5SPKIngressHTTP2 Custom Resource is configured to use one or more services.
- The deployment(s) in one or more services are scaled down
or
- The f5-tmm deployment(s) are scaled up.
Impact:
In the application deployment scale-down scenario, the f5-tmm will attempt to send traffic to deployments that no longer exist, and static routes will remain in the f5-tmm. In the f5-tmm scale-up scenario, only the f5-tmm pods present at the time of F5SPKIngressHTTP2 CR creation will handle traffic.
Workaround:
Options:
1. Remove the F5SPKIngressHTTP2 CR prior to scaling down the deployment(s) and then reapply the CR once completed
2. In case the deployment has already been scaled down, scale the f5-tmm deployment to zero and then increase it again.
3. When you want to scale-up f5-tmm, scale it up as needed, and then remove and reapply the F5SPKIngressHTTP2 CR(s).
Fix:
The SPK Handler for F5SPKIngressHTTP2 CR now properly manages the deployments scale-down and the scale-up of f5-tmm.
Summary of Code Level Changes:
Updated Ingress HTTP2 config template to properly scale down pool members. Also updated Ingress HTTP2 config handler logic for cases where multiple services are scaled/updated/created at the same time.
1624825 : Helm rollback does not revert dSSM pods to the previous version.
Component: SPK
Symptoms:
The dSSM pods do not revert to the previous version when you perform helm rollback.
helm rollback f5-dssm 1 -n dav9-f5-spk
Conditions:
The problem arises when you attempt to use Helm to rollback the dSSM pods.
Impact:
During a Helm rollback, dSSM pods will not go back to the previous version. This means that the pods will remain on the current version and continue to run.
Workaround:
None
Fix:
Previously, the upgrade hook was not executing during a rollback. This has been fixed to ensure that the upgrade hook now runs during Helm rollbacks as well.
Summary of Code Level Changes:
Implementing a fix to ensure the update hook runs during a rollback, just like it does during an upgrade.
1294277-1 : The external session database is encountering an error during Lua script execution when provided with incorrect input arguments.
Component: SPK
Symptoms:
Session requests are not being fulfilled due to an error in the Lua script.
Conditions:
This problem occurs when you use a Lua script with a Boolean or nil values.
Impact:
Session requests to the Redis server result in errors.
Workaround:
None
Fix:
Implemented a string check in the string.sub command before execution in all Lua scripts.
Summary of Code Level Changes:
Modules/component(s) that are updated: tmm - added check to enforce string check before string.sub command evaluation inside all Lua scripts
1622705-1 : Resolved BGP Neighborship Flapping Due to Link State Polling Overload
Component: SPK
Symptoms:
If one of the two TMM pods stops running, the BGP neighborship flaps due to frequent link state polling, which requires multiple system calls.
Conditions:
Repeatedly calling dpdk_get_link_state() using rte_eth_link_get() would directly utilize NIC registers to verify the link status, resulting in several ioctl() system calls. These system calls could sometimes take longer than expected, causing a possible decline in performance.
Impact:
Performance
Workaround:
None
Fix:
Enable interrupt-based link status control that allows the rte_eth_link_get() in reading the link status from a global structure rather than directly accessing the NIC registers. This change eliminates the need for repeated ioctl() system calls, improving system efficiency and reducing latency in link status updates.
Summary of Code Level Changes:
This change enables Interrupt Link Status Control to optimize the handling of link status updates within TMM when scaling pods, particularly during pod deletions and restarts. By enabling this control, the system will read link status from a global structure instead of accessing NIC registers directly with each call to rte_eth_link_get(). This change is expected to eliminate delays and reduce unnecessary BGP session flapping that occurs due to the overhead of syscalls when the TMM pod is restarted.
1670313 : Missing self IP mappings in the ConfigMap used for persistence by the control plane (F5ingress Controller)
Links to More Info: BT1670313
Component: SPK
Symptoms:
The ConfigMap utilized for persistence by the control plane (F5ingress Controller) does not have self IP mappings.
Conditions:
A simultaneous TMM scale-down and scale-up event occurs when one pod is in the deletion state while another pod is starting up.
Impact:
A simultaneous TMM scale-down and scale-up event may occur when one pod is in the deletion state while another pod is starting up. During this process, the control plane may attempt to assign self IPs to the new TMMs but could accidentally reuse IPs already assigned to other TMMs, leading to traffic disruptions.
Workaround:
Update the ConfigMap to match the self IP assignments on the TMMs and restart the F5ingress pod. Note that F5 has provided a cron script to detect such issues in user environments and take preventive action when possible.
Fix:
The SPK v1.7.12 release incorporates a design modification that offers a lasting solution. This solution involves using TMM to assign TMM-specific configurations (such as selfIP) through a feedback system, eliminating the need for the ConfigMap. TMM will serve as the sole source of truth for configuration assignments, addressing concurrent access issues
Summary of Code Level Changes:
Modules/component(s) that are updated: f5ingress
Known Issues in SPK v1.7.12
SPK Issues
| ID Number | Severity | Links to More Info | Description |
| 1708381-1 | 2-Critical | BGP Neighbor Flapping During Helm App Installation | |
| 1672985-1 | 3-Major | The F5IngressEgressUDP CRD has additional fields that are not used. | |
| 1730993-1 | 3-Major | F5SPKIngressTCP CR status remains unchanged when referenced VLAN CR is deleted |
Known Issue details for SPK v1.7.12
1708381-1 : BGP Neighbor Flapping During Helm App Installation
Component: SPK
Symptoms:
When the application is installed using Helm, BGP neighbors flap, causing learned routes to be deleted. Once the BGP neighbors reconnect (typically within 3-6 seconds), the routes are re-added.
Conditions:
This issue occurs when you install the app using Helm with BGP neighbor configuration
Impact:
BGP neighbors disconnect and then reconnect within 3-6 seconds.
Workaround:
Add BGP graceful restart to the address family configuration (such as IPv4 or IPv6)
1672985-1 : The F5IngressEgressUDP CRD has additional fields that are not used.
Component: SPK
Symptoms:
The F5IngressEgressUDP CRD contains a "monitors" section that is currently not used.
Conditions:
An F5IngressEgressUDP Custom Resource is deployed with monitors configured.
Impact:
There are no monitors created based on the configuration in the F5IngressEgressUDP custom resource.
Workaround:
None
1730993-1 : F5SPKIngressTCP CR status remains unchanged when referenced VLAN CR is deleted
Component: SPK
Symptoms:
F5SPKIngressTCP CR does not change its status to 'WAITING' when the referenced VLAN CR is deleted.
Conditions:
When you configure the F5SPKIngressTCP CR with one or more VLANs and their corresponding VLAN CRs, the status of the F5SPKIngressTCP CR should change to "WAITING" if:
1. Any of the specified VLAN CRs are missing.
2. Any of the VLAN CRs that were initially set up are later removed.
However, in the second scenario, the status remains incorrectly reflected as "SUCCESS" instead of switching to "WAITING."
Impact:
Users do not receive appropriate feedback regarding the missing child CR; however, there is no traffic disruption once the VLAN CR is restored.
For additional support resources and technical documentation, see:
- The F5 Technical Support website: http://www.f5.com/support/
- The MyF5 website: https://my.f5.com/manage/s/
- The F5 DevCentral website: http://devcentral.f5.com/