Bug 1772594
Summary: | [3.11] egressnetworkpolicy with dnsname has performance impact due to calling dig often | ||
---|---|---|---|
Product: | OpenShift Container Platform | Reporter: | Juan Luis de Sousa-Valadas <jdesousa> |
Component: | Networking | Assignee: | Juan Luis de Sousa-Valadas <jdesousa> |
Networking sub component: | openshift-sdn | QA Contact: | huirwang |
Status: | CLOSED ERRATA | Docs Contact: | |
Severity: | high | ||
Priority: | high | CC: | agomezpr, bbennett, bretm, fgrosjea, jstrong, ksalunkh, mpatercz, nchavan, sferguso |
Version: | 3.11.0 | ||
Target Milestone: | --- | ||
Target Release: | 3.11.z | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: |
Cause: DNS Names are present in each EgressNetworkPolicy they are defined as a part of. When the DNS records for a given network policy are refreshed, the current code calls dig irrespective of whether that particular DNS record has been refreshed as a virtue of the same DNS Name being present in another EgressNetworkPolicy.
Consequence: If the same DNS Name is present in multiple egress network policies, at scale, we will end up calling DIG too often.
Fix: Make the querying of DNS records based on uniqueness of DNS names rather than for each EgressNetworkPolicy
Result: DNS records are queried only once uniquely no matter how many EgressNetworkPolicy objects they belong to. This significantly improves the performance of the queries.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2020-05-28 05:44:13 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 1684079 | ||
Bug Blocks: |
Description
Juan Luis de Sousa-Valadas
2019-11-14 17:19:49 UTC
Hello, As the status of bugzilla is in POST what is the ETA of getting it shipped with the errata. There is no ETA. I need to know if we are merging the 4.1 first, and then there are a couple issues with this backport which I have to fix. Once it's fixed it needs to be approved, cherry-picked, verified by QA and finally released. So counting all this no less than 1 month. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:2215 |