Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here (e.g. I signed it!) and we'll verify it.

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the project maintainer to go/cla#troubleshoot.
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

I signed it

CLAs look good, thanks!

@cycomike The API docs for projects.get don't show any list values: can you report the keys for which you are seeing a list? Best would be to show the whole response body, with any project-identifying information redacted.

In addition, if the API really has changed to returning lists, then we should likely reflect that as well, which would mean doing a type-sniff to figure out what to do with the whitelistedKeySpecs entries.

@lukesneeringer @jonparrott Do we have a PoC for the back-end DNS team?

Not that I know of, reaching out internally.

@tseaver Here is the full response for the quota information which now has the whitelistedKeySpecs entity. Yes you are right that something probably should be done with it.

{u'quota': {u'kind': u'dns#quota', u'rrsetAdditionsPerChange': 1000, u'resourceRecordsPerRrset': 100, u'totalRrdataSizePerChange': 100000, u'dnsKeysPerManagedZone': 4, u'rrsetsPerManagedZone': 10000, u'whitelistedKeySpecs': [{u'kind': u'dns#dnsKeySpec', u'algorithm': u'ecdsap256sha256'}, {u'kind': u'dns#dnsKeySpec', u'algorithm': u'ecdsap384sha384'}, {u'kind': u'dns#dnsKeySpec', u'keyLength': 2048, u'algorithm': u'rsasha256'}, {u'kind': u'dns#dnsKeySpec', u'keyLength': 1024, u'keyType': u'zoneSigning', u'algorithm': u'rsasha256'}, {u'kind': u'dns#dnsKeySpec', u'keyLength': 2048, u'algorithm': u'rsasha512'}, {u'kind': u'dns#dnsKeySpec', u'keyLength': 1024, u'keyType': u'zoneSigning', u'algorithm': u'rsasha512'}], u'rrsetDeletionsPerChange': 1000, u'managedZones': 10000}, u'kind': u'dns#project', u'number': u'1234567', u'id': u'XXXXXXX'}

Looks like the whitelistedKeySpecs[] addition is documented as part of https://cloud.google.com/dns/api/v1beta2/projects.

@seils Interesting that the field would be removed in the v1 API docs for projects.

@theacodes Any status on a PoC?

@cycomike I'm sorry we've let your patch languish so long. At this point, it seems likely to me that we won't be able to provide proper support for zones created with the whitelistedKeySpecs property under the v1beta2 API.

Cloud dns api still throws error on accessing project quotas due to the whitelistedKeySpecs. The error thrown was :-

  key: int(value) for key, value in resp["quota"].items() if key != "kind"
  TypeError:int() argument must be a string, a bytes-like object or a number, not 'list

How to handle this ?

Cloud dns api still throws error on accessing project quotas due to the whitelistedKeySpecs. The error thrown was :-

  key: int(value) for key, value in resp["quota"].items() if key != "kind"
  TypeError:int() argument must be a string, a bytes-like object or a number, not 'list

How to handle this ?

Hi

The changes were never merged to fix this issue, the patch I created is still sitting in this pull request.
4437bc4

NOTE: It does not do anything with the whitelistedkeys, so if you need that data additional changes would be required.

Two points about this PR:

• Adding "correct" support for the whitelistedKeySpecs resource field would be far preferable to just skipping over it. I realize that involves a lot more work. FWIW, I cannot see any reason why that field is under the top-level quotas field: I think the best choice is to adjust the quotas method to skip that field completely (by name, rather than by type), and then add a new whitelisted_key_specs method which returns the values from the nested field, if present.
• The code for the DNS library has been moved to a separate repository. Any follow-ups should happen there.