Please test it out so that we can get the new kernel karma'd as soon as possible:
ostree remote add --set=gpg-verify=false kerneltest https://dustymabe.fedorapeople.org/repo/ rpm-ostree rebase kerneltest:fedora-atomic/25/x86_64/docker-host
This tree currently has the following changes from current stable: Changed: kernel 4.9.4-201.fc25 -> 4.9.5-200.fc25 kernel-core 4.9.4-201.fc25 -> 4.9.5-200.fc25 kernel-modules 4.9.4-201.fc25 -> 4.9.5-200.fc25 kubernetes 1.4.7-1.fc25 -> 1.5.2-2.fc25 kubernetes-client 1.4.7-1.fc25 -> 1.5.2-2.fc25 kubernetes-master 1.4.7-1.fc25 -> 1.5.2-2.fc25 kubernetes-node 1.4.7-1.fc25 -> 1.5.2-2.fc25
I'll give a link to the bodhi update when it is submitted.
Dusty
On 01/20/2017 08:22 PM, Josh Berkus wrote:
On 01/20/2017 08:19 PM, Dusty Mabe wrote:
This sounds like dns on your node is broken, which is different than the issue we were seeing before (which was a connection issue between containers running on the same node). Can you check your /etc/resolv.conf to make sure it has good information in it?
Never mind, this was the typical issue that the default kube-ansible Flannel IP address range overlaps with default AWS internal IP address ranges. Just one more thing for me to fix with that playbook.
DNS test passed, adding karma now.
Note that I did get an error testing with Guestbook, pulling the redisslave image. This appears to be unrelated to anything in the recent bugs:
Error syncing pod, skipping: failed to "StartContainer" for "slave" with ErrImagePull: "image pull failed for gcr.io/google_samples/gb-redisslave:v1, this may be because there are no credentials on this request. details: (manifest unknown: Failed to fetch "v1" from request "/v2/google_samples/gb-redisslave/manifests/v1".)"
... most likely, that image doesn't exist anymore.
On 01/20/2017 10:55 AM, Dusty Mabe wrote:
Please test it out so that we can get the new kernel karma'd as soon as possible:
ostree remote add --set=gpg-verify=false kerneltest https://dustymabe.fedorapeople.org/repo/ rpm-ostree rebase kerneltest:fedora-atomic/25/x86_64/docker-host
OK, running this I get a failure at certificate configuration:
TASK [kubernetes : Run create cert script on master] *************************** fatal: [172.31.36.80]: FAILED! => {"changed": true, "cmd": ["/usr/local/libexec/kubernetes/make-ca-cert.sh"], "delta": "0:00:20.840371", "end": "2017-01-21 04:02:00.774712", "failed": true, "rc": 6, "start": "2017-01-21 04:01:39.934341", "stderr": "curl: (6) Could not resolve host: storage.googleapis.com", "stdout": "", "stdout_lines": [], "warnings": []}
And indeed, when I log into each instance, it's unable to resolve storage.googleapis.com, or for that matter anything else.
-bash-4.3# ping www.yahoo.com ping: www.yahoo.com: Name or service not known
I'll check on a "clean" system which doesn't have a halfway completed kubernetes-ansible deploy on it. But for now, my verdict is that DNS is still broken.
On 01/20/2017 11:13 PM, Josh Berkus wrote:
On 01/20/2017 10:55 AM, Dusty Mabe wrote:
Please test it out so that we can get the new kernel karma'd as soon as possible:
ostree remote add --set=gpg-verify=false kerneltest https://dustymabe.fedorapeople.org/repo/ rpm-ostree rebase kerneltest:fedora-atomic/25/x86_64/docker-host
OK, running this I get a failure at certificate configuration:
TASK [kubernetes : Run create cert script on master]
fatal: [172.31.36.80]: FAILED! => {"changed": true, "cmd": ["/usr/local/libexec/kubernetes/make-ca-cert.sh"], "delta": "0:00:20.840371", "end": "2017-01-21 04:02:00.774712", "failed": true, "rc": 6, "start": "2017-01-21 04:01:39.934341", "stderr": "curl: (6) Could not resolve host: storage.googleapis.com", "stdout": "", "stdout_lines": [], "warnings": []}
And indeed, when I log into each instance, it's unable to resolve storage.googleapis.com, or for that matter anything else.
-bash-4.3# ping www.yahoo.com ping: www.yahoo.com: Name or service not known
I'll check on a "clean" system which doesn't have a halfway completed kubernetes-ansible deploy on it. But for now, my verdict is that DNS is still broken.
This sounds like dns on your node is broken, which is different than the issue we were seeing before (which was a connection issue between containers running on the same node). Can you check your /etc/resolv.conf to make sure it has good information in it?
On 01/20/2017 08:19 PM, Dusty Mabe wrote:
This sounds like dns on your node is broken, which is different than the issue we were seeing before (which was a connection issue between containers running on the same node). Can you check your /etc/resolv.conf to make sure it has good information in it?
Yah, it's the same as the resolv.conf for the ansible node, where DNS is working.
-
Dusty Mabe -
Josh Berkus