You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@libcloud.apache.org by "John Carr (JIRA)" <ji...@apache.org> on 2013/01/30 22:31:13 UTC

[dev] [jira] [Updated] (LIBCLOUD-281) Support Gandi DNS

     [ https://issues.apache.org/jira/browse/LIBCLOUD-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

John Carr updated LIBCLOUD-281:
-------------------------------

    Attachment: 87.diff

Add patch for PR 87 - adds Gandi DNS Driver
                
> Support Gandi DNS
> -----------------
>
>                 Key: LIBCLOUD-281
>                 URL: https://issues.apache.org/jira/browse/LIBCLOUD-281
>             Project: Libcloud
>          Issue Type: Improvement
>          Components: DNS
>            Reporter: John Carr
>         Attachments: 87.diff
>
>
> Initial implementation of this is here:
> https://github.com/Jc2k/libcloud/compare/trunk...gandi-dns
> Not quite finished yet, but am posting early in case there are any other Gandi fans who had similar plans.
> As usual, hit a few snags.
> I'm not sure the best way to expose the Gandi test system (a staging instance of their infrastructure). Right now I have just completely overridden the API_URL while I work on the thing but want this to be a kwarg or want the API_URL to be a member of the class or something similar so its easy to run tests against my non-prod account. Any preference?
> Any record updates are at least 3 http calls - create a new version of the zone, make the change, update the active version of the zone. Unfortunately creating a new version changes all of the record ids making the ID next to useless. I think I am going to hide the record id from libcloud users and use type:name as the record id. If that's OK I should have something useful on Sunday. (A side note is that the changes are not active until the final call, so it's not quite as bad as it seems).
> The upstream docs also seem to be incorrect - the signature for the update method return value seems wrong. Will flag that upstream.
> At some point as a seperate ticket I am going to try and get the xmlrpc transport to reuse more of the libcloud HTTP stack - LIBCLOUD_STDERR doesn't work at present and i'm guessing it won't have the hardened SSL handling either.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira