)]}'
{
  "log": [
    {
      "commit": "50e3c06ec245e8a5e7ca24015b0c152e3bc40a5c",
      "tree": "1876a283b05919beacbba07e51a0980b5b6df89a",
      "parents": [
        "34c28426767dea608b1bf54ad2bc7fdc27b49f16"
      ],
      "author": {
        "name": "Clark Boylan",
        "email": "clark.boylan@gmail.com",
        "time": "Thu May 19 13:36:43 2022 -0700"
      },
      "committer": {
        "name": "Clark Boylan",
        "email": "clark.boylan@gmail.com",
        "time": "Fri May 20 10:35:18 2022 -0700"
      },
      "message": "Fix dbcounter installation on Jammy\n\nThere are two problems with dbcounter installation on Jammy. The first\nis straightforward. We have to use `py_modules` instead of `modules` to\nspecify the source file. I don\u0027t know how this works on other distros\nbut the docs [0] seem to clearly indicate py_modules does this.\n\nThe second issue is quite an issue and requires story time. When\npip/setuptools insteall editable installs (as is done for many of the\nopenstack projects) it creates an easy-install.pth file that tells the\npython interpreter to add the source dirs of those repos to the python\npath. Normally these paths are appended to your sys.path. Pip\u0027s isolated\nbuild env relies on the assumption that these paths are appeneded to the\npath when it santizes sys.path to create the isolated environemnt.\n\nHowever, when SETUPTOOLS_SYS_PATH_TECHNIQUE is set to rewrite the paths\nare not appended and are inserted in the middle. This breaks pip\u0027s\nisolated build env which broke dbcounter installations. We fix this by\nnot setting SETUPTOOLS_SYS_PATH_TECHNIQUE to rewrite. Upstream indicates\nthe reason we set this half a decade ago has since been fixed properly.\n\nThe reason Jammy and nothing else breaks is that python3.10 is the first\npython version to use pip\u0027s isolated build envs by default.\n\nI\u0027ve locally fiddled with a patch to pip [1] to try and fix this\nbehavior even when rewrite is set. I don\u0027t plan to push this upstream\nbut it helps to illustrate where the problem lies. If someone else would\nlike to upstream this feel free.\n\nFinally this change makes the jammy platform job voting again and adds\nit to the gate to ensure we don\u0027t regress again.\n\n[0] https://docs.python.org/3/distutils/sourcedist.html#specifying-the-files-to-distribute\n[1] https://paste.opendev.org/show/bqVAuhgMtVtfYupZK5J6/\n\nChange-Id: I237f5663b0f8b060f6df130de04e17e2b1695f8a\n"
    },
    {
      "commit": "fe52d7f0a88de2dc330923cf6cf52c83ccb92bd6",
      "tree": "98a1e56a45f2f8bc52e9386a00bdf39c2c347bba",
      "parents": [
        "d450e146ccc9b43ce151f57523e4e4c88b9fdafb"
      ],
      "author": {
        "name": "Dan Smith",
        "email": "dansmith@redhat.com",
        "time": "Thu Apr 28 12:34:38 2022 -0700"
      },
      "committer": {
        "name": "Dan Smith",
        "email": "dansmith@redhat.com",
        "time": "Thu May 12 07:55:02 2022 -0700"
      },
      "message": "Change DB counting mechanism\n\nThe mysql performance_schema method for counting per-database queries\nis very heavyweight in that it requires full logging (in a table) of\nevery query. We do hundreds of thousands in the course of a tempest\nrun, which ends up creating its own performance problem.\n\nThis changes the approach we take, which is to bundle a very tiny\nsqlalchemy plugin module which counts just what we care about in\na special database.\n\nIt is more complex than just enabling the features in mysql, but it\nis a massively smaller runtime overhead. It also provides us the\nopportunity to easily zero the counters just before a tempest run.\n\nChange-Id: I361bc30bb970cdaf18b966951f217862d302f0b9\n"
    }
  ]
}