The format of octoDNS's geo codes are <continent>-<country>-<region>.

There doesn't appear to be an iso standard for continent codes. octoDNS uses https://github.com/jefftune/pycountry-convert to map which maps things with https://github.com/jefftune/pycountry-convert/blob/master/pycountry_convert/country_alpha2_to_continent.py

The country part is an ISO 2-letter country code so that's standard.

The only existing use of region is US states, but conceptually Canadian providences are allowed, it's just that none (to my knowledge) of the existing providers support them, if they do they might just work or may needs some tweaking in the providers to send it down the way they expect.

The details of taking the geo codes and mapping them into the underlying dns service's requirements are the job of the provider. If UltraDNS supports Canadian provinces then it should be possible to send them over to it however it needs. E.g. NA-CA-BC would get translated into whatever UltraDNS expects.

Did anything in particular make you think that it was specific to US states? I know the examples are, but that's mainly b/c it's the only thing supported by providers that I use/has been tested.

I'm looking at octodns/record/geo_data.py which is referenced from _DynamicMixin.validate:

                        print("---- {}".format(geo))
                        reasons.extend(GeoCodes.validate(geo, 'rule {} '
                                                         .format(rule_num)))

In geo_data.py there is a provinces key under 'US':

                   'provinces': {'AK': {'name': 'Alaska'},
                                 'AL': {'name': 'Alabama'},
                                 'AR': {'name': 'Arkansas'},
                                 ...

If I try to create a Dynamic record with Record.new from my provider, with a geo code like NA-CA-BA it dies with a KeyError looking for the province key under Canada.

I'm thinking it might just be a matter of adding that key with the Canadian provinces under CA. Providers that support that level of geo-location in Canada will be able to reference these. Those that don't, will ignore it, as they will just be validating CA , as coming from their respective APIs.

I can whip up a quick PR to add this if you're game.

Ah, didn't/don't remember that setup. Guess the script that builds it needs to figure out a way to include CA provinces. https://github.com/github/octodns/blob/master/script/generate-geo-data. Would happily 👀 at a PR that does that and includes them in the geo_data.

I've written up some changes, just want to get your feedback on how best to submit, @ross.

• octodns/record/geo.py, updates to province_to_code() to support CA provinces
• script/generate-geo-data, to generate the Canadian provinces in geo_data.py
• tests/test_octodns_record_geo.py to test province_to_code()

I've also coded up changes to provider/ns1.py to support CA provinces. I've got all tests passing, and coverage complete, but I'm not super familiar with the NS1 provider code. I'm thinking of submitting the three changes in the list above in one PR, and the changes to the NS1 provider through another PR. I had a look at the Dyn provider, which looks like it uses the methods in octodns/record/geo.py, so I don't think any changes would be needed there to support CA provinces.

Thoughts?

Also - I thought I'd leave it to you to re-gen geo_data.py, as it looks like there's been a couple of country name changes since what's currently in the repo was generated.

I've written up some changes, just want to get your feedback on how best to submit, @ross.

• octodns/record/geo.py, updates to province_to_code() to support CA provinces

🆒, did you have to pass in the country portion to help with that? Guess there may not be overlap between the two, but figure at some point there would be.

• script/generate-geo-data, to generate the Canadian provinces in geo_data.py

👍

• tests/test_octodns_record_geo.py to test province_to_code()

👍

I'm thinking of submitting the three changes in the list above in one PR, and the changes to the NS1 provider through another PR.

That sounds reasonable. I've done similar changes in multiple pieces like that in the past to lay the foundation and then make use of it.

I had a look at the Dyn provider, which looks like it uses the methods in octodns/record/geo.py, so I don't think any changes would be needed there to support CA provinces.

I wouldn't bother with Dyn. It's a deprecated product that was supposed to already be EOL'd by oracle. They've extended it until next year, but I'm already considering it deprecated as far as octoDNS support goes. Anyway if you specifically need Dyn support I can review that too, but don't worry about it otherwise.

Also - I thought I'd leave it to you to re-gen geo_data.py, as it looks like there's been a couple of country name changes since what's currently in the repo was generated.

I'll re-run it and do a clean PR to just pick up the unrelated changes so that when run for CA stuff it won't have anything unrelated.

Submitted #562. Didn't have to pass in the country code, but it makes the assumption that province will only show up for US or CA. If you're good with that PR, I'll submit one for the NS1 changes.

Looks like I'm dealing with a little bit of chicken and egg in the automated testing for #562 re geo_data.py. I'll just go ahead and add the updated geo_data.py to the PR.

#562 was merged.