Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provider request: GoDaddy #145

Closed
rnhurt opened this Issue Jun 19, 2017 · 15 comments

Comments

Projects
None yet
4 participants
@rnhurt
Copy link
Contributor

rnhurt commented Jun 19, 2017

I would like to add my request for GoDaddy support. It looks like they have a pretty good REST API and some tips to get started. Both DNS and Registrar support would be good to have.

BTW: I tried to take a stab at adding a provider but my Go skills are nearly non-existent. :(

@tlimoncelli

This comment has been minimized.

Copy link
Contributor

tlimoncelli commented Jun 19, 2017

Thanks for the request and the links to the API stuff. I've added this to our "list of requested providers" and linked to this Github Issue. If someone picks this project up, we'll re-open this ticket.

By the way... other people with little Go experience have written providers. You basically copy a provider with a similar API and go from there. We'd be glad to help you with any questions along the way.

@rnhurt

This comment has been minimized.

Copy link
Contributor Author

rnhurt commented Jun 22, 2017

So, I'm trying to get something, anything, working and am hitting an early snag. I've followed the directions and created a new providers/godaddy/godaddyProvider.go file but it looks like the build is ignoring it. I've even injected syntax errors into my code and go build completes without complaining. Also, I get this when I tried to test my code:

$ ./dnscontrol preview
2017/06/21 22:55:20 main.go:132: Error creating dsps: DSP type GODADDY not declared

NOTE: One suggestion I have to help newbies would be to create a working "example" provider file instead of telling us to copy one of the other files. This gives us a clean place to start without a lot of overhead and allows us to replace functions with actual, working code in a piecemeal manor.

@captncraig

This comment has been minimized.

Copy link
Member

captncraig commented Jun 22, 2017

Ah, that is a bit hidden, but you need to add your package to all.go to get it linked to the rest of the code.

@rnhurt

This comment has been minimized.

Copy link
Contributor Author

rnhurt commented Jun 22, 2017

Hmmm... my provider is listed with the other providers in the all.go file, but I'm still not able to get it to fail to build (or actually use my godaddy provider either). Any other hints?

....
_ "github.com/StackExchange/dnscontrol/providers/route53"
_ "github.com/StackExchange/dnscontrol/providers/godaddy"
)

@captncraig

This comment has been minimized.

Copy link
Member

captncraig commented Jun 22, 2017

Do you have a branch on a fork I can take a look at?

@rnhurt

This comment has been minimized.

Copy link
Contributor Author

rnhurt commented Jun 22, 2017

I do now: https://github.com/rnhurt/dnscontrol/tree/godaddy_dns

I should have done this first so you could see what I'm doing.

@tlimoncelli

This comment has been minimized.

Copy link
Contributor

tlimoncelli commented Jun 22, 2017

If I check that out ~/src/github.com/rnhurt/dnscontrol I get the same problem.

If I check that out as ~/src/github.com/StackExchange/dnscontrol then it compiles.

Maybe I don't understand how vendoring works but that seems odd.

@pmoroney

This comment has been minimized.

Copy link
Contributor

pmoroney commented Jun 22, 2017

I believe that is because the import paths are not relative to the local repo. So if it is trying to import github.com/StackExchange/dnscontrol/providers/godaddy but that actually exists in github.com/rnhurt/dnscontrol/providers/godaddy it won't load

@rnhurt

This comment has been minimized.

Copy link
Contributor Author

rnhurt commented Jun 22, 2017

Ah, I think I have it now. My problem was two fold; both the location of my source code and the pathing of the provider was wrong. Being a non-Go programmer I didn't realize that it was sensitive to where your source code was located. Once I moved my code into my GOPATH directory things started to change for the better; at least the build was failing now. 😄

The next step was to localize the paths in all.go as well as main.go to use github.com/rnhurt/dnscontrol/providers instead of the default github.com/StackExchange/dnscontrol/providers. My code still doesn't work but at least it compiles now. 😄 However, this pathing thing seems wrong. Does everyone else upload their code to the StackExchange repo before compiling it?

@pmoroney

This comment has been minimized.

Copy link
Contributor

pmoroney commented Jun 22, 2017

@captncraig

This comment has been minimized.

Copy link
Member

captncraig commented Jun 22, 2017

Yeah, all of the files really need to live under $GOPATH/src/github.com/stackexchange/dnscontrol, or else you have to change like every file. Best policy is to keep it there, and add separate remotes for each fork.

@rnhurt

This comment has been minimized.

Copy link
Contributor Author

rnhurt commented Jun 25, 2017

I seem to be making good progress; I can talk to the GoDaddy API and get a list of records. 😄 Now I'm working on building the diff and am getting a weird panic. What does it mean when the error is "DUPLICATE E_RECORD FOUND"? I can't seem to find a duplicate record at all, it just looks like it's complaining if there are two records of any type (A, CNAME, etc.) regardless of what the Target is.

panic: DUPLICATE E_RECORD FOUND: { CNAME} @. 3600

UPDATE
I think I see the problem. GoDaddy uses the "@" to refer to the domain in CNAME records. So, I have something like this in my domain (below) and when I feed it to the diff code it doesn't know anything about the name and just sees the "@"

ftp	3600	IN	CNAME	@
www	3600	IN	CNAME	@

I guess my question is: should the provider automatically convert those "@" entries to the domain name?

ftp	3600	IN	CNAME	mydomain.com
www	3600	IN	CNAME	mydomain.com

Also, it looks like the diff code is already doing something similar when I create models.RecordConfig records from my dnsconfig.js file. Is that what is supposed to happen?

@tlimoncelli

This comment has been minimized.

Copy link
Contributor

tlimoncelli commented Jun 25, 2017

I'm traveling right now but I believe you are in the right direction. The provider should expand @ before sending to diff. When doing updates it can shorten domains to "@" if it wants. The point is that the provider produces a canonical format that diff can use.

P.S. Good work so far! You've come a long way!

@rnhurt

This comment has been minimized.

Copy link
Contributor Author

rnhurt commented Jun 26, 2017

@tlimoncelli

This comment has been minimized.

Copy link
Contributor

tlimoncelli commented Jun 27, 2017

thumbs up!

@tlimoncelli tlimoncelli changed the title GoDaddy Support Provider request: GoDaddy Nov 27, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.