2m 2m 1 varnish-ingress-controller Warning SyncFailure Error, requeueing: [{172.17.0.11:6081: No known admin secret}{172.17.0.12:6081: No known admin secret}]
2m 2m 6 varnish-ingress-controller Normal SyncSuccess Successfully synced
```
The EventSource (in the ``From`` column) is always
``varnish-ingress-controller``, and the Reason for actions taken after
a notification from the cluster API is ``SyncSuccess`` or
``SyncFailure``.
The Message in the case of ``SyncFailure`` reports the errors. The
addresses shown in the error message (such as ``172.17.0.11:6081`` in
the example) are Endpoints for a Service running Varnish, showing the
admin port (to which the controller connects to issue commands). The
controller attempts to sync all Endpoints belonging to a Varnish
Service, even if errors are encountered along the way, and collects
error reports from each Endpoint into a single message, in the "array"
format shown above.
``requeuing`` indicates that the work item has been placed back onto
the controller's queues, and will be re-attempted (with backoff delays
for repeated errors). The controller always repeats attempts to sync
the state of the cluster until the sync is successful. If there is an
unrecoverable error, such as an error in your configuration that must
be corrected, then the ``SyncFailure`` event will be repeatedly
generated (with backoff delays, and with the aggregation and de-dup of
Events by Kubernetes), and ``SyncSuccess`` will never appear, until
the problem is fixed. It is a good idea to monitor your Event logs for
this situation.
It is not unusual for ``SyncFailure`` to be closely followed by
``SyncSuccess``, as in the example above, if the controller has not
received complete information when it first attempts the sync. In the
example, the controller had received the Ingress configuration before
the Secret needed to connect with the Varnish admin ports, so it was
unable to load configurations to realize the Ingress. The Secret was
received shortly afterward, and then the Ingress could be successfully
synced. If the most recent event is ``SyncSuccess`` shortly after
``SyncFailure``, then probably all is well.
The controller is notified about all Services, Ingresses and so on in
the cluster, by default in every namespace, including components that
have nothing to do with Ingress or Varnish. These are ignored -- for
example, Ingresses without the ``ingress.class`` annotation set to
``varnish``, or Secrets that do not have the label
``app: varnish-ingress``. The controller may generate ``SyncSuccess``
Events for such objects, but in fact it has done nothing for them.
The controller log usually contains a message at the ``INFO`` level
that it has ignored information about a component.
## Varnish Service monitor
When the controller starts, it launches a monitor (a goroutine) that
at regular intervals checks the state of each Endpoint of a Varnish
Service implementing Ingress, and loads the current configuration if
necessary (if for some reason the regular sync operations have not
brought the Varnish instance up to date with the desired state).
By default, the monitor runs every 30 seconds. The interval can be
