Bug 1940272

Summary:	[DDF] DNS resolving is very slow with the procedure of "Deploying Internal DNS with OVN"
Product:	Red Hat OpenStack	Reporter:	Direct Docs Feedback <ddf-bot>
Component:	documentation	Assignee:	Greg Rakauskas <gregraka>
Status:	CLOSED NOTABUG	QA Contact:	RHOS Documentation Team <rhos-docs>
Severity:	unspecified	Docs Contact:
Priority:	medium
Version:	16.1 (Train)	CC:	eolivare, gregraka, ihrachys, jamsmith, migawa, rsafrono
Target Milestone:	---	Keywords:	Triaged
Target Release:	---
Hardware:	All
OS:	All
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2022-10-04 20:41:45 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:

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