Currently, we run the e2e tests in whatever order readdir happens to
return, which is random on some filesystems, name sorted on others,
create order on others, etc. Eventually, we may want to be
automatically hermetic between e2e tests (especially as we introduce
more resource destructive tests), but until then, it would be useful
if we permute the test order randomly between runs to ensure that
developers don't accidentally rely on a particular order. This
introduces a form of forced hermeticism, since improper state cleanup
from one test may not perturb a given test, but there's probably *a*
test in the suite that the order will perturb, so the RNG will find
that order eventually.
Adds logging of the generated seed, and an --orderseed argument that
can be used to re-run in the same order. Also sorts the pass/fail list
now for easier human reading.
Watches are often established via long-running HTTP GET requests which
will inevitably time out during the normal course of operations. When
the watches time out, an io.EOF or an io.ErrUnexpectedEOF will bubble
up to client components such as StreamWatcher and Reflector. Treat EOF
as a clean watch termination. Treat ErrUnexpectedEOF as a less-clean
but non-fatal watch termination and log the event at the warning level.
This greatly reduces the amount of log noise generated during what is
ultimately normal operation, and adds the flexibility for the operator
to make a distinction between the EOF conditions if so desired (by
adjusting the logging level).
A few reasons:
- Mux is already widely used in the codebase to refer to a http handler mux.
- Original meaning of Mux was something which sent a chose one of several inputs to
and output. This sends one output to all outputs. Broadcast captures that idea
better.
- Aligns with similar class config.Broadcaster (see #2747)
Don't log an error when Accept failed because the interface (portal)
was just removed.
Don't pass around a pointer to a serviceInfo since another thread
deletes those. Instead, just check if service name is still in the
service map.
Delete the locking on the serviceInfo object since it is only used
by the "main" proxier thread.
