flattening profiles in denominator v4

10 views
Skip to first unread message

Adrian Cole

unread,
Aug 22, 2013, 12:54:10 PM8/22/13
to denomin...@googlegroups.com
Hi, all.

In using denominator at netflix, I've noticed we can improve the way we represent "profiles" for reasons including compatibility with via json-pointer/patch.  The change is to flatten "profiles" such as geo, as optional fields in the record set.  I've reviewed this at length on IRC w/ jdamick and also with Allen here at netflix.  I'd like to make this change soon as denominator 4 so that the model holds water longer thereafter.

Details:

Change:

from:
{
  "name": "www.foo.com.",
  "type": "CNAME",
  "qualifier": "US",
  "ttl": 300,
  "records": [ { "cname": "www-000000001.us-east-1.elb.amazonaws.com."}],
  "profiles": [ { "type": "geo",  "regions": { "United States (US)": [ "Alabama"] } } ]
}

to:
{
  "name": "www.foo.com.",
  "type": "CNAME",
  "qualifier": "US",
  "ttl": 300,
  "records": [ { "cname": "www-000000001.us-east-1.elb.amazonaws.com."}],
  "geo": {"regions": { "United States (US)": [ "Alabama"] } }
}

There are 3 good reasons to do this:
1. data are now compatible with json pointer/patch specs.  ex. geo/regions/United States.  This makes ad-hoc client and PATCH operations straightforward.
2. weird relationships such as Alias + health check, are visible via optional fields as opposed to queries in a profile bucket.  This makes that code simpler
3. mixed types in the same collection are not compatible with schemas like Thrift or Protobuf, so moving to extended fields allows us more flexibility

The original rationale for the profile collection is no longer necessary because:
1. the universe of potential extensions/profiles is much smaller than originally thought
2. vendors release extensions that would be modeled as profiles very slowly
3. the subset of extensions we support use in the next 6months - year is max 3-5 per record set, which is a reasonable amount of optional fields
4. we used to think no profiles = not special, but health checks can be placed on normal records.

Adrian Cole

unread,
Aug 22, 2013, 5:23:57 PM8/22/13
to denomin...@googlegroups.com
FYI: this PR flattens, but preserves RRSet.profiles() as deprecated for removal in 4.0

Colm MacCárthaigh

unread,
Aug 24, 2013, 5:27:46 PM8/24/13
to Adrian Cole, denomin...@googlegroups.com

They sure make it look prettier to me too. +1
--
Colm
Reply all
Reply to author
Forward
0 new messages