Skip to content

OPNET-678: Add internalDNSRecords field#2460

Merged
openshift-merge-bot[bot] merged 11 commits intoopenshift:masterfrom
cybertron:disable-internal-dns
Nov 17, 2025
Merged

OPNET-678: Add internalDNSRecords field#2460
openshift-merge-bot[bot] merged 11 commits intoopenshift:masterfrom
cybertron:disable-internal-dns

Conversation

@cybertron
Copy link
Copy Markdown
Member

@cybertron cybertron commented Aug 26, 2025

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 openshift-ci Bot 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-ci
Copy link
Copy Markdown
Contributor

openshift-ci Bot commented Aug 26, 2025

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
Copy link
Copy Markdown
Contributor

openshift-ci Bot commented Aug 26, 2025

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

@openshift-merge-robot 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-ci openshift-ci Bot added the size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. label Aug 26, 2025
Comment thread config/v1/types_infrastructure.go Outdated
// api, api-int, and ingress.
// +kubebuilder:validation:Optional
// +kubebuilder:validation:Enum=Enabled;Disabled
// +openshift:validation:featureGate=OnPremInternalDNSRecords
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Comment thread config/v1/types_infrastructure.go Outdated

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Comment thread config/v1/types_infrastructure.go Outdated
// +openshift:validation:featureGate=OnPremInternalDNSRecords
// +openshift:enable:FeatureGate=OnPremInternalDNSRecords
// +optional
InternalDNSRecords InternalDNSRecordsType `json:"internalDNSRecords"`
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Comment thread config/v1/types_infrastructure.go Outdated
Comment on lines +186 to +191
type InternalDNSRecordsType string

const (
InternalDNSRecordsDisabled InternalDNSRecordsType = "Disabled"
InternalDNSRecordsEnabled InternalDNSRecordsType = "Enabled"
)
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Comment thread config/v1/types_infrastructure.go Outdated
Comment on lines +1036 to +1037
// internalDNSRecords determines whether we deploy with internal records enabled for
// api, api-int, and ingress.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Comment thread config/v1/types_infrastructure.go Outdated
Comment on lines +1036 to +1044
// 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"`

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Copy Markdown
Contributor

/test lint

@openshift-merge-robot openshift-merge-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Sep 17, 2025
@cybertron
Copy link
Copy Markdown
Member Author

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.

Comment thread config/v1/types_infrastructure.go Outdated
// +optional
LoadBalancer *BareMetalPlatformLoadBalancer `json:"loadBalancer,omitempty"`

// DNSRecordsType determines whether records for api, api-int, and ingress
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Comment thread config/v1/types_infrastructure.go Outdated
Comment on lines +1046 to +1047
// are provided by the internal DNS service or externally. `Internal` configures
// DNS records in the internal service. `External` means no records will be
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Comment thread config/v1/types_infrastructure.go Outdated
Comment on lines +1045 to +1051
// 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.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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, ...

Comment thread config/v1/types_infrastructure.go Outdated
Comment on lines +189 to +190
DNSRecordsExternal DNSRecordsType = "External"
DNSRecordsInternal DNSRecordsType = "Internal"
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
DNSRecordsExternal DNSRecordsType = "External"
DNSRecordsInternal DNSRecordsType = "Internal"
DNSRecordsTypeExternal DNSRecordsType = "External"
DNSRecordsTypeInternal DNSRecordsType = "Internal"

@everettraven
Copy link
Copy Markdown
Contributor

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
Copy link
Copy Markdown
Member Author

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
Copy link
Copy Markdown
Member Author

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

Comment thread config/v1/types_infrastructure.go
Comment thread config/v1/types_infrastructure.go Outdated
// 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`.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 cybertron force-pushed the disable-internal-dns branch from 80ec627 to 862d02e Compare October 3, 2025 20:59
@cybertron cybertron force-pushed the disable-internal-dns branch from 862d02e to 5e9cb14 Compare October 16, 2025 22:43
@cybertron cybertron marked this pull request as ready for review October 16, 2025 22:43
@openshift-ci openshift-ci Bot 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
@cybertron
Copy link
Copy Markdown
Member Author

Rebased and marking ready for review

@openshift-ci openshift-ci Bot requested review from everettraven and jkyros October 16, 2025 22:44
@everettraven
Copy link
Copy Markdown
Contributor

@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!

@openshift-merge-robot 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 cybertron force-pushed the disable-internal-dns branch from 5e9cb14 to 88219ab Compare October 24, 2025 20:33
@openshift-merge-robot 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-ci openshift-ci Bot added the lgtm Indicates that a PR is ready to be merged. label Nov 12, 2025
@openshift-ci-robot
Copy link
Copy Markdown

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 openshift-ci Bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Nov 12, 2025
@cybertron cybertron force-pushed the disable-internal-dns branch from 41fd623 to c72fe4d Compare November 12, 2025 19:15
@openshift-ci openshift-ci Bot removed the lgtm Indicates that a PR is ready to be merged. label Nov 12, 2025
Copy link
Copy Markdown
Contributor

@JoelSpeed JoelSpeed left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm

@openshift-ci openshift-ci Bot added the lgtm Indicates that a PR is ready to be merged. label Nov 12, 2025
@openshift-ci-robot
Copy link
Copy Markdown

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
Copy link
Copy Markdown
Contributor

openshift-ci Bot commented Nov 12, 2025

[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:

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

@cybertron
Copy link
Copy Markdown
Member Author

/verified by @cybertron

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

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

@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
Copy link
Copy Markdown

/retest-required

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

@cybertron
Copy link
Copy Markdown
Member Author

/retest-required

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

@cybertron
Copy link
Copy Markdown
Member Author

/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
Copy link
Copy Markdown
Member Author

/retest-required

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

@cybertron
Copy link
Copy Markdown
Member Author

/retest-required

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

@openshift-ci-robot
Copy link
Copy Markdown

/retest-required

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

@cybertron
Copy link
Copy Markdown
Member Author

/retest-required

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

@cybertron
Copy link
Copy Markdown
Member Author

/retest-required

@openshift-ci
Copy link
Copy Markdown
Contributor

openshift-ci Bot commented Nov 17, 2025

@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.

@openshift-merge-bot openshift-merge-bot Bot merged commit 348370f into openshift:master Nov 17, 2025
28 checks passed
cybertron added a commit to cybertron/installer that referenced this pull request Nov 17, 2025
Pulling in the internalDNSRecords field from
openshift/api#2460
cybertron added a commit to cybertron/installer that referenced this pull request Nov 18, 2025
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
Specifically looking to pull in the dnsRecordsType field from
openshift/api#2460
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Indicates a PR has been approved by an approver from all required OWNERS files. jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. lgtm Indicates that a PR is ready to be merged. size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. verified Signifies that the PR passed pre-merge verification criteria

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants