Closed
Description
Found when looking into DNS configMap upgrade-test errors
@bowei - can you take a look at the following and let me know if this is an issue for the 1.6 release or not? Thanks!
There are two tests failing around DNS configMap in the following test job:
For context, this job is creating a 1.5 cluster, upgrading it to 1.6, then running the 1.6 E2E tests on it to ensure it acts like a fresh 1.6 cluster.
Activity
skriss commentedon Mar 8, 2017
/assign @bowei
liggitt commentedon Mar 9, 2017
Is this a dupe of #42746 or are the nodes upgraded as well?
skriss commentedon Mar 9, 2017
@liggitt not a dupe - this test job upgrades nodes as well, and the failure mode is different
skriss commentedon Mar 9, 2017
@liggitt @bowei is someone looking at this? should it be routed to someone else?
bowei commentedon Mar 9, 2017
Looking --
bowei commentedon Mar 9, 2017
Let keep this as a 1.6 issue for now. The run does not seem to have incorporated the ConfigMap change, it should be independent, but I am still investigating why the failure occurred.
MrHohn commentedon Mar 10, 2017
From the failure above, seems like kube-dns pod was not upgraded to the newer version after upgrade:
Note that we already removed the healthz container from kube-dns in v1.6.
MrHohn commentedon Mar 10, 2017
Found more hints from the equivalent gce upgrade test: https://k8s-gubernator.appspot.com/build/kubernetes-jenkins/logs/ci-kubernetes-e2e-gce-1.5-1.6-upgrade-cluster-new/8
Apparently addon-manager is not working properly and it failed to update kube-dns (logs file). The cause for its failures was that
kubectl apply
hit some weird validation errors as below:And I could not reproduce these errors locally with v1.6.0-beta.1 kubectl against either v1.5.3 or v1.6+ cluster.@kubernetes/sig-cli-bugs
Updates:
FYI the kubectl binary this addon-manager used is built with commit 17375fc (earlier than v1.6.0-beta.1)
but I could not reproduce the error with this binary either. So it feels like the validation errors happened on the apiserver side?mengqiy commentedon Mar 10, 2017
I think this issue have been fixed by #42489. And it is in 1.6.0-beta.2.
The root cause is #42488
EDIT: This only fix the second error
MrHohn commentedon Mar 10, 2017
Updates: I reproduced the first error with kubectl v1.6.0-beta.2 and the latest k8s cluster when try to
kubectl apply -f
an older version kube-dns deployment against the latest one:Another update: And with kubectl v1.5.2:
liggitt commentedon Mar 10, 2017
huh, that almost seems like defaults aren't getting applied after the patch is applied
bowei commentedon Mar 10, 2017
@ymqytw -- as this seems to be an issue with the API object patch mechanism, I am going to assign to you for now... You can assign it back if this continues to fail with the fixes mentioned above.
/assign @ymqytw
liggitt commentedon Mar 10, 2017
@wojtek-t is it possible the switch to
unstructured.DefaultConverter.FromUnstructured
inapplyPatchToObject
dropped the defaulting step of conversion?22 remaining items