OPNET-678: Add internalDNSRecords field by cybertron · Pull Request #2460 · openshift/api

cybertron · 2025-08-26T21:49:21Z

Adds a new field to the Infrastructure object that allows control over the behavior of the on-prem internal DNS records. It can be set to either Internal or External, where Internal is the default (and previous) behavior, and External suppresses generation of the internal records so they can be managed outside the cluster. Currently, External can only be used with a UserManaged loadbalancer.

openshift-ci · 2025-08-26T21:49:26Z

Hello @cybertron! Some important instructions when contributing to openshift/api:
API design plays an important part in the user experience of OpenShift and as such API PRs are subject to a high level of scrutiny to ensure they follow our best practices. If you haven't already done so, please review the OpenShift API Conventions and ensure that your proposed changes are compliant. Following these conventions will help expedite the api review process for your PR.

openshift-ci · 2025-08-26T21:49:27Z

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

everettraven · 2025-08-29T16:55:00Z

+	// api, api-int, and ingress.
+	// +kubebuilder:validation:Optional
+	// +kubebuilder:validation:Enum=Enabled;Disabled
+	// +openshift:validation:featureGate=OnPremInternalDNSRecords


AFAIK, this isn't a real marker. Let's remove this.

Heh, yeah I was throwing stuff at the wall when I had trouble with the feature gate.

everettraven · 2025-08-29T16:55:42Z


+	// internalDNSRecords determines whether we deploy with internal records enabled for
+	// api, api-int, and ingress.
+	// +kubebuilder:validation:Optional


This is essentially a duplicate of the +optional marker below. We prefer the use of the +optional marker so let's remove this one.

everettraven · 2025-08-29T18:10:42Z

+	// +openshift:validation:featureGate=OnPremInternalDNSRecords
+	// +openshift:enable:FeatureGate=OnPremInternalDNSRecords
+	// +optional
+	InternalDNSRecords InternalDNSRecordsType `json:"internalDNSRecords"`


Because this is an optional field and the zero value is invalid, this should have omitempty.

everettraven · 2025-08-29T18:14:46Z

+type InternalDNSRecordsType string
+
+const (
+	InternalDNSRecordsDisabled InternalDNSRecordsType = "Disabled"
+	InternalDNSRecordsEnabled InternalDNSRecordsType = "Enabled"
+)


Normally we try to avoid the terminology Enabled and Disabled where possible because the terms can often be overloaded and cause confusion.
What if instead of naming the field this applies to internalDNSRecords, what if we named it something like dnsRecordsPolicy (or maybe dnsRecordsType? not sure which one is better) and we had Internal and External as the options?

everettraven · 2025-08-29T18:17:34Z

+	// internalDNSRecords determines whether we deploy with internal records enabled for
+	// api, api-int, and ingress.


Please include validation constraints in the GoDoc here so that this is more end-user friendly. This is the text used in our generated API documentation and what users will see when they use something like oc explain ... so we should make sure it reads appropriately as end-user documentation.
Some good guidelines for things to take into consideration for inclusion in the GoDoc are here: https://github.com/openshift/enhancements/blob/master/dev-guide/api-conventions.md#write-user-readable-documentation-in-godoc

everettraven · 2025-08-29T18:21:26Z

+	// internalDNSRecords determines whether we deploy with internal records enabled for
+	// api, api-int, and ingress.
+	// +kubebuilder:validation:Optional
+	// +kubebuilder:validation:Enum=Enabled;Disabled
+	// +openshift:validation:featureGate=OnPremInternalDNSRecords
+	// +openshift:enable:FeatureGate=OnPremInternalDNSRecords
+	// +optional
+	InternalDNSRecords InternalDNSRecordsType `json:"internalDNSRecords"`
+


This looks like we have only added this to the BareMetalPlatformStatus type? Is this because the OpenShift installer will end up setting this value at install time?

If I understand the EP correctly as well, this sounds like this should only be possible to set when loadBalancer is set to UserManaged?
Do we need some additional validation logic (maybe a CEL expression) to enforce that?

Yes, this will be populated by the installer. I have a validation in the installer to ensure it isn't set when it shouldn't be, but I can move that here if it would be better.
I should also note that this is only a partial version of the change. Because these are per-platform types we'll need to apply the same change to the other on-prem platforms once we know what it should look like.

JoelSpeed · 2025-09-09T13:56:08Z

/test lint

cybertron · 2025-09-17T20:17:34Z

I think this latest revision should address all of the comments so far, except moving the validation to the api layer. If we ever make this modifiable after initial install we'll have to do that, but I'd just as soon defer that effort until/if it's needed. Willing to move it here if you'd prefer though.

JoelSpeed · 2025-09-18T13:37:24Z

 	// +optional
 	LoadBalancer *BareMetalPlatformLoadBalancer `json:"loadBalancer,omitempty"`

+	// DNSRecordsType determines whether records for api, api-int, and ingress


Suggested change
// DNSRecordsType determines whether records for api, api-int, and ingress
// dnsRecordsType determines whether records for api, api-int, and ingress

JoelSpeed · 2025-09-18T13:39:22Z

+	// are provided by the internal DNS service or externally. `Internal` configures
+	// DNS records in the internal service. `External` means no records will be


Internal allows DNS resolution for components within the cluster right? It's configuring coredns?

It's configuring a coredns instance on each host. This is separate from the coredns pod that is part of the dns-operator.

everettraven · 2025-09-19T13:53:24Z

+	// DNSRecordsType determines whether records for api, api-int, and ingress
+	// are provided by the internal DNS service or externally. `Internal` configures
+	// DNS records in the internal service. `External` means no records will be
+	// provided and must be configured external to the cluster. `External` is only
+	// allowed when a user-managed loadbalancer is configured. When unset, the
+	// internal records will be provided.
+	// api, api-int, and ingress.


For enum based fields we generally try to follow a pattern like:
dnsRecordsType ...
Allowed values are Internal, External, and omitted.
When set to Internal, ...
When set to External, ...
When omitted, ...

everettraven · 2025-09-19T13:53:54Z

+	DNSRecordsExternal DNSRecordsType = "External"
+	DNSRecordsInternal DNSRecordsType = "Internal"


Suggested change
DNSRecordsExternalDNSRecordsType="External"
DNSRecordsInternalDNSRecordsType="Internal"
DNSRecordsTypeExternalDNSRecordsType="External"
DNSRecordsTypeInternalDNSRecordsType="Internal"

everettraven · 2025-09-19T13:56:55Z

If we ever make this modifiable after initial install we'll have to do that, but I'd just as soon defer that effort until/if it's needed. Willing to move it here if you'd prefer though.

Is this API currently immutable? How do we enforce that?

cybertron · 2025-09-23T16:33:55Z

Is this API currently immutable? How do we enforce that?

This field is only part of the Infrastructure status. There's nothing in the spec to allow it to be modified.

cybertron · 2025-09-23T16:57:36Z

Oh shoot, I had some stale changes in my editor. I'll fix that.

everettraven · 2025-09-24T12:50:43Z

+	// When set to `External`, records are not provided by the internal infrastructure
+	// and must be configured by the user. This value may only be set when a
+	// user-managed loadbalancer is configured.
+	// When omitted, the behavior will be the same as `Internal`.


For the omitted scenario we have some standard terminology we've used throughout OpenShift APIs:
When omitted, this means the user has no opinion and the platform is left
to choose reasonable defaults. These defaults are subject to change over time.
The current default is {default}

cybertron · 2025-10-16T22:43:58Z

Rebased and marking ready for review

everettraven · 2025-10-20T15:21:26Z

@cybertron It looks like this needs a rebase. Could you also update the PR description to provide some additional information as to what work with PR is associated with?

Thanks!

JoelSpeed

/lgtm

openshift-ci-robot · 2025-11-12T19:34:04Z

Scheduling tests matching the pipeline_run_if_changed or not excluded by pipeline_skip_if_only_changed parameters:
/test e2e-aws-ovn
/test e2e-aws-ovn-hypershift
/test e2e-aws-ovn-hypershift-conformance
/test e2e-aws-ovn-techpreview
/test e2e-aws-serial-1of2
/test e2e-aws-serial-2of2
/test e2e-aws-serial-techpreview-1of2
/test e2e-aws-serial-techpreview-2of2
/test e2e-azure
/test e2e-gcp
/test e2e-upgrade
/test e2e-upgrade-out-of-change

openshift-ci · 2025-11-12T19:34:17Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: JoelSpeed

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

~~OWNERS~~ [JoelSpeed]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

cybertron · 2025-11-12T21:20:52Z

/verified by @cybertron

I've tested this by vendoring it into the affected projects in my local dev cluster.

openshift-ci-robot · 2025-11-12T21:21:05Z

@cybertron: This PR has been marked as verified by @cybertron.

Details

In response to this:

/verified by @cybertron
I've tested this by vendoring it into the affected projects in my local dev cluster.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

openshift-ci-robot · 2025-11-12T22:00:48Z

/retest-required

Remaining retests: 0 against base HEAD 50e2ece and 2 for PR HEAD c72fe4d in total

cybertron · 2025-11-13T15:11:27Z

/retest-required

This should have no effect on an aws cluster. Looks like maybe a quota issue?

cybertron · 2025-11-13T21:45:15Z

/retest-required

As far as I can tell, this is failing on the following error:

2025-11-13T16:10:21.817654562Z I1113 16:10:21.817595 1 requests.go:294] Making HTTP GET request at: https://console.redhat.com/api/insights-results-aggregator/v2/cluster/30461bca-facb-4b6c-9cc0-eb7feda89f9b/request/5399d52611ba4030b31666bac1f43a03/status
2025-11-13T16:10:51.915983970Z I1113 16:10:51.915917 1 gather_commands.go:443] Received HTTP status code 504, retry 3/3 in 1m0s

Which appears to be a server-side issue on console.redhat.com.

cybertron · 2025-11-13T22:39:46Z

/retest-required

And now we're failing on rate limiting from AWS.

cybertron · 2025-11-14T15:13:26Z

/retest-required

I see this job finally passed last night, hopefully the issues have been fixed.

openshift-ci-robot · 2025-11-14T18:29:50Z

/retest-required

Remaining retests: 0 against base HEAD 6711368 and 1 for PR HEAD c72fe4d in total

cybertron · 2025-11-14T21:48:51Z

/retest-required

Failed on a totally different set of tests this time. :-/

cybertron · 2025-11-17T14:04:33Z

/retest-required

openshift-ci · 2025-11-17T16:47:29Z

@cybertron: all tests passed!

Full PR test history. Your PR dashboard.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

Pulling in the internalDNSRecords field from openshift/api#2460

Specifically looking to pull in the dnsRecordsType field from openshift/api#2460

openshift-ciBot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Aug 26, 2025

openshift-merge-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Aug 26, 2025

openshift-ciBot added the size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. label Aug 26, 2025

cybertron mentioned this pull request Aug 26, 2025
OPNET-678: Make VIPs optional with external loadbalancer openshift/enhancements#1803
Closed

everettraven reviewed Aug 29, 2025
View reviewed changes

cybertron force-pushed the disable-internal-dns branch from 3ddd0ad to 09cb604Compare September 17, 2025 19:47

openshift-merge-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Sep 17, 2025

JoelSpeed reviewed Sep 18, 2025
View reviewed changes

everettraven reviewed Sep 19, 2025
View reviewed changes

cybertron force-pushed the disable-internal-dns branch from 569c8f8 to 80ec627Compare September 23, 2025 17:08

everettraven reviewed Sep 24, 2025
View reviewed changes

Comment threadconfig/v1/types_infrastructure.go

everettraven reviewed Sep 24, 2025
View reviewed changes

cybertron force-pushed the disable-internal-dns branch from 80ec627 to 862d02eCompare October 3, 2025 20:59

cybertron force-pushed the disable-internal-dns branch from 862d02e to 5e9cb14Compare October 16, 2025 22:43

cybertron marked this pull request as ready for review October 16, 2025 22:43

openshift-ciBot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Oct 16, 2025

openshift-ciBot requested review from everettraven and jkyros October 16, 2025 22:44

openshift-merge-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Oct 20, 2025

cybertron force-pushed the disable-internal-dns branch from 5e9cb14 to 88219abCompare October 24, 2025 20:33

openshift-merge-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Oct 24, 2025

openshift-ciBot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Nov 12, 2025

Update godoc to clarify user requirements
c72fe4d

cybertron force-pushed the disable-internal-dns branch from 41fd623 to c72fe4dCompare November 12, 2025 19:15

openshift-ciBot removed the lgtm Indicates that a PR is ready to be merged. label Nov 12, 2025

JoelSpeed reviewed Nov 12, 2025
View reviewed changes

openshift-ciBot added the lgtm Indicates that a PR is ready to be merged. label Nov 12, 2025

openshift-ci-robot added the verified Signifies that the PR passed pre-merge verification criteria label Nov 12, 2025

openshift-merge-botBot merged commit 348370f into openshift:masterNov 17, 2025
28 checks passed

cybertron added a commit to cybertron/installer that referenced this pull request Nov 17, 2025
Bump openshift/api
e178a87
Pulling in the internalDNSRecords field from openshift/api#2460

cybertron mentioned this pull request Nov 17, 2025
OPNET-678: Bump openshift/api openshift/installer#10097
Merged

cybertron added a commit to cybertron/installer that referenced this pull request Nov 18, 2025
Bump openshift/api
a0dd35f
Pulling in the internalDNSRecords field from openshift/api#2460

cybertron added a commit to cybertron/cluster-version-operator that referenced this pull request Nov 19, 2025
Update openshift/api vendoring
3dfb0da
Specifically looking to pull in the dnsRecordsType field from openshift/api#2460

cybertron mentioned this pull request Nov 19, 2025
OPNET-678: Update openshift/api vendoring openshift/cluster-version-operator#1262
Closed

dfitzmau mentioned this pull request Dec 22, 2025
OSDOCS-16614: Documented VIP optional with user-managed LB feature openshift/openshift-docs#104065
Merged
2 tasks

qodo-for-rh-openshiftBot mentioned this pull request Jul 29, 2026
4.22 backport: add IBMCloudServiceTransitGateway and IBMCloudServicePowerVS to IBMCloudServiceName #2961
Closed

This was referenced Aug 10, 2026
OCPBUGS-105407: Remove VSphereMultiNetworks feature gate #2975
Open
OSASINFRA-4437: openstack: add additional fields to support multiple VIPs #2976
Open

		// internalDNSRecords determines whether we deploy with internal records enabled for
		// api, api-int, and ingress.

	// DNSRecordsType determines whether records for api, api-int, and ingress
	// dnsRecordsType determines whether records for api, api-int, and ingress

		// are provided by the internal DNS service or externally. `Internal` configures
		// DNS records in the internal service. `External` means no records will be

		DNSRecordsExternal DNSRecordsType = "External"
		DNSRecordsInternal DNSRecordsType = "Internal"

-DNSRecordsExternalDNSRecordsType="External"
-DNSRecordsInternalDNSRecordsType="Internal"
+DNSRecordsTypeExternalDNSRecordsType="External"
+DNSRecordsTypeInternalDNSRecordsType="Internal"

Uh oh!

Conversation

cybertron commented Aug 26, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openshift-ciBot commented Aug 26, 2025

Uh oh!

openshift-ciBot commented Aug 26, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

JoelSpeed commented Sep 9, 2025

Uh oh!

cybertron commented Sep 17, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

everettraven commented Sep 19, 2025

Uh oh!

cybertron commented Sep 23, 2025

Uh oh!

cybertron commented Sep 23, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cybertron commented Oct 16, 2025

Uh oh!

everettraven commented Oct 20, 2025

Uh oh!

JoelSpeed left a comment

Choose a reason for hiding this comment

Uh oh!

openshift-ci-robot commented Nov 12, 2025

Uh oh!

openshift-ciBot commented Nov 12, 2025

Uh oh!

cybertron commented Nov 12, 2025

Uh oh!

openshift-ci-robot commented Nov 12, 2025

Uh oh!

openshift-ci-robot commented Nov 12, 2025

Uh oh!

cybertron commented Nov 13, 2025

Uh oh!

cybertron commented Nov 13, 2025

Uh oh!

cybertron commented Nov 13, 2025

Uh oh!

cybertron commented Nov 14, 2025

Uh oh!

openshift-ci-robot commented Nov 14, 2025

Uh oh!

cybertron commented Nov 14, 2025

Uh oh!

cybertron commented Nov 17, 2025

cybertron commented Aug 26, 2025•
edited
Loading