)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"1c54646bbca1d3d6113023405b4643cd16327886","unresolved":false,"context_lines":[{"line_number":11,"context_line":"_prep_block_device. If the project is at their volume quota"},{"line_number":12,"context_line":"limit, Cinder will fail and we\u0027ll get an OverQuota exception"},{"line_number":13,"context_line":"during _build_resources. This is also counted as a build"},{"line_number":14,"context_line":"failure in _failed_build() which checks the"},{"line_number":15,"context_line":"[compute]/consecutive_build_service_disable_threshold config"},{"line_number":16,"context_line":"option and can eventually auto-disable the nova-compute service"},{"line_number":17,"context_line":"on this host, e.g. if Dastardly Dan is already over quota for"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"5f7c97a3_fe0d9535","line":14,"range":{"start_line":14,"start_character":11,"end_line":14,"end_character":24},"updated":"2018-05-16 20:22:14.000000000","message":"_build_failed","commit_id":"fc9a9ba2ff3aa57e0b006088b3c5eba529c3847f"}],"nova/compute/manager.py":[{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"f5ae77deb32084ef311ee5f13a56ef1e00f17213","unresolved":false,"context_lines":[{"line_number":1751,"context_line":"                    if result in (build_results.FAILED,"},{"line_number":1752,"context_line":"                                  build_results.RESCHEDULED):"},{"line_number":1753,"context_line":"                        self._build_failed()"},{"line_number":1754,"context_line":"                    else:"},{"line_number":1755,"context_line":"                        self._failed_builds \u003d 0"},{"line_number":1756,"context_line":""},{"line_number":1757,"context_line":"        # NOTE(danms): We spawn here to return the RPC worker thread back to"}],"source_content_type":"text/x-python","patch_set":1,"id":"5f7c97a3_5e4b695e","line":1754,"updated":"2018-05-16 20:24:35.000000000","message":"Maybe skip FAILED_DONT_DISABLE here? Otherwise such a failure would reset the consecutive build fails. Although, they are consecutive, so maybe not but.. I dunno, seems weird to reset it if we\u0027re not really sure it _would_ have finished.","commit_id":"fc9a9ba2ff3aa57e0b006088b3c5eba529c3847f"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ef8d6d1ac6bb3c0cfcea6ae395191f966b219bb8","unresolved":false,"context_lines":[{"line_number":1751,"context_line":"                    if result in (build_results.FAILED,"},{"line_number":1752,"context_line":"                                  build_results.RESCHEDULED):"},{"line_number":1753,"context_line":"                        self._build_failed()"},{"line_number":1754,"context_line":"                    else:"},{"line_number":1755,"context_line":"                        self._failed_builds \u003d 0"},{"line_number":1756,"context_line":""},{"line_number":1757,"context_line":"        # NOTE(danms): We spawn here to return the RPC worker thread back to"}],"source_content_type":"text/x-python","patch_set":1,"id":"5f7c97a3_bee15d2d","line":1754,"in_reply_to":"5f7c97a3_5e4b695e","updated":"2018-05-16 20:33:36.000000000","message":"Not sure about this either, just left it alone for now.","commit_id":"fc9a9ba2ff3aa57e0b006088b3c5eba529c3847f"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"0651bf35e0de7db3e908a19035167626daffb57e","unresolved":false,"context_lines":[{"line_number":1751,"context_line":"                    if result in (build_results.FAILED,"},{"line_number":1752,"context_line":"                                  build_results.RESCHEDULED):"},{"line_number":1753,"context_line":"                        self._build_failed()"},{"line_number":1754,"context_line":"                    else:"},{"line_number":1755,"context_line":"                        self._failed_builds \u003d 0"},{"line_number":1756,"context_line":""},{"line_number":1757,"context_line":"        # NOTE(danms): We spawn here to return the RPC worker thread back to"}],"source_content_type":"text/x-python","patch_set":1,"id":"5f7c97a3_5e5e09ea","line":1754,"in_reply_to":"5f7c97a3_5e4b695e","updated":"2018-05-16 20:34:26.000000000","message":"So you\u0027re suggesting to just leave the count alone in the FAILED_DONT_DISABLE case instead of resetting it? I think that\u0027s worth considering -- we don\u0027t want to get into a situation where we, by chance, never can disable a compute for failed builds if it periodically experiences one of the FAILED_DONT_DISABLE errors.","commit_id":"fc9a9ba2ff3aa57e0b006088b3c5eba529c3847f"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4b97f50d5cdccfee85b7e11f33f636f7ed684cf6","unresolved":false,"context_lines":[{"line_number":1751,"context_line":"                    if result in (build_results.FAILED,"},{"line_number":1752,"context_line":"                                  build_results.RESCHEDULED):"},{"line_number":1753,"context_line":"                        self._build_failed()"},{"line_number":1754,"context_line":"                    else:"},{"line_number":1755,"context_line":"                        self._failed_builds \u003d 0"},{"line_number":1756,"context_line":""},{"line_number":1757,"context_line":"        # NOTE(danms): We spawn here to return the RPC worker thread back to"}],"source_content_type":"text/x-python","patch_set":1,"id":"5f7c97a3_9e9ca16b","line":1754,"in_reply_to":"5f7c97a3_5e5e09ea","updated":"2018-05-16 20:46:01.000000000","message":"I don\u0027t feel strongly about it, I\u0027m happy to not reset the counter when we hit one of these user-error type don\u0027t disable cases. The main point of the change is that we shouldn\u0027t ever count user-error things against the auto-disable consecutive build failure count.","commit_id":"fc9a9ba2ff3aa57e0b006088b3c5eba529c3847f"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"f5ae77deb32084ef311ee5f13a56ef1e00f17213","unresolved":false,"context_lines":[{"line_number":1895,"context_line":"                    host_lists\u003d[host_list])"},{"line_number":1896,"context_line":"            return build_results.RESCHEDULED"},{"line_number":1897,"context_line":"        except (exception.InstanceNotFound,"},{"line_number":1898,"context_line":"                exception.UnexpectedDeletingTaskStateError):"},{"line_number":1899,"context_line":"            msg \u003d \u0027Instance disappeared during build.\u0027"},{"line_number":1900,"context_line":"            LOG.debug(msg, instance\u003dinstance)"},{"line_number":1901,"context_line":"            self._cleanup_allocated_networks(context, instance,"}],"source_content_type":"text/x-python","patch_set":1,"id":"5f7c97a3_1e55f1fa","line":1898,"updated":"2018-05-16 20:24:35.000000000","message":"This would be a case where they deleted it before it finished starting yeah? So probably shouldn\u0027t let them increment the counter.","commit_id":"fc9a9ba2ff3aa57e0b006088b3c5eba529c3847f"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ef8d6d1ac6bb3c0cfcea6ae395191f966b219bb8","unresolved":false,"context_lines":[{"line_number":1895,"context_line":"                    host_lists\u003d[host_list])"},{"line_number":1896,"context_line":"            return build_results.RESCHEDULED"},{"line_number":1897,"context_line":"        except (exception.InstanceNotFound,"},{"line_number":1898,"context_line":"                exception.UnexpectedDeletingTaskStateError):"},{"line_number":1899,"context_line":"            msg \u003d \u0027Instance disappeared during build.\u0027"},{"line_number":1900,"context_line":"            LOG.debug(msg, instance\u003dinstance)"},{"line_number":1901,"context_line":"            self._cleanup_allocated_networks(context, instance,"}],"source_content_type":"text/x-python","patch_set":1,"id":"5f7c97a3_de48d92f","line":1898,"in_reply_to":"5f7c97a3_1e55f1fa","updated":"2018-05-16 20:33:36.000000000","message":"Yup. There are going to be a buttload of cases like this, like   booting with device tags against a virt driver that doesn\u0027t support device tags, or booting from a multiattach volume and the driver doesn\u0027t support multiattach (which is currently all non-libvirt volumes). That\u0027s the slippery slope issue with trying to figure out all the things that should be counted against the auto-disable total. I\u0027m not sure what easier/smarter ways we have of doing this though.\n\nFor the device tags and volume multiattach failures, those are capabilities on the driver and long-term we should be representing those as traits on the compute node resource provider in placement and using those for placement request filtering in the scheduler so we don\u0027t even pick this host to begin with for those types of requests.","commit_id":"fc9a9ba2ff3aa57e0b006088b3c5eba529c3847f"}]}