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

New Provider HEXONET #373

Merged
merged 1 commit into from Aug 30, 2018

Conversation

Projects
None yet
3 participants
@papakai
Copy link
Contributor

papakai commented Jul 18, 2018

Ready to merge to get 1st release out :)

@tlimoncelli

This comment has been minimized.

Copy link
Contributor

tlimoncelli commented Jul 18, 2018

Looks good so far! Let me know how we may be of assistance.

@papakai

This comment has been minimized.

Copy link
Contributor Author

papakai commented Jul 23, 2018

Sorry, I am pretty busy. I am using the below configuration in a test zone file

var REG_HX = NewRegistrar('hexonet', 'HEXONET');
var DNS_HX = NewDnsProvider('hexonet', 'HEXONET', {
    'default_soa': {
        'master': 'ns1.ispapi.net.',
        'mbox': 'hostmaster.ispapi.net.',
        'refresh': 3600,
        'retry': 600,
        'expire': 604800,
        'minttl': 1440,
    },
    'default_ns': [
        'ns1.ispapi.net.',
        'ns2.ispapi.net.',
        'ns3.ispapi.net.'
    ]
});

Here the questions that came up up to now:

  1. HEXONET is both DNS and Domain Registrar. Thus I assume that EnsureDomainExists, GetRegistrarCorrections and GetDomainCorrections have to be implemented in the registrar module?
    That's at least what I tried to cover based on the things I recognized in other provider modules..
  2. Where have I to check if a DNS Zone exists? I assume in GetDomainCorrections, right?
  3. Wouldn't it make sense to have a method EnsureDNSZoneExists (or EnsureZoneExists) to cover that functionality in the way you're doing it for the domain (EnsureDomainExists)?
  4. How can I access such a DNSProvider default configurations (provided above in config file) so that I can use it for creating the dns zone?
  5. Some TLDs require that a DNSZone is already working before Domains can be successfully registered. Are such cases covered in dnscontrol somehow? if you need examples, let me know.
  6. We would love to also automatically delete a created dns zone again in case the domain registration did NOT work to avoid that such a zone generates unnecessary costs on customer-side. Is it possible to cover such a case through dnscontrol?
  7. How to update an existing SOA record at later time? (especially the mbox config)
  8. We would love to be one of the offically supported registrars. What do we have to cover / to care about to achieve this at the end? At least we could realize OT&E system integration tests that could be run automatically. Something else? Or do you decided case by case?

Sorry for so many questions, any help -> very appreciated.

@tlimoncelli

This comment has been minimized.

Copy link
Contributor

tlimoncelli commented Jul 23, 2018

Here the questions that came up up to now:

  1. HEXONET is both DNS and Domain Registrar. Thus I assume that EnsureDomainExists, GetRegistrarCorrections and GetDomainCorrections have to be implemented in the registrar module?
    That's at least what I tried to cover based on the things I recognized in other provider modules..

Yes, but they don't need to be in the same file. Some modules split out the registrar stuff into a separate file.

To be clear... to be a Registrar, implement all the methods in type Registrar interface (defined in models/provider.go). To be a DNS provider, implement the methods in type DNSProvider interface. A "registrar" is just something that can change the NS records for a domain. It can't actually register, buy, sell, etc. domains. There is a "dnscontrol create-domains" command which is for telling a DNS provider to recognize that a (pre-existing) domain should exist.

If there are confusing points, please either add what you learned to https://stackexchange.github.io/dnscontrol/writing-providers or suggest what you'd like clarified and I'll update the file.

  1. Where have I to check if a DNS Zone exists? I assume in GetDomainCorrections, right?

EnsureDomainExists() is a method of the type DomainCreator interface. It is only used
for the create-zone command.

  1. Wouldn't it make sense to have a method EnsureDNSZoneExists (or EnsureZoneExists) to cover that functionality in the way you're doing it for the domain (EnsureDomainExists)?

I don't understand the question. What are you trying to achieve?

  1. How can I access such a DNSProvider default configurations (provided above in config file) so that I can use it for creating the dns zone?

Providers hardcode default data. for example providers/digitalocean/digitaloceanProvider.go

  1. Some TLDs require that a DNSZone is already working before Domains can be successfully registered. Are such cases covered in dnscontrol somehow? if you need examples, let me know.

No, we don't have to deal with this since we're not going registration or domain buying, just updating the NS records on the parent domain.

  1. We would love to also automatically delete a created dns zone again in case the domain registration did NOT work to avoid that such a zone generates unnecessary costs on customer-side. Is it possible to cover such a case through dnscontrol?

Again, not an issue.

  1. How to update an existing SOA record at later time? (especially the mbox config)

This is an outstanding bug. There is currently no way to do this. It only affects the BIND driver, which has an easy work-around (hand-edit the zone file). The other providers simply auto-generate the SOA and don't let the users control it at all. Considering that nobody but spammers use the mbox data, we're ok with this. Fixing this is being discussed in #352

  1. We would love to be one of the offically supported registrars. What do we have to cover / to care about to achieve this at the end? At least we could realize OT&E system integration tests that could be run automatically. Something else? Or do you decided case by case?

The main point of being "official" is that we will block a new release if the provider isn't working. Unofficial providers, if they are broken, will not block a new release. Currently all the official providers are ones that Stack Overflow depends on in production, therefore we're willing to fix anything that is broken to get a release out. We would need a commitment from a vendor to fix bugs within a certain SLA to make those official. We haven't worked out how to do that.

Our internal CI/CD system runs the integration tests for official providers, plus any that we have a good relationship and can get a no-cost account for testing (OT&E is fine). We'll add you to our internal CI/CD system that runs automated tests. At least we'll know when things break and can report it to you.

Sorry for so many questions, any help -> very appreciated.

Glad to help! I'm excited that you are interested in providing such good support to dnscontrol users!

I haven't had much time to work on dnscontrol lately. It is basically feature-complete for our needs right now.

Tom

@papakai

This comment has been minimized.

Copy link
Contributor Author

papakai commented Jul 25, 2018

Thanks a lot @tlimoncelli for this feedback, very helpful.

Indeed, I was misleaded by documentation or even by naming conventions of e.g. EnsureDomainExists that this is the place where a domain registar could check if a domain exists. if not I understood this to be the place to trigger a registration. This needs some review imo - I'll try to cover this after my module is ready.

This affects my Question 3 where you had problems to follow me. I was searching the method for creating the zone as I though EnsureDomainExists is used to register the domain in case it does not exist. That's why I was wondering why no EnsureZoneExists method is available as it would make sense then. I hope you were able to follow me now :)

Providers hardcode default data. for example providers/digitalocean/digitaloceanProvider.go
I've also hardcoded default data like nameservers, our Backend System applies SOA defaults anyway in case we create the zone but do not provide a SOA RR. But that's not my question :)
What if the customer provides a default_soa and default_ns configuration through his dns config file, is that auto-considered in dnscontrol through an SOA RR update later on or have I to consider it when creating the zone? if I have to care about that when creating the zone -> how do I get access to that configuration in EnsureDomainExists? I hope I could explain my thoughts now in a better way :)
Out of your response to Question 7, I assume that it is bad practice to have such an configuration? As you point to the fact that most of your supported providers don't let users control the SOA.
Our system honestly allows it, but implementing this in dnscontrol isn't a must then imo. Getting the module working is the primary task. Caring about specifics like this, might be an optional target for the future.

As you see, you could clarify a lot of my questions and misunderstandings. again ty a lot!

@papakai papakai force-pushed the hexonet:hexonetProvider branch from 8cc8e5d to ce87321 Jul 25, 2018

@papakai

This comment has been minimized.

Copy link
Contributor Author

papakai commented Jul 25, 2018

Is there an existing module that covers such OT&E tests so that I could have an eye on how this is realized the best way? or do you have any suggestions? Or do you just need a OT&E account (which is for free!) and you care about this?

@papakai

This comment has been minimized.

Copy link
Contributor Author

papakai commented Jul 25, 2018

https://godoc.org/github.com/StackExchange/dnscontrol/providers

DomainCreator should be implemented by providers that have the ability to add domains to an
account. the create-domains command can be run to ensure all domains are present before running preview/push.

That's where EnsureDomainExists appears.

This is what gave me the impression that not-existing domains need to be registered.

@tlimoncelli

This comment has been minimized.

Copy link
Contributor

tlimoncelli commented Jul 25, 2018

Is there an existing module that covers such OT&E tests...

For OT&E we just run the integration tests with the OT&E credentials. Step 7 (Integration Test) in https://stackexchange.github.io/dnscontrol/writing-providers explains how to run the integration tests.

@papakai papakai force-pushed the hexonet:hexonetProvider branch from a0f8ae3 to b3e0722 Jul 26, 2018

@papakai

This comment has been minimized.

Copy link
Contributor Author

papakai commented Jul 26, 2018

@tlimoncelli
when I am in my own fork, I can't run the integration test.
I think this is because I am in namespace github.com/hexonet/dnscontrol and includes point to github.com/dnscontrol/...
I don't want to change these include paths as this breaks the PR finally. Any suggestions on that matter?

go test -v -verbose -provider HEXONET
=== RUN   TestDNSProviders
--- FAIL: TestDNSProviders (0.00s)
        integration_test.go:46: DSP type HEXONET not declared
=== RUN   TestDualProviders
--- FAIL: TestDualProviders (0.00s)
        integration_test.go:46: DSP type HEXONET not declared
FAIL
exit status 1
FAIL    github.com/hexonet/dnscontrol/integrationTest   0.008s

I've created on OT&E account for you guys, how can I forward the account name and password to you guys?

@captncraig

This comment has been minimized.

Copy link
Member

captncraig commented Jul 26, 2018

Regarding the package paths. Go is really bad for forking. You pretty much need to always clone to the canonical path, which is $GOPATH/src/StackExchange/dnscontrol. When I fork go repos, I always clone to the original path, and then add my own fork as a second origin called mine. Then I push branches to my remote. Its kinda crappy, but you end up inadvertantly using the wrong packages or needing to rewrite imports if you do it any other way.

@papakai papakai force-pushed the hexonet:hexonetProvider branch from 7c3d58a to 21cd171 Jul 26, 2018

@papakai

This comment has been minimized.

Copy link
Contributor Author

papakai commented Jul 26, 2018

@captncraig can you please go into more details how to do this exactly?

@captncraig

This comment has been minimized.

Copy link
Member

captncraig commented Jul 26, 2018

  1. Clone to `$GOPATH/src/github.com/StackExchange/dnscontrol
  2. In that repo: git remote add mine git@github.com:hexonet/dnscontrol.git
  3. git push -u mine hexonetProvider
@papakai

This comment has been minimized.

Copy link
Contributor Author

papakai commented Jul 26, 2018

A "registrar" is just something that can change the NS records for a domain. It can't actually register, buy, sell, etc. domains. There is a "dnscontrol create-domains" command which is for telling a DNS provider to recognize that a (pre-existing) domain should exist.

I can't follow here exactly. Can someone please explain this "create-domains" command in detail? For us (and we take this out of the documentation) it still sounds that we could somehow register domains through dnscontrol. As the mouse-over tooltip in feature list says:

This means the provider can automatically create domains that do not currently exist on your account. The 'dnscontrol create-domains' command will initialize any missing domains

Do we have to integrate this somehow? how does this work?

@papakai papakai force-pushed the hexonet:hexonetProvider branch from 4e34efe to 3f22738 Jul 26, 2018

@captncraig

This comment has been minimized.

Copy link
Member

captncraig commented Jul 26, 2018

That is for providers that allow you to create and host arbitrary dns names, but not necessarily register them.

We implement this for route53, cloudflare, and some others that let you host dns zones whether or not you actually own it or have the root nameservers configured properly.

Other providers do not implement it (name.com, namecheap), because they do not allow arbitrary user-created zones, and require you to buy a domain through them.

This is not a required feature to implement.

@papakai

This comment has been minimized.

Copy link
Contributor Author

papakai commented Jul 26, 2018

@captncraig sounds like we could support this. how to implement this? can we support here?

@papakai papakai force-pushed the hexonet:hexonetProvider branch 4 times, most recently from 9f18aa5 to 365768a Jul 26, 2018

@papakai papakai referenced this pull request Jul 27, 2018

Closed

TLSA RR integration broken #380

@papakai papakai force-pushed the hexonet:hexonetProvider branch from 1dbf098 to a6ebc41 Jul 27, 2018

@papakai papakai force-pushed the hexonet:hexonetProvider branch from cc605f1 to 4059ae0 Jul 30, 2018

@papakai

This comment has been minimized.

Copy link
Contributor Author

papakai commented Jul 30, 2018

@tlimoncelli @captncraig the current status of our PR passes the integration tests. We would love to get this released in short (end of this week maybe?) and as pointed out as official supported provider. How do we proceed here?

Even though I have still open questions, it doesn't block a release. Things can be updated with a follow-up release.

@papakai papakai force-pushed the hexonet:hexonetProvider branch 2 times, most recently from d1f230c to 6f5c467 Jul 30, 2018

@papakai papakai changed the title WIP:New Provider HEXONET New Provider HEXONET Aug 1, 2018

@papakai papakai force-pushed the hexonet:hexonetProvider branch from 398d1d1 to 43d5824 Aug 3, 2018

@papakai

This comment has been minimized.

Copy link
Contributor Author

papakai commented Aug 8, 2018

Hey guys,

even though we don't want to pressure: is there an update on this PR?
Can we support somehow to fasten things up?

Thanks so much!
Kai

@papakai papakai force-pushed the hexonet:hexonetProvider branch 2 times, most recently from 4913b01 to 82738a6 Aug 8, 2018

@tlimoncelli

This comment has been minimized.

Copy link
Contributor

tlimoncelli commented Aug 8, 2018

FYI: I'm on vacation until Aug 13.

@captncraig

This comment has been minimized.

Copy link
Member

captncraig commented Aug 8, 2018

@papakai

This comment has been minimized.

Copy link
Contributor Author

papakai commented Aug 8, 2018

@tlimoncelli thanks for your update. I wish you a well regeneration. :)

@papakai papakai force-pushed the hexonet:hexonetProvider branch 3 times, most recently from e29969b to 136cfbe Aug 9, 2018

@papakai

This comment has been minimized.

Copy link
Contributor Author

papakai commented Aug 10, 2018

FYI: I am out of office on August 13th and 14th. August 15th is public holiday in Germany.

@papakai papakai force-pushed the hexonet:hexonetProvider branch 2 times, most recently from 751e505 to c29f103 Aug 17, 2018

@captncraig

This comment has been minimized.

Copy link
Member

captncraig commented Aug 17, 2018

Ok, I'll be reviewing today, and hopefully get this merged asap. Sorry about the delays, but we've had a bunch of vacation get in the way. Thanks.

@papakai papakai force-pushed the hexonet:hexonetProvider branch from 1b35b0c to 930b4d6 Aug 17, 2018

@papakai

This comment has been minimized.

Copy link
Contributor Author

papakai commented Aug 17, 2018

I've cleaned up the warnings so that all checks passed, ready to merge. ;o)
Also I've rebased our branch to current head of master branch.

@papakai

This comment has been minimized.

Copy link
Contributor Author

papakai commented Aug 20, 2018

@captncraig something I can support with? open questions?
At least you would need the ot&e credentials for integration tests ;o)
Let me know how I've to share that with you guys.

---
# HEXONET Provider

HEXONET is a leading developer and operator of domain names and DNS platforms. Thousands of individuals, service providers and registrars globally choose HEXONET for domains and DNS for our advanced technology, operational performance and up-time, and most importantly for unparalleled expertise in DNS. DnsControl with HEXONET's DNS marries DNS automation with an industry-leading DNS platform that supports DNSSEC, PremiumDNS via Anycast Network, and nearly all of DnsControl's listed provider features.

This comment has been minimized.

@tlimoncelli

tlimoncelli Aug 20, 2018

Contributor

Please limit lines to 80 cols (makes future diffs smaller).

Also... would you mind removing the sentence "Thousands ... expertise in DNS" as it seems like a marketing pitch.

This comment has been minimized.

@papakai

papakai Aug 20, 2018

Author Contributor

Hey @tlimoncelli,

it comes from our marketing department, I will talk to them if we can drop that sentence out.
Maybe just leaving "Thousands" out already removes that marketing pitch impression.
What you think?

This comment has been minimized.

@papakai

papakai Aug 21, 2018

Author Contributor

I've updated the text. Is that version ok for you?

@captncraig
Copy link
Member

captncraig left a comment

Just a few comments on my first pass. Seems pretty close. I would like to run the tests perhaps if you have ote credentials you can share (pinged you on gitter if that works).

OWNERS Outdated
@@ -5,6 +5,7 @@ providers/digitalocean @Deraen
providers/dnsimple @aeden
providers/gandi @TomOnTime
# providers/gcloud
# providers/hexonet

This comment has been minimized.

@captncraig

captncraig Aug 20, 2018

Member

If you don't mind putting your name here, it will help you be a recommended reviewer for future issues / prs referencing this code.

This comment has been minimized.

@papakai

papakai Aug 21, 2018

Author Contributor

I don't mind - it was just part of getting "officially" supported.

// Package hexonet implements a registrar that uses the hexonet api to set name servers. It will self register it's providers when imported.
package hexonet

// HEXONET is a leading developer and operator of domain names and DNS platforms.

This comment has been minimized.

@captncraig

captncraig Aug 20, 2018

Member

I don't think this comment s necessary.

This comment has been minimized.

@papakai

papakai Aug 21, 2018

Author Contributor

cleaned up

providers.CantUseNOPURGE: providers.Can(),
providers.DocCreateDomains: providers.Can(),
providers.DocDualHost: providers.Can(),
providers.DocOfficiallySupported: providers.Can(),

This comment has been minimized.

@captncraig

captncraig Aug 20, 2018

Member

"Officially supported" is a designation that means the maintainers (Stack Exchange) actively use and guarantee support for a provider. The hexonet provider will be "community supported", as we do not have the expertise to debug it thoroughly. But you do :)

This comment has been minimized.

@tlimoncelli

tlimoncelli Aug 20, 2018

Contributor

"officially supported" providers block a release if they don't work. "community supported" is best effort... we'll ship a release if it is broken and haven't heard back from the author.

This comment has been minimized.

@papakai

papakai Aug 21, 2018

Author Contributor

Ok, I will forward this - I was asked to get us as officially supported. If that's not possible atm, I can't change it :)

This comment has been minimized.

@papakai

papakai Aug 23, 2018

Author Contributor

got already changed to community supported.

api := &HXClient{
client: hxcl.NewClient(),
}
api.APILogin, api.APIPassword, api.APIEntity = conf["apilogin"], conf["apipassword"], conf["apientity"]

This comment has been minimized.

@captncraig

captncraig Aug 20, 2018

Member

Perhaps we should default "apientity" to the live system to save anyone needing to know the magic "54cd" identifier?

Perhaps even switch it to a "use OTE" type flag and handle the entity ids internally only?

This comment has been minimized.

@papakai

papakai Aug 21, 2018

Author Contributor

Yes, that's how we already cover it in our connector library go-sdk. By default live system will be used. Just in case customer wants to use OT&E system, method api.client.UseOTESystem() needs to be called.
The intention of the methods UseOTESystem and UseLIVESystem was exactly to not force people to use these very technical entity values. My integration here was a quickshot with a planned later rewrite - that I've forgotten to apply. Thanks for pointing on that.

"DOMAIN": domain,
}
for idx, ns := range ns {
cmd["NAMESERVER"+strconv.Itoa(idx)] = ns

This comment has been minimized.

@captncraig

captncraig Aug 20, 2018

Member

rather than strconv and concatenation, I think I'd prefer cmd[fmt.Sprintf("NAMESERVER%d", idx]

This comment has been minimized.

@papakai

papakai Aug 21, 2018

Author Contributor

makes sense

api.client.SetIPAddress(conf["ipaddress"])
}
if api.APIEntity != "1234" && api.APIEntity != "54cd" {
return nil, errors.Errorf("wrong api system entity used. use \"1234\" for OT&E system or \"54cd\" for Live system")

This comment has been minimized.

@captncraig

captncraig Aug 20, 2018

Member

Prefer fmt.Errorf to the errors package directly. Mostly for consistency across the code base.

This comment has been minimized.

@papakai

papakai Aug 21, 2018

Author Contributor

makes sense

response := n.client.Request(cmd)
code := response.Code()
if code != 200 {
return errors.New(strconv.Itoa(code) + " " + response.Description())

This comment has been minimized.

@captncraig

captncraig Aug 20, 2018

Member

fmt.Errorf makes this a little cleaner.

This comment has been minimized.

@papakai

papakai Aug 21, 2018

Author Contributor

makes sense


for _, rec := range dc.Records {
if rec.Type == "ALIAS" {
rec.Type = "CNAME" // TODO as we fully support ALIAS through our XDNS system

This comment has been minimized.

@captncraig

captncraig Aug 20, 2018

Member

Are these just plain cnames, or do your nameservers do some additional flattening of cnames? We use cnames for cloudflare, for example, in place of alias, because they transparently flatten them and serve as A records. Does hexonet do something like that? If not, then we should not claim to support alias records as they are semantically different from cnames.

This comment has been minimized.

@papakai

papakai Aug 21, 2018

Author Contributor

You were right, I've discussed this with our CTO. Falling back to CNAME is for sure wrong.
For the 1st release, I've decided to leave out ALIAS support.
Our system supports ALIAS RR in correct way, but it creates in addition A Records or AAAA Records (copied from target zone) which will get updated from time to time.
So creating a ALIAS RR automatically comes with further assigned records. Not sure how dnscontrol can handle this. Is it possible to apply such additional and automatically created RR also to customer's dnsconfig file so that this stays transparent?
/EDIT -> Never mind about that question, as these A Records may change from time to time it is impossible to reflect this in the config file accrodingly. So the below idea, is worth to review.

The easiest and working way could be to simply filter these A or AAAA RR out that are bound to that ALIAS RR, but I've to ensure that I can do this without running into further issues.

This comment has been minimized.

@captncraig

captncraig Aug 21, 2018

Member

Are you saying that if I make an ALIAS record, your system will create the underlying A/AAAA records, and actually return them form future api requests in addition to the original ALIAS record? That seems... odd. My naive expectation would probably be that those records get created only on the nameserver side of things, and remain hidden to the api consumer if possible. If they are indeed returned, then yes, they would probably need to be filtered out if identifiable in order to eliminate infinite update loop scenarios if running dnscontrol multiple times. We hope we can establish enough consistency so that if you ever run 'dnscontrol push' twice in a row, you should expect zero corrections on the second run.

This comment has been minimized.

@papakai

papakai Aug 21, 2018

Author Contributor

Looks like I was faced with an bug in our API. These A RRs shouldn't get returned. I will work on ALIAS feature in the next days. But as pointed out: this doesnt block 1st release.

This comment has been minimized.

@papakai

papakai Aug 23, 2018

Author Contributor

Launch of ALIAS is postponed for next weeks, no ETA for that backend system bugfix. So won't be part of the initial release. All parts of our module do already consider the change accordingly - no support for ALIAS. We plan this for the next release.

Thanks guys

changes = true
fmt.Fprintln(buf, cre)
rec := cre.Desired
params["ADDRR"+strconv.Itoa(addrridx)] = n.createRecordString(rec, dc.Name)

This comment has been minimized.

@captncraig

captncraig Aug 20, 2018

Member

All of these params would probably look better to me with fmt.Sprintf.

This comment has been minimized.

@papakai

papakai Aug 21, 2018

Author Contributor

yes.

@papakai papakai force-pushed the hexonet:hexonetProvider branch 2 times, most recently from d889b04 to 711a197 Aug 21, 2018

@papakai

This comment has been minimized.

Copy link
Contributor Author

papakai commented Aug 21, 2018

Thanks for the review, I've applied all changes. Let me know if there's still something you want to have changed. OT&E Credentials are forwarded in gitter.im to @captncraig.

@papakai papakai force-pushed the hexonet:hexonetProvider branch from 5f25c2d to 08602d1 Aug 21, 2018

@papakai

This comment has been minimized.

Copy link
Contributor Author

papakai commented Aug 27, 2018

Can we get this merged this week? I am asking because I am weeks offline in holiday starting on September 1st.
TIA Kai

@tlimoncelli

This comment has been minimized.

Copy link
Contributor

tlimoncelli commented Aug 27, 2018

That shouldn't be a problem. Craig is out today but should get to this by Wednesday.

@captncraig captncraig merged commit 3e5d223 into StackExchange:master Aug 30, 2018

2 checks passed

WIP ready for review
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@papakai

This comment has been minimized.

Copy link
Contributor Author

papakai commented Aug 30, 2018

Thanks a lot again @captncraig and @tlimoncelli for your help and work time spent on this. Very appreciated. We'll met again in next PR to support ALIAS :)

@papakai papakai deleted the hexonet:hexonetProvider branch Aug 30, 2018

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.