)]}'
{
  "log": [
    {
      "commit": "12971d6c8031d06f497c81ae1ed2a5bee488e7d2",
      "tree": "3332b72dda28e9c3d476aba0dd63d8465a3245f7",
      "parents": [
        "b0272187ee577a94edb803b81413165b7c1a89ba"
      ],
      "author": {
        "name": "Serge Bazanski",
        "email": "serge@nexantic.com",
        "time": "Tue Nov 17 12:12:58 2020 +0100"
      },
      "committer": {
        "name": "Serge Bazanski",
        "email": "serge@nexantic.com",
        "time": "Tue Nov 17 12:12:58 2020 +0100"
      },
      "message": "logtree: capture multiple lines in leveled log entries\n\nThis implements a solution to a disputed answer to the following\nquestion:\n\n    “What happens when someone calls Infof(\"foo\\nbar\")?”\n\nMultiple answers immediately present themselves:\n\n    a) Don\u0027t do anything, whatever consumers logs needs to expect that\n       they might contain newlines.\n    b) Yell/error/panic so that the programmer doesn\u0027t do this.\n    c) Split the one Info call into multiple Info calls, one per line,\n       somewhere in the logging path.\n\nFollowing the argumentation for these we establish the follwoing\nrequirments for any solution:\n\n    1) We want the programmer to be able to log multiple lines from a\n       single Info call and have that not fail. This is especially\n       important for reliability - we don\u0027t want an accidental codepath\n       that suddenly starts printing %s-formatted user-controlled\n       messages to start erroring out in production. This rules out b).\n    2) We want to allow emitting multiple lines that will not be\n       interleaved when viewing the log data. This rules out c).\n    3) We want to prohibit log injection by malicious \\n-containing\n       payloads (in case of %s-formatted user-controlled content). This\n       rules out a).\n    4) If multiple lines are allowed in a leveled payload, the type\n       system should support that, so that log consumers/tools will not\n       forget to account for the possible newlines. This too rules out\n       a).\n\nWith these in mind, we instead opt for a different solutions: changing\nthe API of logtree and logging protos to contain multiple possible lines\nper single log entry. This is a breaking change, but since all access to\nlogs is currently self-contained within the Monogon OS codebase, we can\nafford this.\n\nTo support this change, we change the access API (at LogEntry and\nLeveledPayload level) to contain two different methods for retrieving\nthe canonical representation of an entry:\n\n    fn String() string\n\nwhich returns a string with possible intra-string newlines (but no\ntrailing newlines), but with each newline-delimited chunk having the\ncanonical text representation prefix for this message. This prevents\nnewline injection into logs creating fake prefixes.\n\n    fn Strings() (prefix string, lines []string)\n\nwhich returns a common prefix for this entry (in its text\nrepresentation) and a set of lines that were contained in the original\nlog entry. This allows slightly smarter consuming code to make more\nactive decisions regarding the rendering of a multi-line entry, while\nstill providing a canonical text formatted representation of that log\nentry.\n\nThese permit simple log access code that prints log data into a terminal\n(or terminal-like view), like dbg, to continue using the String() call.\nIn fact, no changes had to be made to dbg for it to continue working,\neven though the API underneath changed.\n\nNaturally, raw logging entries continue to contain only a single line,\nso no change is implemented in the LineBuffer API. The containing\nLogEntry for raw log entries emits single-lined Strings() results and no\nnewline-containing strings in String() results.\n\nTest Plan: Updated unit tests to cover this.\n\nX-Origin-Diff: phab/D650\nGitOrigin-RevId: 4e339a930c4cbefff91b289b07bc31f774745eca\n"
    },
    {
      "commit": "b0272187ee577a94edb803b81413165b7c1a89ba",
      "tree": "e270e4fc6d3497b4a6c8624ea7cd8ebbe7246a59",
      "parents": [
        "967be21df6e1f0e14ab66e904f5904261962f099"
      ],
      "author": {
        "name": "Serge Bazanski",
        "email": "serge@nexantic.com",
        "time": "Mon Nov 02 18:39:44 2020 +0100"
      },
      "committer": {
        "name": "Serge Bazanski",
        "email": "serge@nexantic.com",
        "time": "Mon Nov 02 18:39:44 2020 +0100"
      },
      "message": "core: plug logtree into NodeDebugService\n\nThis introduces a new Proto API for accessing debug logs. Currently this\nis implemented to be used by the debug service. However, these proto\ndefinitions will likely be reused for production cluster APIs.\n\nThe implementation mostly consists of adding the proto, implementing\nto/from conversion methods, and altering the debug service to use the\nnew API.\n\nWe also move all of the debug service implementation into a separate file,\nto slightly clean up main.go. This produces an unfortunately colorful\ndiff, but it\u0027s just moving code around.\n\nTest Plan: Manually tested using the dbg tool. We currently don\u0027t properly test the debug service. I suppose we should do that for the production cluster APIs, and just keep on going for now.\n\nX-Origin-Diff: phab/D649\nGitOrigin-RevId: ac454681e4b72b2876e313b3aeababa179eb1fa3\n"
    },
    {
      "commit": "57b4375dc2763dbf8444a4786bd41b7ec1a8172b",
      "tree": "96c6ec6648426bd51bbf82573b2fbe28f2044868",
      "parents": [
        "73fc59541abfc457598cc5e62ae4d2c3b84065a1"
      ],
      "author": {
        "name": "Serge Bazanski",
        "email": "serge@nexantic.com",
        "time": "Mon Jul 13 19:17:48 2020 +0200"
      },
      "committer": {
        "name": "Serge Bazanski",
        "email": "serge@nexantic.com",
        "time": "Mon Jul 13 19:17:48 2020 +0200"
      },
      "message": "core/internal/cluster: implement multi-node clusters with \u0027golden ticket\u0027.\n\nAs we have fully ripped out all traces of the node management service or\nintegrity checks, we implement a stopgap system that allows us to\ncontinue developing multi-node clusters. This mechanism is enrolment\nusing \u0027golden tickets\u0027, which are protobuf messages that can be\ngenerated via the debug service on an existing cluster, and set on a new\nnode\u0027s EnrolmentConfig to bring that enrol that node into the cluster.\n\nAs this is a stopgap measure (waiting for better cluster lifecycle\ndesign), this is somewhat poorly implemented, with known issues:\n - odd enrolment flow that creates all certificates off-node and results\n   in some code duplication in the cluster manager and node debug\n   service\n - (more) assumptions that every node is both a kubernetes and etcd\n   member.\n - absolutely no protection against consensus loss due to even quorum\n   membership, repeated issuance of certificates\n - dependence on knowing the IP address of the new node ahead of time,\n   which is not something that our test harness supports well (or that\n   we want to rely on at all)\n\nTest Plan: part of existing multi-node tests\n\nX-Origin-Diff: phab/D591\nGitOrigin-RevId: 8f099e6ef37f8d47fb2272a3a14b25ed480e377a\n"
    },
    {
      "commit": "73fc59541abfc457598cc5e62ae4d2c3b84065a1",
      "tree": "3eed74792f885733069eedefa2de5dfaaa92052a",
      "parents": [
        "1ebd1e133bac1a7fe0d667ec2ac95f87f63c3701"
      ],
      "author": {
        "name": "Serge Bazanski",
        "email": "serge@nexantic.com",
        "time": "Tue Jul 21 12:50:54 2020 +0200"
      },
      "committer": {
        "name": "Serge Bazanski",
        "email": "serge@nexantic.com",
        "time": "Tue Jul 21 12:50:54 2020 +0200"
      },
      "message": "core/proto: remove NodeDebugService.GetCondition\n\nThis stopped being used after D590 where we moved the debug service to\nstart late enough that we\u0027re sure we already have the prerequisite\nconditions to continue testing. In the future, the debug service might\ngrow some introspection methods into the supervisor - if so, that will\nsomewhat replace this bespoke condition API.\n\nTest Plan: no behavioural changes\n\nX-Origin-Diff: phab/D604\nGitOrigin-RevId: a7edf8a45467fb2be602323b612abe054acf2b11\n"
    },
    {
      "commit": "efdb6e9da9ed4d575afe72fde02a27817eca37c4",
      "tree": "b1e1a9bff4b1b91ada8da8673e042bfecda2f505",
      "parents": [
        "b7689bd2d426a5b5fa8375bb6e72aa853610707f"
      ],
      "author": {
        "name": "Serge Bazanski",
        "email": "serge@nexantic.com",
        "time": "Mon Jul 13 17:19:27 2020 +0200"
      },
      "committer": {
        "name": "Serge Bazanski",
        "email": "serge@nexantic.com",
        "time": "Mon Jul 13 17:19:27 2020 +0200"
      },
      "message": "core/api: move to core/proto\n\nThis is keeping in line with conventions that protobuf files generally\nlive in a \u0027proto/\u0027 directory. Even without that, a lot of the protos in\nthere aren\u0027t actually part of an API, so keeping them in `api/` is a bit\nof a misnomer.\n\nWe also remove unused protos that were part of the old\nintegrity/lifecycle flow. Again, these will make a comeback.\n\nTest Plan: this should fail. part of a larger stack. D590 is the first tip of the stack that should work.\n\nX-Origin-Diff: phab/D588\nGitOrigin-RevId: 4a7af494810348f6bcabd49e63902b4c47e6ec35\n"
    }
  ]
}