Bug 1768847 - [4.2]The DNS provider failed to ensure the record: caused by: Post https://route53.amazonaws.com/xxx: dial tcp x.x.x.x:443: i/o timeout
Summary: [4.2]The DNS provider failed to ensure the record: caused by: Post https://ro...
Keywords:
Status: CLOSED EOL
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Documentation
Version: 4.2.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: 4.2.z
Assignee: Daneyon Hansen
QA Contact: Hongan Li
URL:
Whiteboard:
Depends On: 1765044 1782829
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-11-05 11:41 UTC by Johnny Liu
Modified: 2021-04-07 19:34 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1765044
Environment:
Last Closed: 2021-04-07 19:34:17 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Comment 1 Daneyon Hansen 2019-11-07 18:13:39 UTC 
Users are required to manually manage dns by following https://github.com/openshift/installer/blob/master/docs/user/aws/install_upi.md#adjust-dns-zones. Moving to the doc's team to confirm this requirement is documented.
Comment 4 Daneyon Hansen 2019-11-08 17:04:41 UTC 
Johnny,

Can TestBlocker be removed from the bug? You can see how the proxy upi test job [1] automates the dns record creation.

[1] https://github.com/openshift/release/pull/4719/files
Comment 5 Johnny Liu 2019-11-11 05:27:09 UTC 
(In reply to Daneyon Hansen from comment #4)
> Johnny,
> 
> Can TestBlocker be removed from the bug? You can see how the proxy upi test
> job [1] automates the dns record creation.
> 
> [1] https://github.com/openshift/release/pull/4719/files

1. From [1], I did not see how dns record is created for apps. Do I miss something? Could you point me the detailed lines?
2. If you was saying https://github.com/openshift/installer/blob/master/docs/user/aws/install_upi.md#adjust-dns-zones, yeah, that is kinds of workaround. But the purpose of this bug is requesting the same thing in https://jira.coreos.com/browse/NE-182.
3. In QE's testing, we are running proxy testing in some 'black-hole' private subnet. Every operator should be able to reach to cloud API via proxy. In this bug, ingress-router operator does not. I think this is some important things in customer scenario.
Comment 6 Daneyon Hansen 2019-11-11 17:50:06 UTC 
Johnny,

The limitation identified in this bug was previously discovered. At that time it was agreed upon that manually creating the ingress operator dns records is an acceptable 4.3 workaround. https://jira.coreos.com/browse/NE-182 was created to fix this limitation in a future release. Hence my request to remove "TestBlocker" by manually creating the records for testing. [2] is the code in the proxy CI job that creates the ingress dns wildcard alias record. QE should be able to take the same approach for testing.

[2] https://github.com/openshift/release/pull/5308/files#diff-2b1b845b92f8062711789a2bfdb27290R2673-R2691
Comment 7 Johnny Liu 2019-11-12 01:35:01 UTC 
For UPI, I think manually adding dns record is some acceptable workaround. But for IPI, it feels like tricky. 

Steps like this:
1. user prepare a restricted network VPC.
2. user create a proxy server in this VPC
3. run IPI install with proxy enabled.
4. installation is failed, due to no dns record is provisioned.
5. after the failure, user have to add dns record manually as workaround.
Comment 8 Johnny Liu 2019-11-12 02:33:17 UTC 
And from https://github.com/openshift/release/pull/5308/files#diff-2b1b845b92f8062711789a2bfdb27290R2673-R2691, the workaround is only for UPI, no IPI.
Comment 9 Daneyon Hansen 2019-11-13 19:50:19 UTC 
UPI is the only supported installer for proxy.
Note You need to log in before you can comment on or make changes to this bug.