This has exposed k8s issue #59822 when we use client-go v6.0.0 for
compatibility with k8s 1.9, when shared informers are stopped as
part of queue shutdown:

https://github.com/kubernetes/kubernetes/issues/59822

This upgrades to use of client-go v6.0.1, but evidently only has the
effect that the problem is intermittent. Occasionally there are panics
due to double channel close. The guarantee of sequential delivery
by a shared informer may also not be honored.

We go forward with these issues, since 1.9 is already out of support,
and will probably start supporting newer k8s versions in the near
term.

Ref #6

Closes #7

Notifications from the API server (Add, Delete, Update) are now
logged at the Debug level.

Details of the monitor loop are also at the Debug level when all is
well, for example when there are no panics, child is running, etc.

Otherwise, messages previously at the Debug level are now at the
Trace level -- logging to trace and debug what the controller is
doing.

This is a best practice for Varnish and should be encouraged by the
example configs.

In order to avoid return(pass) in builtin vcl_recv when
req.http.Authorization is present -- if the backends don't need the
header, it can be deleted. But we need to make sure that it isn't
removed before the auth protocol is executed.

Almost certainly, two Specs are equivalent iff their DeepHashes
are equal (unless we've discovered a SHA512 collision).

Base62 encoding is strictly alphanumeric, so VCL config names (which
include the hash) are very likely safe in any context.

With the "vk8s_ing_" prefix, VCL config names are 47 bytes long.

Closes #14

Download modules when go.mod or go.sum change, not whenever any
source file changed.

Closes #9

Ingress merge is now implemented, and the ingress.class annotation
value is not hard-wired to "varnish".

Closes #26

"varnish" remains as the default value. This makes it possible to
run more than one controller to manage different Varnish Services
(or just choose a different annotation value).

Ref #26

Ref #26
Ref #13

Ref #26
Closes #13

An Ingress definition with ingress.class for Varnish can identify
the Varnish Service that implements its rules:

* If it has the ingress.varnish-cache.org/varnish-svc annotation,
  then the values names the Varnish Service, which may be named
  using namespace/name notation. If the namespace is left out,
  then the same namespace as the Ingress is assumed.

* If the Ingress does not have the annotation, then:

  * If there is only one Varnish-as-Ingress Service in the cluster
    (with label app:varnish-ingress), then that Service implements
    the rules.

  * Otherwise if there is only one Varnish Service in the same
    namespace as the Ingress, then that Service implements the
    rules.

  * Otherwise error

A Varnish Service can define Services from different namespaces as
its backends, if it implements Ingresses from those namespaces which
define those Services as Ingress backends. (Ingresses only define
backends from the same namespace.)

Ingresses can be merged under these conditions:

* No host is specified in more than one Ingress.

* There is no more than one default backends in all of the Ingresses
  to be merged.

If either of these rules are violated, then error.

This resolves the question of merging Ingresses (to be documented in
upcoming commits).

Ref #26
Ref #13

Closes #27

Closes #22

References #22

Closes #1

Supports selecting a match when more than one pattern may match for
regex and prefix matching.