Update the README

README.md

@@ -72,7 +72,7 @@ A higly configurable interface to pass single/multiple records to the DNS host.
     sprout  604800 IN NAPTR 1 1 "S" "SIP+D2T" "" _sip._tcp.sprout
     _sip._tcp.sprout 604800 IN SRV 0 0 5054 sprout-1
     sprout-1 604800 IN A 10.0.10.254
-    
+
 
 > Note: this will be moving to a JSON datastructure in the near future. Parsing
 > an array of strings when integrating with providers other than bind is not
@@ -94,6 +94,7 @@ None of the 3rd party provider support has been added save for the provider arch
 
 **provider**: Specify the underlying provider. Defaults to **bind** 
 
+**proivider_keys**: Used to warehouse provider specific configuration. For an example usecase, see the [rt53](contrib/rt53/README.md) docs.
 
 # Contact Information
 

contrib/rt53/README.md

@@ -14,7 +14,7 @@ You must provide the charm's `provider_keys` directive with at least the 2 keys
 bound to an account with authorization to access and modify Rt53 resources.
 
     juju set dns provider="rt53"
-    juju set dns provider_keys="AWS_ACCESS_KEY|1234 AWS_SECRET_KEY|abc123def"
+    juju set dns provider_keys="AWS_ACCESS_KEY_ID|1234 AWS_SECRET_ACCESS_KEY|abc123def"
 
 By setting the provider to rt53, and providing the requisite Access keys you are
 now ready to start the integration of your Juju Environment w/ AWS Rt53 domains.
@@ -34,12 +34,26 @@ The record types this provider will accept are marked in the
 `contrib/rt53/provider.py` initializer. This helps cut down on attempting to
 make API calls we're not sure how to handle.
 
-    self.record_types = ['A', 'CNAME', 'NS', 'SRV', 'TXT']
+    self.record_types = ['A', 'CNAME']
 
 To date, we support the most common DNS record entries youll encounter. Should
 you need another, PR's are welcome - but you'll need to include a test that
 stubs the AWS Rt53 API with a fixture to illustrate usage.
 
+### Known Caveats
+
+The DNS charm does not actively reconfigure from one provider to another. This
+feat of configuration requires revisiting the core logic of the charm and
+implementing additional calls to determine if the underlying DNS provider has
+changed.
+
+When switching providers. you have two options presently:
+
+- Attach to the charm over debug-hooks during an event, and manually run the
+  install/config-changed hooks.  `hooks/install  && hooks/config-changed`
+
+- Redeploy the service
+
 
 ### Bugs / Feature Requests