USHIFT-6913: Add DNS resource configuration enhancement for MicroShift by Neilhamza · Pull Request #1989 · openshift/enhancements

Neilhamza · 2026-04-28T10:22:03Z

Summary

Adds enhancement proposal for OCPSTRAT-3015: MicroShift DNS deployment resource configuration
Introduces dns.resources config option to override CPU/memory requests and limits for the dns container in the dns-default DaemonSet
Follows the same pattern as the existing dns.hosts feature

openshift-ci-robot · 2026-04-28T10:22:07Z

@Neilhamza: This pull request references USHIFT-6912 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "5.0.0" version, but no target version was set.

Details

In response to this:

Summary

Adds enhancement proposal for OCPSTRAT-3015: MicroShift DNS deployment resource configuration

Introduces dns.resources config option to override CPU/memory requests and limits for the dns container in the dns-default DaemonSet

Follows the same pattern as the existing dns.hosts feature

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 · 2026-04-28T10:26:27Z

@Neilhamza: This pull request references USHIFT-6913 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "5.0.0" version, but no target version was set.

Details

In response to this:

Summary

Adds enhancement proposal for OCPSTRAT-3015: MicroShift DNS deployment resource configuration

Introduces dns.resources config option to override CPU/memory requests and limits for the dns container in the dns-default DaemonSet

Follows the same pattern as the existing dns.hosts feature

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.

Neilhamza · 2026-04-28T10:30:59Z

/jira refresh

openshift-ci-robot · 2026-04-28T10:31:02Z

@Neilhamza: This pull request references USHIFT-6913 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "5.0.0" version, but no target version was set.

Details

In response to this:

/jira refresh

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.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

pacevedom · 2026-05-04T16:00:47Z

/assign

pacevedom · 2026-05-04T21:45:05Z

+    Requests map[string]string `json:"requests,omitempty"`
+    Limits   map[string]string `json:"limits,omitempty"`


Should we use specific fields here instead of arbitrary keys? With current types a user could input gpus: 1 for example.
Wondering if corev1.ResourceRequirements type would bring any benefits too.

restrict keys to only "cpu" and "memory" during validation, unsupported keys like "gpu" are rejected with a clear error. in the implementation we used map[string]string to stay consistent with the existing config patterns (simple Go types, not Kubernetes API types). Using corev1.ResourceRequirements would be the only Kubernetes type in the config package and would add coupling to the API types for serialization.

Added to the Document that only cpu and memory keys are accepted, unsupported keys rejected during validation

pacevedom · 2026-05-04T21:46:30Z

+      memory: <resource.Quantity> # optional, default: not set
+```
+
+By default, the `dns.resources` section is not set, and the current hardcoded defaults are used. When provided, individual fields within `requests` and `limits` are optional - users can set only the values they want to override.


If a user includes any of those values, does that invalidate the default setting for the others? For example, setting cpu to 500m still keeps the 70Mi for memory, or does it become unset?

setting only cpu: 500m preserves the default memory: 70Mi. The implementation uses key-by-key merge, not full map replacement. and we have a test for it

Added to the Document explicit explanation of key-by-key merge behavior and that defaults are preserved

pacevedom · 2026-05-04T21:49:02Z

+    "DNSCPULimit":      dnsResourceValue(cfg.DNS.Resources, "limits", "cpu", ""),
+    "DNSMemoryLimit":   dnsResourceValue(cfg.DNS.Resources, "limits", "memory", ""),


Unset limits would render empty strings, which renders to false in the template. This is now a requirement for the function, right?

Yes, unset limits return empty strings.
The template uses {{- if .DNSHasLimits }} (checks len(cfg.DNS.Resources.Limits) > 0) to conditionally render the entire limits block. Individual limit values are also guarded with {{- if .DNSCPULimit }}. So empty strings never appear in the rendered YAML.

Updated template to use DNSHasLimits boolean (matching implementation), added explanation of nil map behavior

pacevedom · 2026-05-04T21:50:02Z

+### Risks and Mitigations
+
+**Risk:** Users configure resources too low, causing CoreDNS to be OOM-killed or throttled.
+**Mitigation:** Document minimum recommended values. MicroShift does not enforce minimum thresholds to allow flexibility on constrained devices.


We might need to include a minimum setting or else the cluster is not even able to start properly (without dns there is no readiness from all pods).

Good point. We could add minimum thresholds in validation (e.g., reject cpu < 10m or memory < 20Mi), but could this block legitimate use cases on extremely constrained edge devices?

updated mitigation text, acknowledged the risk, noted minimum validation can be added later

We have minimum requirements to run MicroShift (without including the app). Even if there is an extreme resource contraint the minimum requirements must hold, and having too low resources for dns might render unstable clusters (dns not responding, throttling in other pods, etc.).
What do you think about having the minimum the same as the default value we ship, as that has been the case so far since first version?

sure! updated the minimum requirements same as the default we ship

lance5890 · 2026-05-05T06:54:13Z

+**Risk:** Users configure resources too low, causing CoreDNS to be OOM-killed or throttled.
+**Mitigation:** Document minimum recommended values. MicroShift does not enforce minimum thresholds to allow flexibility on constrained devices.
+
+**Risk:** Users configure resource limits without requests, leading to unexpected Kubernetes scheduling behavior.


I'm afraid that if u only set the limit value without setting the request value, the request value should be equal to the limit value by default

In the implementation, default requests (cpu=50m, memory=70Mi) are always populated by dnsDefaults(). If a user sets only limits, the defaults remain as requests. The rendered DaemonSet YAML always contains explicit requests and limits values
adding this to the Document

Added to the Document detailed explanation that default requests are always populated, and validation catches limit default request

Should we add a test for this in the test plan? This is a corner case for the config.

yes! added the test in the e2e tests and in the test plan

Update enhancement document to match implementation: - Value type DNSResources instead of pointer - Key-by-key merge preserving defaults for partial config - Key validation restricting to cpu and memory - DNSHasLimits boolean for template rendering - Clarify limit-without-request behavior - Expand test plan to cover all 7 e2e test cases Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

openshift-ci · 2026-05-05T07:11:36Z

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please ask for approval from pacevedom. For more information see the Code Review Process.

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

Details

Needs approval from an approver in each of these files:

OWNERS

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

Minimum requests (cpu: 50m, memory: 70Mi) match shipped defaults. Requests below these thresholds are rejected at startup to prevent unstable clusters. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

openshift-ci · 2026-05-05T09:55:18Z

@Neilhamza: 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-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label Apr 28, 2026

openshift-ci Bot requested review from ingvagabund and sosiouxme April 28, 2026 10:22

Neilhamza force-pushed the dns-resource-configuration branch from a296905 to fda3b3f Compare April 28, 2026 10:23

Neilhamza changed the title ~~USHIFT-6912: Add DNS resource configuration enhancement for MicroShift~~ USHIFT-6913: Add DNS resource configuration enhancement for MicroShift Apr 28, 2026

Neilhamza force-pushed the dns-resource-configuration branch from fda3b3f to 89258a5 Compare April 28, 2026 10:54

USHIFT-6912: Add DNS resource configuration enhancement for MicroShift

23f187e

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Neilhamza force-pushed the dns-resource-configuration branch from 89258a5 to 23f187e Compare April 28, 2026 11:23

openshift-ci Bot assigned pacevedom May 4, 2026

pacevedom mentioned this pull request May 4, 2026

USHIFT-6912: Add DNS deployment resource configuration support openshift/microshift#6621

Open

pacevedom reviewed May 4, 2026

View reviewed changes

lance5890 reviewed May 5, 2026

View reviewed changes

Neilhamza and others added 2 commits May 5, 2026 12:35

USHIFT-6912: Enforce minimum DNS resource requests in validation

da1fda9

Minimum requests (cpu: 50m, memory: 70Mi) match shipped defaults. Requests below these thresholds are rejected at startup to prevent unstable clusters. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

USHIFT-6914: Add limits-only test case to test plan

6ab0ece

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Neilhamza requested a review from pacevedom May 5, 2026 09:41

		Requests map[string]string `json:"requests,omitempty"`
		Limits map[string]string `json:"limits,omitempty"`

		"DNSCPULimit": dnsResourceValue(cfg.DNS.Resources, "limits", "cpu", ""),
		"DNSMemoryLimit": dnsResourceValue(cfg.DNS.Resources, "limits", "memory", ""),

Conversation

Neilhamza commented Apr 28, 2026 • edited by openshift-ci Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Uh oh!

openshift-ci-robot commented Apr 28, 2026 • edited by openshift-ci Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Uh oh!

openshift-ci-robot commented Apr 28, 2026

Summary

Uh oh!

Neilhamza commented Apr 28, 2026

Uh oh!

openshift-ci-robot commented Apr 28, 2026

Uh oh!

pacevedom commented May 4, 2026

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!

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!

pacevedom May 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

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!

openshift-ci Bot commented May 5, 2026

Uh oh!

openshift-ci Bot commented May 5, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Neilhamza commented Apr 28, 2026 •

edited by openshift-ci Bot

Loading

openshift-ci-robot commented Apr 28, 2026 •

edited by openshift-ci Bot

Loading

pacevedom May 5, 2026 •

edited

Loading