@brendanburns @jbeda

What should we do about this test? The current test in hack/e2e-suite/guestbook.sh 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 kubecfg/kubectl?

Does it make sense to rewrite this test in Go or do we already have more test coverage from e.g. test/e2e/basic.go?

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.

@jlowdermilk and I talked about this and #3694 for a while and think that they should remain as kubectl tests. This test needs to be improved: it needs to be turned into an actual test (we don't do anything with the service).

guestbook.sh has not passed on gce or gke-ci since around 11am this morning (around when this PR was merged).

@piosz 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 #5091 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:
FRONTEND_ADDR=https://${KUBE_MASTER_IP}/api/v1beta1/proxy/services/frontend
curl ${FRONTEND_ADDR}/index.php?cmd=get\&key=messages --insecure --user ${KUBE_USER}:${KUBE_PASSWORD}

Is this a reasonable use of the proxy service? Today @bgrant0607 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). @bgrant0607 ?

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 #4588 has been reverted by @roberthbailey

The test is passing for me locally. I'll updated #5091. 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 #4977 -- which can bite you if one of the fields of a JSON response contains a field called status).

It sounds to me like there are 2 issues:

1. How should the guestbook example make the guestbook app accessible to users?
2. How should the guestbook.sh 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:

// Interface is an abstract, pluggable interface for cloud providers.
type Interface interface {
    // TCPLoadBalancer returns a balancer interface. Also returns true if the interface is supported, false otherwise.
    TCPLoadBalancer() (TCPLoadBalancer, bool)
    // Instances returns an instances interface. Also returns true if the interface is supported, false otherwise.
    Instances() (Instances, bool)
    // Zones returns a zones interface. Also returns true if the interface is supported, false otherwise.
    Zones() (Zones, bool)
    // Clusters returns a clusters interface.  Also returns true if the interface is supported, false otherwise.
    Clusters() (Clusters, bool)
}

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 #5088