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

["Tomaz Muraus (JIRA)" <ji...@apache.org>]

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

Tomaz Muraus resolved LIBCLOUD-281.
-----------------------------------

    Resolution: Fixed
      Assignee: Tomaz Muraus

Thanks! I've merged it into trunk and 0.12.x (http://svn.apache.org/viewvc?view=revision&revision=r1440820) with some minor changes:

- 3.2 compatibility stuff (use xmlrpclib from libcloud.utils.py3, etc.)
- 2.5 compatibility stuff (from __future__ import with_statement)
- minor style stuff
- some missing pep8 stuff
- consistent quoting (use single quotes around strings everywhere)
- don't use builtin function names for variable names (filter -> filter_opts)
                
> 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
>            Assignee: Tomaz Muraus
>         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