Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extend dns configmap tests to include CoreDNS #63265

Merged
merged 1 commit into from
May 24, 2018
Merged

Extend dns configmap tests to include CoreDNS #63265

merged 1 commit into from
May 24, 2018

Conversation

rajansandeep
Copy link
Contributor

@rajansandeep rajansandeep commented Apr 27, 2018

What this PR does / why we need it:
This PR extends the DNS configmap e2e tests to include testing the CoreDNS ConfigMap.
The tests now test the equivalent stubdomain, federation and upstreamnameserver configuration of kube-dns for CoreDNS, when CoreDNS is the installed DNS server.

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #62865

Special notes for your reviewer:

Release note:

NONE

@k8s-ci-robot k8s-ci-robot added release-note-none Denotes a PR that doesn't merit a release note. size/L Denotes a PR that changes 100-499 lines, ignoring generated files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. labels Apr 27, 2018
@rajansandeep
Copy link
Contributor Author

/sig network
/area dns

@k8s-ci-robot k8s-ci-robot added sig/network Categorizes an issue or PR as relevant to SIG Network. area/dns labels May 2, 2018
@fturib
Copy link

fturib commented May 8, 2018

/cc @MrHohn

@k8s-ci-robot k8s-ci-robot requested a review from MrHohn May 8, 2018 16:39
Copy link
Member

@MrHohn MrHohn left a comment

Choose a reason for hiding this comment

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

Thanks for the works, this looks good overall.

@@ -235,6 +242,21 @@ func (t *dnsTestCommon) deleteUtilPod() {
}
}

// deleteCoreDNSPods manually deletes the CoreDNS pods to apply the changes to the ConfigMap.
Copy link
Member

Choose a reason for hiding this comment

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

Interesting, so CoreDNS pod doesn't reload configmap upon update? Will this behavior change in the future?

Copy link
Member

Choose a reason for hiding this comment

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

Copy link

@fturib fturib May 18, 2018

Choose a reason for hiding this comment

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

Yes, reload plugin would work. However it is slow : it can take up to 2mn30 to have the reload effective.
Also there is a dependency with the image used for CoreDNS.
Right now CoreDNS used in kube-up does not support the reload plugin.

(that manifest is expected to be updated next week, before code freeze, with last version of CoreDNS and the support of reload).

Copy link
Member

Choose a reason for hiding this comment

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

Ack, we can live with this for now.

it can take up to 2mn30 to have the reload effective

Curious why 2m30, would this be changed to a pull model in the future?

Copy link
Member

Choose a reason for hiding this comment

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

Oops I meant push..

Copy link

Choose a reason for hiding this comment

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

@MrHohn : it is not expected to be changed.
The current behavior to update the config of CoreDNS is to associate a persitent file named "Corefile" with the configmap "coredns".
The delay to have the persistent file updated after edition of the Configmap can go up to 2mn.
The delay to "reload" the configuration file in CoreDNS is tuned to 30sec (but could be decrease down to 2 sec).

Overall the most important delay is coming from Kubernetes' mechanism to propagate the update to the persistent file.

pods insecure
upstream
fallthrough in-addr.arpa ip6.arpa
}
Copy link
Member

Choose a reason for hiding this comment

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

I see the default corefile contains more options than this, should we keep them consistent (for the unchanged part), or at least recover to what it was after test?

Corefile: |
.:53 {
errors
health
kubernetes __PILLAR__DNS__DOMAIN__ in-addr.arpa ip6.arpa {
pods insecure
upstream
fallthrough in-addr.arpa ip6.arpa
}
prometheus :9153
proxy . /etc/resolv.conf
cache 30
}

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I kept the corefile minimal for the tests as the additional options which I removed from the default won't affect the tests.

Copy link
Member

Choose a reason for hiding this comment

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

Fair enough. Can we store the configmap before test, and recover that after test?

@MrHohn
Copy link
Member

MrHohn commented May 8, 2018

/assign
cc @grayluck

proxy . /etc/resolv.conf
cache 30
Copy link
Member

Choose a reason for hiding this comment

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

Humm...Instead of hardcoding the config value here, can we fetch the configmap directly before test? In that way we are off the burden of keeping these consistent with whatever is in the CoreDNS deployment configuration.

Similar to:

pcm, err := fetchDNSScalingConfigMap(c)
Expect(err).NotTo(HaveOccurred())
previousParams = pcm.Data

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done.

Copy link
Member

@MrHohn MrHohn left a comment

Choose a reason for hiding this comment

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

Thanks, this looks good. Could you squash the fix-up commits?
/approve

@k8s-ci-robot k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label May 22, 2018
Copy link

@fturib fturib left a comment

Choose a reason for hiding this comment

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

I agree with logic.
But, unless I am wrong, we need to ensure the configmap is restored even if execution of the test is interrupted because of failing part.

@@ -160,6 +162,7 @@ func (t *dnsNameserverTest) run() {
defer t.deleteDNSServerPod()

if t.name == "coredns" {
originalConfigMapData = t.fetchCoreDNSConfigMapData()
t.setConfigMap(&v1.ConfigMap{Data: map[string]string{
Copy link

Choose a reason for hiding this comment

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

As we expect that the Configmap returned to the original one, WHATEVER the result of the test. We need to ensure that it is setback to the "originalConfigMapData" with a "defer function" (like the one of line 162).

if t.name == "coredns" {
t.setConfigMap(&v1.ConfigMap{Data: originalConfigMapData})
t.deleteCoreDNSPods()
} else {
Copy link

Choose a reason for hiding this comment

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

we should keep this return to original, as there is a dependent test after it.
But we still need the "defer .." restore to ensure it whatever the result of all tests.

Copy link

Choose a reason for hiding this comment

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

I would think that is also true for the kube-dns clear of ConfigMap.
Maybe be worth to create a function or restoring the original configmap configuration and defer that function on each test.

Copy link
Member

Choose a reason for hiding this comment

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

Good point, defer seems like a better option.

Regarding kube-dns, the default kube-dns configmap is empty. So a reset would probably be enough. But having such function sounds good as well.

err = podClient.Delete(pod.Name, metav1.NewDeleteOptions(0))
Expect(err).NotTo(HaveOccurred())
}
}
Copy link

Choose a reason for hiding this comment

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

Should you wait the Pod is restored before going ahead ? or that is part of a delete option ?

Copy link

@fturib fturib left a comment

Choose a reason for hiding this comment

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

Thanks for the update

@rajansandeep
Copy link
Contributor Author

/retest

@MrHohn
Copy link
Member

MrHohn commented May 23, 2018

/lgtm

/test pull-kubernetes-e2e-kops-aws

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label May 23, 2018
@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: MrHohn, rajansandeep

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

The pull request process is described here

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

@rajansandeep
Copy link
Contributor Author

/retest

1 similar comment
@rajansandeep
Copy link
Contributor Author

/retest

@k8s-github-robot
Copy link

Automatic merge from submit-queue (batch tested with PRs 64174, 64187, 64216, 63265, 64223). If you want to cherry-pick this change to another branch, please follow the instructions here.

@k8s-github-robot k8s-github-robot merged commit 52f44cd into kubernetes:master May 24, 2018
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. area/dns cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. lgtm "Looks good to me", indicates that a PR is ready to be merged. release-note-none Denotes a PR that doesn't merit a release note. sig/network Categorizes an issue or PR as relevant to SIG Network. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

e2e network/config-map - adapt the ConfigMap change depending the kind of DNS Server running.
5 participants