)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"82b0260ca28549c185515ba56ee83b2404e0bb46","unresolved":false,"context_lines":[{"line_number":36,"context_line":"ComputeNode fields if the configured ratios are not the 0.0 default."},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"Change-Id: I43a23a3290db0c835fed01b8d6a38962dc61adce"},{"line_number":39,"context_line":"Related-Bug: #1789654"},{"line_number":40,"context_line":"(cherry picked from commit 2588af87c862cfd02d860f6b860381e907b279ff)"},{"line_number":41,"context_line":"(cherry picked from commit 01265b98c4cd2b1377e891a06ce748fc6f8f3425)"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"3fce034c_b7d1d825","line":39,"updated":"2019-04-18 15:04:32.000000000","message":"OK so the original issue with this bug was we were saving 0.0 allocation ratio values in placement in rocky which was causing scheduling to fail. I think that was related to some changes made to the RT in rocky which shifted a race or something that caused that problem - it was hard to nail down.\n\nNow I don\u0027t think that same race appears in pike, and was thought to be related to https://review.openstack.org/#/q/I120a98cc4c11772f24099081ef3ac44a50daf71d which is why I said if you were going to backport that change to pike we definitely wanted this change as well. Since you\u0027ve abandoned that backport for pike, I\u0027m not sure that we need this.\n\nHowever, I remember now that there was another reason for this change, which is in the paragraph above:\n\n\u003e So even if the ComputeNode object allocation ratio values are the\nnon-0.0 defaults, we\u0027ll *always* update the database on every\nperiodic even if nothing else changed in inventory.\n\nIn a kvm deployment where there is 1:1 host:node mapping, that \u0027update on every call\u0027 is maybe not a big deal, but I could see how in a vcenter deployment where maybe the compute is managing many nodes, it could be an issue - so maybe that\u0027s the justification for backporting this for vcenter? Although I thought we stopped doing 1:M host:node cluster support for vcenter back in like Kilo or Liberty?","commit_id":"4cb1ec2910cb199a4711317d1094912c3ef1b8ce"}]}