Bug 1940272 - [DDF] DNS resolving is very slow with the procedure of "Deploying Internal DNS with OVN"
Summary: [DDF] DNS resolving is very slow with the procedure of "Deploying Internal DN...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: documentation
Version: 16.1 (Train)
Hardware: All
OS: All
medium
unspecified
Target Milestone: ---
: ---
Assignee: Greg Rakauskas
QA Contact: RHOS Documentation Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-03-18 01:59 UTC by Direct Docs Feedback
Modified: 2024-10-17 07:56 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-10-04 20:41:45 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker OSP-588 0 None None None 2022-03-24 14:29:11 UTC

Description Direct Docs Feedback 2021-03-18 01:59:32 UTC
DNS resolving is very slow with the procedure of "Deploying Internal DNS with OVN"

I tested "Deploying Internal DNS with OVN" with following the procedure. It looks work but it's very slow to resolve the instance name. It takes 20~60 sec.

However, when I added the gateway as DNS server to the subnet, it has been improved to less than 1 sec.
And, I'm wondering if this is the proper setting for this feature.


Anyway, I think the document is not sufficient to use this internal DNS feature because it's too slow to use it.


Reported by: rhn-support-migawa

https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.1/html/networking_with_open_virtual_network/deploying-dvr-ovn#annotations:dd8d2208-21a4-4a47-8095-664b6129c813

Comment 11 Greg Rakauskas 2022-10-04 20:41:45 UTC
Hi,

Based on Eduardo's conclusion at the end of Comment 4, it sounds like there is
no action required for the RHOSP customer docs on this issue.

Therefore, I am closing this BZ.

If I have missed something, please comment and reopen this BZ.

Thanks,
--Greg

Comment 12 Masayuki Igawa 2022-10-05 00:10:49 UTC
Hi Greg,

Thank you for taking care of this.
I think it's OK to close this bug because we already opened the new bug BZ#1946662 to handle this issue.
And, I will create a KCS for it.

Best Regards,
-- Masayuki

Comment 13 Ihar Hrachyshka 2024-09-13 17:38:51 UTC
@Eduardo, @Greg, the OVN bug was closed, BUT: the new option for DNS record to "own" the domain should be set by CMS (or user). If we think that this should be the OVN ml2 driver behavior, then there's a missing piece - neutron ml2 driver integration to set the new option. Should we report a new Jira to track this work?

Comment 14 Greg Rakauskas 2024-09-16 17:38:32 UTC
Hi @Ihar,

Thanks for raising this issue. I would vote for working this into the ML2/OVN 
default behavior. One less knob for customers to turn for something that should
be already the default.

Best,
--Greg R.

Comment 15 Eduardo Olivares 2024-09-17 07:42:07 UTC
Hi Ihar and Greg,

After taking a look at the description of the core ovn's upstream patch [1], it seems to me the option `ovn-owned` should be set to True by default.
I am thinking about it and I can't see any case where setting it to True could be problematic.

On the other hand, this would be a change of behavior, hence, rather a (small) feature than a bug, right? We would need a few tests covering the new behavior (e.g. networks with both IPv4 and IPv6 subnets and networks with only one of them).

It would only go to RHOSO18? Or RHOSP17.1 too?

BR,
Eduardo

[1] https://patchwork.ozlabs.org/project/ovn/patch/20231001192704.3107450-1-mheib@redhat.com/

Comment 16 Ihar Hrachyshka 2024-10-14 20:40:19 UTC
I think we can start with a RHOSO 18 Jira and consider the complexity of the implementation for 17.x later. Would you mind reporting a Jira for this work to happen in neutron? Thanks.

Comment 17 Eduardo Olivares 2024-10-17 07:56:04 UTC
(In reply to Ihar Hrachyshka from comment #16)
> I think we can start with a RHOSO 18 Jira and consider the complexity of the
> implementation for 17.x later. Would you mind reporting a Jira for this work
> to happen in neutron? Thanks.

I have opened this ticket:
https://issues.redhat.com/browse/OSPRH-10758


Note You need to log in before you can comment on or make changes to this bug.