USHIFT-6901: Add custom DNS config for microshift#1984
USHIFT-6901: Add custom DNS config for microshift#1984pacevedom wants to merge 1 commit intoopenshift:masterfrom
Conversation
|
@pacevedom: This pull request references USHIFT-6901 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. DetailsIn response to this: 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
added
the
jira/valid-reference
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
@pacevedom: all tests passed! Full PR test history. Your PR dashboard. DetailsInstructions 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. |
| when new CoreDNS features are needed. | ||
| * Reflect changes to the custom Corefile at runtime without restarting | ||
| MicroShift. | ||
| * Maintain mutual exclusivity between custom DNS configuration and the |
There was a problem hiding this comment.
I guess we'll have to throw in C2CC CoreDNS other-cluster forwarding, but it looks liek future me problem
| contents, using the file content as the `Corefile` key value. | ||
|
|
||
| #### Runtime reload | ||
| A new file watcher, following the same pattern as `HostsWatcherManager` in |
There was a problem hiding this comment.
Is it a chance for common struct refactor?
| On systems using greenboot for health checking, a bad Corefile that breaks DNS | ||
| will cause health checks to fail, triggering an automatic rollback to the | ||
| previous deployment. This acts as a safety net, limiting the blast radius of |
There was a problem hiding this comment.
I think this warrants an investigation, ostree/bootc is doing some kind of merge for /etc. TBH I'm not even sure if a new image can deploy a new config? And if so, would rolling back really go back to previous config?
I think it should, only /var is not manipulated during those operations.
| updates to work. If omitted, the user must restart CoreDNS pods manually. | ||
|
|
||
| ## Open Questions | ||
| 1. Should MicroShift provide a default Corefile as a reference file on disk |
There was a problem hiding this comment.
Either that or in the docs. With observability I think we kind of do both...
4 participants
No description provided.