Dyn will still match them, even while they're empty before we've had a
chance to add the respons pools to them which is BAD and caused a
medium-size outage (thankfully not as bad as it could have been.) Ideally
we'd use publish=False and stage things, but that seems broken in the client
lib, there's no way to send publish=N. I also tried sending the
response_pool_ids as part of the create calls and response pool config if
one didn't exist, but neither of those routes worked :-(
This implements it transparently at Record level. Providers that need things to
be chunked (seems to just be Route53 an Dyn) switch to use `chunked_values`, but
everything else can stick with `values`. I've run through each provider I have
access to verifying that things operate as expected/required. OVH and Azure are
untested.
- adds lenient flag to Record.new, problems during validation are just
warnings if it's true
- target populate calls during the plan phase pass lenient=True
- make all of the provider.populate call logging consistent including both
target and lenient
- add source=self to Record.new in a few places that were missing it
More thorough unit tests while I'm in here. Ended up doing some hacks/monkey
patching of DSFMonitor as the client library's object doesn't seem to be fully
functional/useful and has inconsitent behavior.
Supports ALIAS for Dnsimple, Dyn, Ns1, and PowerDNS. Notes added to readme about
some of the quirks found while working with them. TTL seems to mostly be
accepted on ALIAS records so it has been added back, what it means seems to vary
across providers, thus notes.
