Change:
local REGION=${ZONE%-*} gcloud compute forwarding-rules delete -q --region ${REGION} "${INSTANCE_PREFIX}-default-frontend" || true gcloud compute target-pools delete -q --region ${REGION} "${INSTANCE_PREFIX}-default-frontend" || true <ins> gcloud compute firewall-rules delete guestbook-e2e-minion-8000 -q || true fi } function wait_for_running() { echo "Waiting for pods to come up." local frontends master slaves pods all_running status i pod frontends=($(${KUBECTL} get pods -l name=frontend -o template '--template={{range.items}}{{.id}} {{end}}')) master=($(${KUBECTL} get pods -l name=redis-master -o template '--template={{range.items}}{{.id}} {{end}}')) slaves=($(${KUBECTL} get pods -l name=redis-slave -o template '--template={{range.items}}{{.id}} {{end}}')) pods=("${frontends[@]}" "${master[@]}" "${slaves[@]}") all_running=0 for i in {1..30}; do all_running=1 for pod in "${pods[@]}"; do status=$(${KUBECTL} get pods "${pod}" -o template '--template={{.currentState.status}}') || true if [[ "$status" != "Running" ]]; then all_running=0 break fi done if [[ "${all_running}" == 1 ]]; then break fi sleep 10 done if [[ "${all_running}" == 0 ]]; then echo "Pods did not come up in time" return 1 </ins> fi }

Discussion:
Part of issue . Re-write test in Go, generate unique names for top level resources, ensure test is idempotent, clean up all resources at end of test.
What should we do about this test? The current test in only brings up the guestbook but doesn't even confirm that it is up or tries to connect to any of the ports... Was the point of that test case to test /? Does it make sense to rewrite this test in Go or do we already have more test coverage from e.g. ? If it makes sense to rewrite it in Go, what should we accomplish with this test?
How about a functional test that inserts some names and tries to retrieve them i.e. enough to know that the service has basic functionality?
+1 to an actual functional test. The service is basic enough, it should be straightforward to do the same POST/GET from go that the js on the guestbook homepage does.
and I talked about this and for a while and think that they should remain as tests. This test needs to be improved: it needs to be turned into an actual test (we don't do anything with the service).
has not passed on gce or gke-ci since around 11am this morning (around when this PR was merged). Can you look at the Jenkins logs and try to figure out what is going wrong?
The problem is with guestbook itself not with the test. The frontend cannot connect to redis data base so it returns error response to the user. I created issue for that
I have been 100% absorbed for weeks with my own e2e test so I've not paid much attention to this. Does the test connect to the service via an external load balancer?
Nope. It's using proxy. For example:
Is this a reasonable use of the proxy service? Today told me that the proxy service is fine for contacting cluster-level services (note the dash Brian) but for regular applications we should use some other mechanism (e.g. external load balancer). ?
My first idea was to use ELB but it requires to create also firewall-rules using. I'm not sure if we want to do it.
PR has been reverted by The test is passing for me locally. I'll updated . Is there any chance that using proxy instead of ELB can cause the problem?

Personally, I think -- for now -- using an ELB is fine -- by setting the use external load balancer field in the System specification. I am working on a PR to fix an issue relating to the use of application endpoints using the proxy server (to address issue -- which can bite you if one of the fields of a JSON response contains a field called ).
It sounds to me like there are 2 issues: should the guestbook example make the guestbook app accessible to users? should the test test correctness? I think these are 2 totally different things. The right answer to (1) is clearly external IPs. That's what we want to teach users to do. (2) likely doesn't have the same requirements. Conflating the 2 cases might not be helpful. However, if you want to do that, use the external load balancer, not the proxy.
Yes, I am torn about this too. Another thing to consider is that a test that uses an external load balancer is going to take longer because it takes much longer to create a service with an external load balancer (almost instant with ELB vs. perhaps up to a minute with a load balancer) and then there is a teardown step as well when you delete the service (which deletes the forwarding rules etc.). As a point of principle we should decide if it is an approved use of the proxy mechansim for use in tests in order to make them more lightweight vs. using an ELB.
So there is agreement to use ELB. What about firewall rule? Port 8000 should be opened, I can do it by using gcloud, however it's not provider agnostic operation. Is there any other option for that?
Sadly not: I suggest just using gcloud / making the API calls for the firewall and keep this as a GCE specific test. Which is indeed a shame.
Reopening since the PR was reverted in