Change:
"testing" "github.com/GoogleCloudPlatform/kubernetes/pkg/api" <ins> "github.com/GoogleCloudPlatform/kubernetes/pkg/util" </ins> ) <ins> func TestFindPort(t *testing.T) { manifest := api.ContainerManifest{ Containers: []api.Container{ { Ports: []api.Port{ { Name:          "foo", ContainerPort: 8080, HostPort:      9090, }, { Name:          "bar", ContainerPort: 8000, HostPort:      9000, }, }, }, }, } port, err := findPort(&manifest, util.IntOrString{Kind: util.IntstrString, StrVal: "foo"}) expectNoError(t, err) if port != 8080 { t.Errorf("Expected 8080, Got %d", port) } port, err = findPort(&manifest, util.IntOrString{Kind: util.IntstrString, StrVal: "bar"}) expectNoError(t, err) if port != 8000 { t.Errorf("Expected 8000, Got %d", port) } port, err = findPort(&manifest, util.IntOrString{Kind: util.IntstrInt, IntVal: 8000}) if port != 8000 { t.Errorf("Expected 8000, Got %d", port) } port, err = findPort(&manifest, util.IntOrString{Kind: util.IntstrInt, IntVal: 7000}) if port != 7000 { t.Errorf("Expected 7000, Got %d", port) } port, err = findPort(&manifest, util.IntOrString{Kind: util.IntstrString, StrVal: "baz"}) if err == nil { t.Error("unexpected non-error") } port, err = findPort(&manifest, util.IntOrString{Kind: util.IntstrString, StrVal: ""}) expectNoError(t, err) if port != 8080 { t.Errorf("Expected 8080, Got %d", port) } port, err = findPort(&manifest, util.IntOrString{}) expectNoError(t, err) if port != 8080 { t.Errorf("Expected 8080, Got %d", port) } } </ins> func TestSyncEndpointsEmpty(t *testing.T) { serviceRegistry := MockServiceRegistry{} podRegistry := MockPodRegistry{}

Discussion:
What would you like to be : We'd like to have the Prometheus stack () running in our scalability tests. Why is this needed: There are couple of reasons: will simplify writing SLI assertions/tests that are based on metrics not necessarily exported on master. Some examples here are the new In-Cluster Network Programming Latency SLI (exported in kube-proxy) or soon to be implemented RTT SLI where the metric will be exported in regular pods (probes). With Prometheus stack, collecting and aggregating such metrics is very simple. -prometheus provides many useful metrics about the state of the cluster, such metrics might be invaluable when debugging scalability test failures. mimics what customers do in their cluster, making the test setup more realistic.
/sig scalability
/assign
The GCE 5K Node Performance test with enabled Prometheus completed successfully. We can enable Prometheus in all tests.
Looks like kubemark-500 has some issue, test fails often with Kubemark-5000 also failed once with Will disable Prometheus in kubemark, will work on fixing it when I'm back from my vacation.
For the first kind of the failure that kubemark-500 suffered from, i.e. the root cause is Looks like the token for the "prometheus-operator" service account was not ready, as we can see in the logs it was created after the POST to create the servicemonitor was called.
It looks like the second failure (kubemark-5000) was caused by the prometheus-k8s pods not scheduled by the kube-scheduler. This is strange but may be related to other issues we had. Hard to investigate what really happened there, will leave it for now. Will re-enable prometheus tomorrow and will see if it happens again.
Closing, as this is basically done in a minimal version. Other improvements will be tracked in separate issues. /close
Closing this issue. <detailsIn response to : Closing, as this is basically done in a minimal version. 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