Change:
go run hack/e2e.go -v --test --check_node_count=false --test_args="--host=http://127.0.0.1:8080" --ginkgo.focus="Secrets" ``` <ins> ### Version-skewed and upgrade testing We run version-skewed tests to check that newer versions of Kubernetes work similarly enough to older versions.  The general strategy is to cover the following cases: 1. One version of `kubectl` with another version of the cluster and tests (e.g. that v1.2 and v1.4 `kubectl` doesn't break v1.3 tests running against a v1.3 cluster). 1. A newer version of the Kubernetes master with older nodes and tests (e.g. that upgrading a master to v1.3 with nodes at v1.2 still passes v1.2 tests). 1. A newer version of the whole cluster with older tests (e.g. that a cluster upgraded---master and nodes---to v1.3 still passes v1.2 tests). 1. That an upgraded cluster functions the same as a brand-new cluster of the same version (e.g. a cluster upgraded to v1.3 passes the same v1.3 tests as a newly-created v1.3 cluster). [hack/e2e-runner.sh](http://releases.k8s.io/HEAD/hack/jenkins/e2e-runner.sh) is the authoritative source on how to run version-skewed tests, but below is a quick-and-dirty tutorial. ```sh # Assume you have two copies of the Kubernetes repository checked out, at # ./kubernetes and ./kubernetes_old # If using GKE: export KUBERNETES_PROVIDER=gke export CLUSTER_API_VERSION=${OLD_VERSION} # Deploy a cluster at the old version; see above for more details cd ./kubernetes_old go run ./hack/e2e.go -v --up # Upgrade the cluster to the new version # # If using GKE, add --upgrade-target=${NEW_VERSION} # # You can target Feature:MasterUpgrade or Feature:ClusterUpgrade cd ../kubernetes go run ./hack/e2e.go -v --test --check_version_skew=false --test_args="--ginkgo.focus=[Feature:MasterUpgrade]" # Run old tests with new kubectl cd ../kubernetes_old go run ./hack/e2e.go -v --test --test_args="--kubectl-path=$(pwd)/../kubernetes/cluster/kubectl.sh" ``` If you are just testing version-skew, you may want to just deploy at one version and then test at another version, instead of going through the whole upgrade process: ```sh # With the same setup as above # Deploy a cluster at the new version cd ./kubernetes go run ./hack/e2e.go -v --up # Run new tests with old kubectl go run ./hack/e2e.go -v --test --test_args="--kubectl-path=$(pwd)/../kubernetes_old/cluster/kubectl.sh" # Run old tests with new kubectl cd ../kubernetes_old go run ./hack/e2e.go -v --test --test_args="--kubectl-path=$(pwd)/../kubernetes/cluster/kubectl.sh" ``` </ins> ## Kinds of tests We are working on implementing clearer partitioning of our e2e tests to make

Discussion:
Data as of June 3rd, 9:00 PM Eastern. Latest data can be found here: Prow link to the 2 jobs: * Additional Context:
/sig storage cc
I'm working on , it's hard to get a job yaml right at the first time. I'll check iscsi. /assign
/triage accepted /kind failing-test
ci-kubernetes-e2e-storage-kind-disruptive fixed: has 1 green run pull-kubernetes-e2e-storage-kind-disruptive fixed: , it fails when it should fail, it's green otherwise, I'll continue with iscsi.
/reopen it's still red, but at least it installs now:
Reopened this issue. <detailsIn response to : /reopen it's still red, but at least it installs now: Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
e2e-gce-iscsi-serial job passes now: e2e-gce-iscsi is getting greener: I'll let it run for few more days to see if today's failures are flakes. /reopen
Reopened this issue. <detailsIn response to : It's getting greener: /reopen </details
iscsi-serial is green: