Change:
Currently the 1.6 -1.5 downgrade jobs are failing: Looks like this could be for different reasons.
I'll fix quota for the GKE test. It was failing for unrelated reasons yesterday and leaked IPs.
From etcd log: From what I understand, we cannot rollback etcdv3 + proto data store encoding. We can rollback etcdv3 + json data store encoding if we use the updated etcd image that has the rollback tool in it. Details look to be in I'll start playing around with this to see if I can get it working. cc
just merged - will review results in morning before closing
I'm afraid this only uncovers another issue. Last I spoke with he said he was working on something for that.
any luck?
Also is probably needed. Thanks for helping investigate that.
looks like still failing but with different errors this time. I'm seeing: https://k8s- and https://k8s-
thoughts? This is a release blocker
your comment was before merged. Most recent failure is significantly different but I'm finding the output hard to read. I'm talking to to decipher: https://k8s-
I tried to create a 1.6 cluster and then downgrade the master to 1.5, but the downgraded master never responded (waited for hours). The steps I run:
You're hitting the downgrade issue , there is no way to downgrade etcd from v3 storage version to v2. has some env variables that allow you to deploy etcd with v2 for the 1.6 cluster.
We still aren't passing the right variables into the kube-env. In particular, there's no value for , so we end up running the 2.2.1 image which doesn't contain the migration script nor the rollback tool. I can try to reproduce this myself. cc in case we are doing something dumb WRT the environment.
were you able to reproduce?
Looks like is now failing with the same error as , progress! https://k8s- Now it looks like has the static IP allocation issue: https://k8s- could you look into the quota on this one too? It looks like whatever you did fixed the other suite.
I'm not looking at this anymore, ping me if you need me.
I'm willing to count https://k8s- as a pass...
Was decided at burndown that these are test failures and don't need to block 1.6
Doesn't look like we're having quota issues anymore. /unassign
The ingress upgrade test continues to leak static addresses when the disruption fails. The test's func is never called. Please see
This seems to be affecting many PRs at the moment. Is there a clear owner here?
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale

Discussion:
} func masterUpgradeGCE(rawV string) error { <ins> env := os.Environ() // TODO: Remove these variables when they're no longer needed for downgrades. if TestContext.EtcdUpgradeVersion != "" && TestContext.EtcdUpgradeStorage != "" { env = append(env, "TEST_ETCD_VERSION="+TestContext.EtcdUpgradeVersion, "STORAGE_BACKEND="+TestContext.EtcdUpgradeStorage, "TEST_ETCD_IMAGE=3.0.17") } </ins> v := "v" + rawV <del> _, _, err := RunCmd(gceUpgradeScript(), "-M", v) </del> <ins> _, _, err := RunCmdEnv(env, gceUpgradeScript(), "-M", v) </ins> return err }