aaron-sierra opened a new issue, #2065:
URL: https://github.com/apache/libcloud/issues/2065

   ## Summary
   
   While comparing the LuaDNS driver to other DNS drivers, I noticed that there 
are a number of subtly incompatible implementations sharing an otherwise common 
API which limit portability between providers.
   
   For example, some drivers use empty strings to represent apex/naked records 
(e.g. example.com.), while others use `None`. Both categories of drivers employ 
explicit unit testing to confirm their preferred `Record.name` value.
   
   Similarly, some drivers want `Record.name` as a rooted FQDN (e.g. 
`"host.example.com."`), others as an unrooted FQDN (e.g. `"host.example.com"`), 
and still others as a bare host name (e.g. `"host"`).
   
   ## Proposal
   
   Assuming that the **libcloud** DNS class/driver APIs are intended to provide 
a consistent interface for users and drivers should provide logic within 
themselves to adapt the common objects and interfaces for their respective 
services, I propose the following:
   
   1. Add common logic to the `Record` class to standardize apex/naked record 
names on the empty string (or `None`).
   2. Add common logic to the `Record` class to enforce that `.name` represents 
the host name, without the domain suffix. This would likely involve adding new 
`.fqdn` and `.rooted_fqdn` properties to expose unrooted and rooted FQDN 
strings, respectively.
       - For the sake of compatibility with existing uses, `__init__()` would 
accept a rooted/unrooted FQDN or a bare host name.
   3. Refactor `Record.update()` to leverage common code to enforce the items 
above, while being kind to existing users.
   4. Expand DNS driver unit tests to validate data sent *to* the provider. 
Presently, it appears that testing primarily validates the formatting of 
(canned) data received *from* a provider.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscr...@libcloud.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Reply via email to