Run etcd 2.0.5 in a pod #6221
Run etcd 2.0.5 in a pod #6221
Conversation
| "containers":[ | ||
| { | ||
| "name": "etcd-container", | ||
| "image": "kubernetes/etcd:2.0.5.1", |
There was a problem hiding this comment.
Is this image on ContainerVM now, or should we get it onto gcr.io?
There was a problem hiding this comment.
This shouldn't be in ContainerVM image since we still support other internal users.
There was a problem hiding this comment.
I'm okay with merge as-is so we can start to get some run-time. Can you file a follow-on issue to move this to gcr.io quickly, though, so all infrastructure is off docker hub?
|
LGTM except that question. |
|
LGTM. Can you run e2e test against this change? |
|
This is revert-of-revert-of-#4442 |
|
Please run e2e tests and post the result here. Network test was failed due to
|
|
Summarizing 5 Failures: Fail] 90mPD It] should schedule a pod w/ a RW PD, remove it, then schedule it on another host (Failed to delete PD) Fail] 90mkubectl update-demo It] should scale a replication controller Fail] 90mDensity It] should allow starting 30 pods per node Apparently pods didnt start up Fail] 90mShell It] tests that services.sh passes Fail] 90mSecrets It] should be consumable from pods Ran 28 of 32 Specs in 5036.928 seconds |
|
My second test run finished INFO: failed to query list of pods from influxdb. Query: "select distinct(pod_id) from /cpu./", Err: expected only one series from Influxdb for query "select distinct(pod_id) from /cpu./". Got [] [It] should schedule a pod w/ a RW PD, remove it, then schedule it on another host |
|
of the two, the first is failing on HEAD as well. The second is failing on a "gcloud compute disks delete" command even after though the pod holding the pd has been killed. I believe these are not related to my change. |
|
@eparis ^ FYI. |
|
Merging to get some soak time in Jenkins. |
|
Great! |
|
Can you check out how he docker-i-fied etcd and see if there is anything here we want to grab/contribute? |
|
sure |
@zmerlynn
This PR should work correctly since we added some robustness to kube-addons creation logic with the retries #6200