This is an update to the order in which we have the new mock methods.

Removed comment and added comment to exported mock helper.

This is to add two new tests which will cover the new logic where the
submit route53 changes function can error if any one of the updates
fails for any given batch in any given zone. Additionally, there is now
a test to check that the application does not try and create a set of
entries if the total number of changes associated with a given name is
greater than the total number of allowed changes per batch.

This is to change the way batching works when using the aws provider.
Originally, batching would take the first n records you want to update
and perform the desired actions on those records as part of a sync. It
would then wait for the configured sync period and take the first n
records again and sync them. The issue with this is that when you are
using the TXT registry with a custom prefix, the updates can sync a TXT
record and not the accompanying A/CNAME record. This causes external-dns
to get out of sync with what is created and what the current state
actually is. This update uses the same idea of batching, however, rather
than stopping after the first batch until the next run, batching will
now have a separate batch interval which controls the interval between
each batch in the same sync period. This allows external-dns to fully
sync with route53 as part of each sync and can then know that the state
is complete.

Fixes https://github.com/kubernetes-incubator/external...

* add Istio Gateway Source

* add documentation for Istio Gateway Source

* make both istio namespace and ingress gateway service configurable

* prefix gateway types, constructors, and flags with 'istio-'

* fix: add missing sources to source flag docs

CRD source based on getting endpoints from CRD

Alibaba Cloud Provider add zone info to deployment

Add filter by service type feature

Add Alibaba Cloud Provider

* Add generic metrics for Source & Registry Errors

Change-Id: Ie145f200f815712ec372fca1c897bee3710b045b

* add label to distinguish read errors

Change-Id: I9fb1295c6fb3b2c5814ba942b4af91e1fca1c2c1

* detect write errors

Change-Id: I524360923359a5aebe6224c4e32553b138dfbdab

* revert back to label less metrics

Change-Id: Id689e0ba8c3a40a520f5af73219a4e202c167e03

* fixup Gopkg.lock

Change-Id: I3e3fdc8ad792128421b92db587bdde6e788fea58

Updating changelog for new release v0.5.5

Dyn: cache records per zone using zone's serial number

exoscale: bump version to 0.11

Set Linode user agent

Configure req timeout calling k8s APIs

Signed-off-by: Yoan Blanc <yoan.blanc@exoscale.ch>

When running in a pod sometimes the request to get ingreses/services
stalls indefinitely. A simple pod restart fixes this. Hard to reproduce
but I got lucky and did thread dump which revealed a gorouting blocked
on call to k8s.

What's new is a `--request-timeout` flag that makes requests to k8s
bounded in time. The default is 30s - this may cause some deployments
with a slow api-server to timeout.

adding assume role to aws_sd provider

Linode Provider Implementation

The only thing preventing use of a smaller interval is the API request
limit. Caching records by the zone's serial number would let users set a
smaller interval and still not hit Dyn's request limit if there aren't
any changes to the zone since the last time external-dns has run.

In a dynamic setting bigger interval is still the main throttling
mechanism.