)]}'
{
  "log": [
    {
      "commit": "41513bfe35218ffd6964e54cb468a4671688b516",
      "tree": "bc7f84f459de0b0ce59253edc519014c37313401",
      "parents": [
        "16138de840ace426ef58d10011b73bc4cca88336"
      ],
      "author": {
        "name": "Zack Williams",
        "email": "zdw@opennetworking.org",
        "time": "Sat Jul 07 20:08:35 2018 -0700"
      },
      "committer": {
        "name": "Zack Williams",
        "email": "zdw@opennetworking.org",
        "time": "Sat Jul 07 22:45:38 2018 -0700"
      },
      "message": "Fixes to pass license check\n\nChange-Id: If9a17321030490c70d9a8fdd49adfe8b912c6fe7\n"
    },
    {
      "commit": "dafefe16ce5d946271ca9ac5a4fd36ec2a92bee8",
      "tree": "a0f218d28f01c9498ca63993e1c8987337be1158",
      "parents": [
        "7b1bab911a9e79da18247746f6b56168d24df049"
      ],
      "author": {
        "name": "Zsolt Haraszti",
        "email": "zharaszt@ciena.com",
        "time": "Mon Nov 14 21:29:58 2016 -0800"
      },
      "committer": {
        "name": "Zsolt Haraszti",
        "email": "zharaszt@ciena.com",
        "time": "Wed Nov 23 10:20:30 2016 -0800"
      },
      "message": "Config/management model framework initial version\n\nThis is the initial commit of the internal config\nmodel tree for Voltha.\n\nA system that borrows key concepts from Docker, repo,\nand git for multi-revision configuration handling with\ntransaction (commit/abort) logic, tagging, and the\nability to diff between config versions.\n\nKey features:\n* Stored model is defined using *annotated* Google protobuf\n  (*.proto) files\n* Model is kept in memory as Python protobuf message objects\n* The whole configuration is arranged in a nested (tree)\n  structure, made up of ConfigNode objects. Each\n  ConfigNode holds its config data as (possibly nested)\n  protobuf message object, as well as lists of \"pointers\"\n  to its logically nested children nodes. What message\n  fields are considered part of the node-local config vs.\n  what is stored as a child node is controlled by \"child_node\"\n  annotations in the *.proto files.\n* Each ConifgNode stores its config in immutable\n  ConfigRevision obects, each revision being identified\n  by a unique hash value, calculated from a unique\n  hash value of its local configuration as well as\n  the list of hash values of all its children node.\n* Collection type children nodes can be indexed (keyed)\n  so that they can be addressed with \"path\" notation\n  friendly to REST and other interfaces/APIs. Which\n  field is used as key is defined in the parent message\n  using \"key\" attribute of the \"child_node\" annotation.\n  Currently string and integer type fields can be used\n  as keys.\n* Changes to the model create new revisions in all\n  affected nodes, which are rolled up as new revisions\n  to the root node.\n* Root revisions can be tagged, tags can be moved\n* The root node by default keeps a rev, but provides\n  a mechanism to purge untagged revs.\n* All branch and leaf nodes auto-purge interim revs\n  not needed. A rev is not needed if no one refers\n  to it.\n* Diffing between revs is supported, it yields RFC6902\n  jsonpatch objects. Diffing can be done between any\n  revs.\n* The main operations are: CRUD (we call them .add,\n  .get, .update, .remove)\n* Get can be recursive to an optionally limited depth.\n* There is support for Read-Only attributes (fields)\n* All CRUD operation support \"path\" based addressing.\n* There is support for an branch/leaf node perspective\n  implemented by ConfigProxy. This proxy, when attached\n  to an arbitrary node in the tree, provides all the\n  CRUD operations in that context, that is, path args\n  are used relative to that node.\n* Transaction support: All mutations made in a transaction\n  are invisible to others until the transaction is committed.\n  The commit is atomic (either all changes are applied\n  to the tree or none). Conflicts between transactions\n  are detected at the per-node level and a conflict\n  results in rejecting the conflicting transaction (first\n  one wins).\n* Registered callbacks: via the proxy objects an\n  observer can register for pre- and post- operation\n  callbacks. Also, there is a post-get callback which\n  can be used to augment stored data with real-time\n  data.\n\nI started hooking up the new config infrastructure to\nVoltha\u0027s CORE, but this is still in progress, as not\nall existing APIs have bee moved over yet.\n\nNote: I also lumped in some experimental files working\nwith \"Any\" types in protobufs\n\nChange-Id: Ic547b36e9b893d54e6d9ce67bdfcb32a6e8acd4c\n"
    }
  ]
}