Uploaded image for project: 'Libcloud'
  1. Libcloud
  2. LIBCLOUD-281

Support Gandi DNS



    • Improvement
    • Status: Closed
    • Major
    • Resolution: Fixed
    • None
    • 0.12.1
    • DNS
    • None


      Initial implementation of this is here:


      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.


        1. 87.diff
          52 kB
          John Carr



            kami Tomaz Muraus
            jc2k John Carr
            0 Vote for this issue
            2 Start watching this issue