Add SoftLayer as a DomainServiceProvider.

[jamielennox]

This is a fairly simple mapping of calls onto the softlayer-go APIs.

Currently the internationalization integration tests fail with an error
message from the SoftLayer APIs. I'm confident this is something not
supported on the server side rather than a problem with the dnscontrol
provider.

I am not an employee of SoftLayer and this should be considered a
community contribution.

[captncraig]

This is great.

Is there any easy way to get an accout to test this myself? Looking at their website I don't see an easy/cheap way to get access, even to the api sandbox.

I'll be taking a closer look at the code in the coming days.

[jamielennox]

I don't know of any api sandbox.

So they use IBMid for control panel login, so i'm guessing if you got an id [1] and then logged in with it [2] it would create you an account? That would seem reasonable - which is no guarantee.

Alternatively looks like there is a free tier for object storage portion [3] which would at least get you an account, and then see what is needed to add DNS. It's all related on the logged in side.

I will experiment with those as well, but see if that gets you started.

[1] https://www.ibm.com/account/us-en/signup/register.html
[2] https://control.softlayer.com/
[3] http://www.softlayer.com/object-storage

[captncraig]

Wow, I think the storage tip was the key. I think I have a working account now after making my $0 payment. Will test and report back.

[captncraig]

Testing it now. I'll have some feedback soon.

SoftLayer definitely wins the "most inconsistent application of internationalized domain name rules" award in my book.

The web ui does not accept unicode names, but will accept punycoded values and convert them to unicode. The api accepts either, and returns them in unicode form either way, but they don't accept unicode OR punycode for cname targets. Ew. I may file a support ticket to see what they say.

[captncraig]

I made a support ticket, I'll see what they say. At present, I will detect that situation, print a warning, and ignore those records. Our convention is for the provider itself to recognize cases where it fails due to these quirks, and warn the user.

[jamielennox]

That sounds like my experiences with softlayer :) I'll be glad to have dnscontrol in front of it. Interestingly though we may have discovered the cheapest way to host DNS.

If you know what you want those detections/warnings to look like you can let me know, but please feel free to push things to this branch. No point in walking me through all the steps if you know what you want.

[jamielennox]

rebased and fixed the merge conflict. Any word back from SoftLayer?

[captncraig]

Sorry, I'm working on like 10 things at once. Should focus. I made a ticket, I think I finally got them to acknowledge something is wrong.

Until they fix though, I'm ok just skipping those tests. I have some refactors to the tests in a few othed prs. I will get those merged and then make this passing.

Is it ok if I push to your branch?

[jamielennox]

No worries - everyone's working on too many things :)

Of course, push to branch, merge and mangle, rewrite it to make it pretty. Whatever makes things easier.

[tlimoncelli]

@jamielennox Hi! This PR seems to be stalled. I'd rather have it merged with a caveat that certain features aren't supported (with those tests skipped) than wait much longer. I'd like to avoid version drift. If you would please rebase this, I'll merge it.

[jamielennox]

@tlimoncelli Hey, thanks for kicking this along again. There's been a number of changes since i last looked at this but i think i've got it updated correctly and agree, i'd love to get the base functionality merged even if there are errors that need addressed later.

Quick question. I updated it to include SRV handling which is new since my last update.

There's a problem though because softlayer treats service and protocol as two individual required pieces. Therefore i have no idea what to do with the "@" in the tests. My basic testing works with SRV but I've left the capability turned off for now.

[tlimoncelli]

Yes, "@" is technically invalid and a lot of providers reject it. https://github.com/StackExchange/dnscontrol/pull/174/files will change "@" to "_service._protocol". Feel free to make the same change so that it merges easily.

[jamielennox]

Great, I've rebased on top of that now that it has merged.

I did have to change the tests to be _tcp instead of _protocol because softlayer is doing checks for 'known' protocols but it doesn't have a real impact on tests so it should be fine.

[tlimoncelli]

There's one small merge conflict. Fix it and then we should be ready to go!

[jamielennox]

close/reopen seems to be the only way to trigger travis re-run without write on the repo. I'm not sure what the validate.go problem is, that's nothing to do with this patch.

[captncraig]

That failure means you need to run go generate. Its related to some features added in master.

[tlimoncelli]

Can we improve that error message? I also forgot to rub "go generate" recently and it too me a while to realize what the error was.

[jamielennox]

So that file is generated slightly differently under go 1.7.6 (which i was using) to go 1.8.3 (which travis is using) which caused the test to fail. Personal opinion of someone who hasn't done enough golang to know how it's done here, but a generated or recreatable file doesn't need to be in git.

[tlimoncelli]

Thanks for the contribution! It is great to have a new provider added.

Tom

P.S. I agree about "go generate", but the go style is to check them in. I can't win 'em all.