The Secret must be in the same namespace of the Pods into which
their contents are mounted.

The verification script intermittently gets a 503 status if requests
are sent to "soon", even after waiting for the Varnish Services to
become ready. It doesn't appear to happen if we wait a few seconds
longer.

For now, wait longer until we run the verification test case. In the
long run, we should investigate why the configuration is not actually
ready when the Ready state is reached.

Since the controller now interacts with the headless Service that
defines the admin ports, it can no longer find the http port in
that Service definition. This is needed to configure the Varnishen
as backends for one another.

Search for all Services in the same namespace that define the same
selector as the admin Service (and hence are configured for the
same Pods). We then search for the http port in the Endpoints of
those Services.

... which determines if a Service defines the admin interfaces for
a Varnish Service that implements Ingress. We don't have to query
the Endpoints (which often don't exist yet when the Service is new),
because the service port definitions are in the Spec.

This means that the function doesn't have to return a possible
error, which simplifies the calling code. In particular,
filterVarnishIngSvcs(), which filters a slice of Services for those
for which isVarnishIngSvc() is true, does not have to pass along
the error return value. That in turn simplifies more calling code.

- The varnish controller deleted a service from its
map under the wrong conditions.

- Not an error if there are no Endpoints for the
Service when the Delete event is synced -- they
may already be gone.

- Varnish and haproxy controllers delete the service
from their maps before any other sync actions are
taken -- otherwise error returns may prevent the
deletion from ever happening.

- Permanent network errors on attempts to communicate
with the admin interfaces are ignored (do not cause
re-queue), since the instance may be gone.

The admin Service was missing, and the varnishadm port was still
defined for the Varnish Service.

It had a newline after the password string.

Builds will fail with the old version as the package is not available
on all mirrors anymore.

This was a case of golang's wonderfully confusing nil pointer vs
nil interface.

Feedback on haproxy issue 590 showed a working method after all --
haproxy has a listener for dataplane as a backend, and the listener
executes basic auth. This way, the userlist insecure-password config
can be set from the env variable, passed to the container with the
downward API.

See: https://github.com/haproxy/haproxy/issues/590

Setting a password in haproxy.cfg from an environment variable
apparently doesn't work, see: https://github.com/haproxy/haproxy/issues/590

The idea was to set the password in a Secret, whose value is passed
into the haproxy container as an env variable, using the downward API.
This will have to be redesigned.

For now we use the fixed password, so that further development is not
blocked.

WIP: Service deletion currently not working, and testing is otherwise
incomplete.

WIP -- testing currently incomplete.

WIP: undeployment currently not working correctly.