)]}'
{"nova/compute/resource_tracker.py":[{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"52ce4f55cb3947c8fe01014eb70cdd80f76e328d","unresolved":false,"context_lines":[{"line_number":603,"context_line":""},{"line_number":604,"context_line":"    def _copy_resources(self, compute_node, resources):"},{"line_number":605,"context_line":"        \"\"\"Copy resource values to supplied compute_node.\"\"\""},{"line_number":606,"context_line":"        # purge old stats and init with anything passed in by the driver"},{"line_number":607,"context_line":"        # NOTE(danms): Preserve \u0027failed_builds\u0027 across the stats clearing,"},{"line_number":608,"context_line":"        # as that is not part of resources"},{"line_number":609,"context_line":"        # TODO(danms): Stop doing this when we get a column to store this"}],"source_content_type":"text/x-python","patch_set":2,"id":"5f7c97a3_db425e0d","line":606,"range":{"start_line":606,"start_character":8,"end_line":606,"end_character":72},"updated":"2018-07-31 18:06:55.000000000","message":"I missed this part...so for ironic we start with a clear stats dict.","commit_id":"7f492a94a278d4b84f063ae5df196cacfc2d8cb3"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"8e761b65327dd3e1b1122731e274f8b3e8860942","unresolved":false,"context_lines":[{"line_number":612,"context_line":"        self.stats.clear()"},{"line_number":613,"context_line":"        self.stats[\u0027failed_builds\u0027] \u003d prev_failed_builds"},{"line_number":614,"context_line":"        self.stats.digest_stats(resources.get(\u0027stats\u0027))"},{"line_number":615,"context_line":"        compute_node.stats \u003d self.stats"},{"line_number":616,"context_line":""},{"line_number":617,"context_line":"        # update the allocation ratios for the related ComputeNode object"},{"line_number":618,"context_line":"        compute_node.ram_allocation_ratio \u003d self.ram_allocation_ratio"}],"source_content_type":"text/x-python","patch_set":2,"id":"5f7c97a3_19c4d040","line":615,"range":{"start_line":615,"start_character":8,"end_line":615,"end_character":39},"updated":"2018-06-19 17:29:40.000000000","message":"I\u0027m not going to say this removal is bad, but it looks like it\u0027s only running on compute startup, so it should be inexpensive, right?","commit_id":"7f492a94a278d4b84f063ae5df196cacfc2d8cb3"},{"author":{"_account_id":6062,"name":"jichenjc","email":"jichenjc@cn.ibm.com","username":"jichenjc"},"change_message_id":"c4fa37c4d3470e399ece9a049ca910bcb1a0adfe","unresolved":false,"context_lines":[{"line_number":612,"context_line":"        self.stats.clear()"},{"line_number":613,"context_line":"        self.stats[\u0027failed_builds\u0027] \u003d prev_failed_builds"},{"line_number":614,"context_line":"        self.stats.digest_stats(resources.get(\u0027stats\u0027))"},{"line_number":615,"context_line":"        compute_node.stats \u003d self.stats"},{"line_number":616,"context_line":""},{"line_number":617,"context_line":"        # update the allocation ratios for the related ComputeNode object"},{"line_number":618,"context_line":"        compute_node.ram_allocation_ratio \u003d self.ram_allocation_ratio"}],"source_content_type":"text/x-python","patch_set":2,"id":"5f7c97a3_c06f2ff8","line":615,"range":{"start_line":615,"start_character":8,"end_line":615,"end_character":39},"in_reply_to":"5f7c97a3_19c4d040","updated":"2018-06-20 05:21:46.000000000","message":"checked the code and seems you are right, all usage is in compute _init_compute_node function and in turn something can be acceptable","commit_id":"7f492a94a278d4b84f063ae5df196cacfc2d8cb3"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"52ce4f55cb3947c8fe01014eb70cdd80f76e328d","unresolved":false,"context_lines":[{"line_number":612,"context_line":"        self.stats.clear()"},{"line_number":613,"context_line":"        self.stats[\u0027failed_builds\u0027] \u003d prev_failed_builds"},{"line_number":614,"context_line":"        self.stats.digest_stats(resources.get(\u0027stats\u0027))"},{"line_number":615,"context_line":"        compute_node.stats \u003d self.stats"},{"line_number":616,"context_line":""},{"line_number":617,"context_line":"        # update the allocation ratios for the related ComputeNode object"},{"line_number":618,"context_line":"        compute_node.ram_allocation_ratio \u003d self.ram_allocation_ratio"}],"source_content_type":"text/x-python","patch_set":2,"id":"5f7c97a3_dbf01edd","line":615,"range":{"start_line":615,"start_character":8,"end_line":615,"end_character":39},"in_reply_to":"5f7c97a3_c06f2ff8","updated":"2018-07-31 18:06:55.000000000","message":"This does get called every time I think, because _init_compute_node is called from _update_available_resource.","commit_id":"7f492a94a278d4b84f063ae5df196cacfc2d8cb3"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"52ce4f55cb3947c8fe01014eb70cdd80f76e328d","unresolved":false,"context_lines":[{"line_number":707,"context_line":""},{"line_number":708,"context_line":"        # initialize the compute node object, creating it"},{"line_number":709,"context_line":"        # if it does not already exist."},{"line_number":710,"context_line":"        self._init_compute_node(context, resources)"},{"line_number":711,"context_line":""},{"line_number":712,"context_line":"        nodename \u003d resources[\u0027hypervisor_hostname\u0027]"},{"line_number":713,"context_line":""}],"source_content_type":"text/x-python","patch_set":2,"id":"5f7c97a3_fb52bad9","line":710,"updated":"2018-07-31 18:06:55.000000000","message":"OK so here we\u0027ll eventually call _copy_resources which will clear the stats dict.","commit_id":"7f492a94a278d4b84f063ae5df196cacfc2d8cb3"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"e06b373c316800ff8f57e0a859eef7138d4ab813","unresolved":false,"context_lines":[{"line_number":724,"context_line":"                            \u0027flavor\u0027, \u0027migration_context\u0027])"},{"line_number":725,"context_line":""},{"line_number":726,"context_line":"        # Now calculate usage based on instance utilization:"},{"line_number":727,"context_line":"        self._update_usage_from_instances(context, instances, nodename)"},{"line_number":728,"context_line":""},{"line_number":729,"context_line":"        # Grab all in-progress migrations:"},{"line_number":730,"context_line":"        migrations \u003d objects.MigrationList.get_in_progress_by_host_and_node("}],"source_content_type":"text/x-python","patch_set":2,"id":"5f7c97a3_99bdd6d2","line":727,"updated":"2018-07-31 14:35:25.000000000","message":"This is where we start processing usage for all instances on this host. That calls _update_usage_from_instance per instance in a loop to update the stats, then deepcopies those stats back into the compute node record, and then down blow on L762 we\u0027ll update the compute node and save off the updated stats.","commit_id":"7f492a94a278d4b84f063ae5df196cacfc2d8cb3"},{"author":{"_account_id":6062,"name":"jichenjc","email":"jichenjc@cn.ibm.com","username":"jichenjc"},"change_message_id":"1c0e6ad2af1feb0cb0f13f76ab5dcd9904cb97c7","unresolved":false,"context_lines":[{"line_number":1127,"context_line":""},{"line_number":1128,"context_line":"        cn \u003d self.compute_nodes[nodename]"},{"line_number":1129,"context_line":"        self.stats.update_stats_for_instance(instance, is_removed_instance)"},{"line_number":1130,"context_line":"        cn.stats \u003d self.stats"},{"line_number":1131,"context_line":""},{"line_number":1132,"context_line":"        # if it\u0027s a new or deleted instance:"},{"line_number":1133,"context_line":"        if is_new_instance or is_removed_instance:"}],"source_content_type":"text/x-python","patch_set":2,"id":"5f7c97a3_944d1473","line":1130,"range":{"start_line":1130,"start_character":8,"end_line":1130,"end_character":29},"updated":"2018-06-19 09:13:32.000000000","message":"seems valid as the resource tracker is per compute node based\nand won\u0027t have others to change the value of the variable","commit_id":"7f492a94a278d4b84f063ae5df196cacfc2d8cb3"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"a9f20833dae8223929e79f4fc22bbb53ca8a9098","unresolved":false,"context_lines":[{"line_number":1127,"context_line":""},{"line_number":1128,"context_line":"        cn \u003d self.compute_nodes[nodename]"},{"line_number":1129,"context_line":"        self.stats.update_stats_for_instance(instance, is_removed_instance)"},{"line_number":1130,"context_line":"        cn.stats \u003d self.stats"},{"line_number":1131,"context_line":""},{"line_number":1132,"context_line":"        # if it\u0027s a new or deleted instance:"},{"line_number":1133,"context_line":"        if is_new_instance or is_removed_instance:"}],"source_content_type":"text/x-python","patch_set":2,"id":"5f7c97a3_851d0979","line":1130,"range":{"start_line":1130,"start_character":8,"end_line":1130,"end_character":29},"in_reply_to":"5f7c97a3_0529f987","updated":"2018-06-28 21:11:34.000000000","message":"\u003e the stats could be\n \u003e wrong if they aren\u0027t copied uniquely per node - or at least I\u0027m\n \u003e assuming that\u0027s Eric\u0027s concern.\n\nYes, that was my concern, though I wasn\u0027t able to articulate it that well (even in my head).  Thanks for the help.","commit_id":"7f492a94a278d4b84f063ae5df196cacfc2d8cb3"},{"author":{"_account_id":6062,"name":"jichenjc","email":"jichenjc@cn.ibm.com","username":"jichenjc"},"change_message_id":"c4fa37c4d3470e399ece9a049ca910bcb1a0adfe","unresolved":false,"context_lines":[{"line_number":1127,"context_line":""},{"line_number":1128,"context_line":"        cn \u003d self.compute_nodes[nodename]"},{"line_number":1129,"context_line":"        self.stats.update_stats_for_instance(instance, is_removed_instance)"},{"line_number":1130,"context_line":"        cn.stats \u003d self.stats"},{"line_number":1131,"context_line":""},{"line_number":1132,"context_line":"        # if it\u0027s a new or deleted instance:"},{"line_number":1133,"context_line":"        if is_new_instance or is_removed_instance:"}],"source_content_type":"text/x-python","patch_set":2,"id":"5f7c97a3_c01def77","line":1130,"range":{"start_line":1130,"start_character":8,"end_line":1130,"end_character":29},"in_reply_to":"5f7c97a3_1e903696","updated":"2018-06-20 05:21:46.000000000","message":"ok, I don\u0027t know why [1] is related to here may need further dig, but Ironic might be something worthy check as you mentioned","commit_id":"7f492a94a278d4b84f063ae5df196cacfc2d8cb3"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ecef73c68f3ac37326c3b1b52040cfa9a6abf9b2","unresolved":false,"context_lines":[{"line_number":1127,"context_line":""},{"line_number":1128,"context_line":"        cn \u003d self.compute_nodes[nodename]"},{"line_number":1129,"context_line":"        self.stats.update_stats_for_instance(instance, is_removed_instance)"},{"line_number":1130,"context_line":"        cn.stats \u003d self.stats"},{"line_number":1131,"context_line":""},{"line_number":1132,"context_line":"        # if it\u0027s a new or deleted instance:"},{"line_number":1133,"context_line":"        if is_new_instance or is_removed_instance:"}],"source_content_type":"text/x-python","patch_set":2,"id":"5f7c97a3_db0a5e1c","line":1130,"range":{"start_line":1130,"start_character":8,"end_line":1130,"end_character":29},"in_reply_to":"5f7c97a3_851d0979","updated":"2018-07-31 17:41:38.000000000","message":"So maybe we should change self.stats to a dict, keyed by nodename (like self.compute_nodes), mapped to a Stats object per node (which is per instance for ironic). Then we don\u0027t need the deepcopy, right? I also don\u0027t really see how the stats can be accurate for any baremetal filtering anyway since let\u0027s say this host is managing 3 nodes:\n\n1. stats for node1 will contain instance1 (copy stats)\n2. stats for node2 will contain instance1 (because it\u0027s in self.stats) and instance2 (copy stats)\n3. stats for node3 will contain instance1 (because it\u0027s in self.stats) and instance2 (because it\u0027s in self.stats) and instance3 (copy stats)\n\nSo only stats for node1 would be accurate, right? The only in-tree scheduler filter that relies on stats is ComputeCapabilitiesFilter and I\u0027m not sure how much that is used with baremetal scheduling, although I thought people relied on it before ironic nodes + traits existed.","commit_id":"7f492a94a278d4b84f063ae5df196cacfc2d8cb3"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"8e761b65327dd3e1b1122731e274f8b3e8860942","unresolved":false,"context_lines":[{"line_number":1127,"context_line":""},{"line_number":1128,"context_line":"        cn \u003d self.compute_nodes[nodename]"},{"line_number":1129,"context_line":"        self.stats.update_stats_for_instance(instance, is_removed_instance)"},{"line_number":1130,"context_line":"        cn.stats \u003d self.stats"},{"line_number":1131,"context_line":""},{"line_number":1132,"context_line":"        # if it\u0027s a new or deleted instance:"},{"line_number":1133,"context_line":"        if is_new_instance or is_removed_instance:"}],"source_content_type":"text/x-python","patch_set":2,"id":"5f7c97a3_1e903696","line":1130,"range":{"start_line":1130,"start_character":8,"end_line":1130,"end_character":29},"in_reply_to":"5f7c97a3_944d1473","updated":"2018-06-19 17:29:40.000000000","message":"No, there\u0027s only resource tracker as of [1].  So if this is gonna break, it\u0027s gonna break ironic.\n\n[1] I6e204fe8e7c003246c9d8bebf484323700737093","commit_id":"7f492a94a278d4b84f063ae5df196cacfc2d8cb3"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"c31dcd098aac551bf556327ca98e1d71434d009f","unresolved":false,"context_lines":[{"line_number":1127,"context_line":""},{"line_number":1128,"context_line":"        cn \u003d self.compute_nodes[nodename]"},{"line_number":1129,"context_line":"        self.stats.update_stats_for_instance(instance, is_removed_instance)"},{"line_number":1130,"context_line":"        cn.stats \u003d self.stats"},{"line_number":1131,"context_line":""},{"line_number":1132,"context_line":"        # if it\u0027s a new or deleted instance:"},{"line_number":1133,"context_line":"        if is_new_instance or is_removed_instance:"}],"source_content_type":"text/x-python","patch_set":2,"id":"5f7c97a3_0529f987","line":1130,"range":{"start_line":1130,"start_character":8,"end_line":1130,"end_character":29},"in_reply_to":"5f7c97a3_c01def77","updated":"2018-06-28 20:28:14.000000000","message":"Ironic is the only driver that has a 1:M host:node mapping, so ironic hosts are the only ones that can have self.compute_nodes with \u003e1 entry, and with ironic there is a 1:1 mapping between instance and node, so the concern might be that the stats could be wrong if they aren\u0027t copied uniquely per node - or at least I\u0027m assuming that\u0027s Eric\u0027s concern. John Garbutt might have some ideas here.","commit_id":"7f492a94a278d4b84f063ae5df196cacfc2d8cb3"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"52ce4f55cb3947c8fe01014eb70cdd80f76e328d","unresolved":false,"context_lines":[{"line_number":1127,"context_line":""},{"line_number":1128,"context_line":"        cn \u003d self.compute_nodes[nodename]"},{"line_number":1129,"context_line":"        self.stats.update_stats_for_instance(instance, is_removed_instance)"},{"line_number":1130,"context_line":"        cn.stats \u003d self.stats"},{"line_number":1131,"context_line":""},{"line_number":1132,"context_line":"        # if it\u0027s a new or deleted instance:"},{"line_number":1133,"context_line":"        if is_new_instance or is_removed_instance:"}],"source_content_type":"text/x-python","patch_set":2,"id":"5f7c97a3_db4d7ec5","line":1130,"range":{"start_line":1130,"start_character":8,"end_line":1130,"end_character":29},"in_reply_to":"5f7c97a3_db0a5e1c","updated":"2018-07-31 18:06:55.000000000","message":"Furthermore, in the before times (before https://review.openstack.org/#/c/398473/ ), the RT was 1:1 per node, so stats was 1:1 with each node, and the compute manager had multiple RTs (one per node), but with https://review.openstack.org/#/c/398473/ it was changed so that the compute manager is 1:1 with the RT and the RT manages multiple nodes, but stats is still \"shared\" across all the nodes, making the stats cumulative (and wrong) for subsequently processed nodes.","commit_id":"7f492a94a278d4b84f063ae5df196cacfc2d8cb3"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"5d93205c63cb152aff6d2eaa080d813b9965c332","unresolved":false,"context_lines":[{"line_number":1242,"context_line":"                \"Will auto-correct allocations to handle \""},{"line_number":1243,"context_line":"                \"Ocata-style assumptions.\")"},{"line_number":1244,"context_line":""},{"line_number":1245,"context_line":"        for instance in instances:"},{"line_number":1246,"context_line":"            if instance.vm_state not in vm_states.ALLOW_RESOURCE_REMOVAL:"},{"line_number":1247,"context_line":"                if msg_allocation_refresh:"},{"line_number":1248,"context_line":"                    LOG.debug(msg_allocation_refresh)"},{"line_number":1249,"context_line":"                    msg_allocation_refresh \u003d False"},{"line_number":1250,"context_line":"                self._update_usage_from_instance(context, instance, nodename,"},{"line_number":1251,"context_line":"                    require_allocation_refresh\u003drequire_allocation_refresh)"},{"line_number":1252,"context_line":""},{"line_number":1253,"context_line":"    def _remove_deleted_instances_allocations(self, context, cn,"},{"line_number":1254,"context_line":"                                              migrations):"}],"source_content_type":"text/x-python","patch_set":2,"id":"5f7c97a3_0577b9a1","line":1251,"range":{"start_line":1245,"start_character":8,"end_line":1251,"end_character":74},"updated":"2018-06-28 20:30:59.000000000","message":"If we wanted to avoid the copy per instance during the periodic, why not do the cn.stats copy here once we\u0027ve processed all instances? The other places I see the copy happening are during claims (instance claim, move claim), but those should be less heavy since they are one instance rather than all on this host at the same time.\n\nI could see how vcenter really gets hurt by this because a single compute host (resource tracker) is tracking all of the VMs in a single vcenter cluster (right Gary?) so you could have a single resource tracker monitoring several hundred if not a 1000 or more VMs.","commit_id":"7f492a94a278d4b84f063ae5df196cacfc2d8cb3"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"74294b4bb56a75034e8c62f585e62ec29cbd78bf","unresolved":false,"context_lines":[{"line_number":1242,"context_line":"                \"Will auto-correct allocations to handle \""},{"line_number":1243,"context_line":"                \"Ocata-style assumptions.\")"},{"line_number":1244,"context_line":""},{"line_number":1245,"context_line":"        for instance in instances:"},{"line_number":1246,"context_line":"            if instance.vm_state not in vm_states.ALLOW_RESOURCE_REMOVAL:"},{"line_number":1247,"context_line":"                if msg_allocation_refresh:"},{"line_number":1248,"context_line":"                    LOG.debug(msg_allocation_refresh)"},{"line_number":1249,"context_line":"                    msg_allocation_refresh \u003d False"},{"line_number":1250,"context_line":"                self._update_usage_from_instance(context, instance, nodename,"},{"line_number":1251,"context_line":"                    require_allocation_refresh\u003drequire_allocation_refresh)"},{"line_number":1252,"context_line":""},{"line_number":1253,"context_line":"    def _remove_deleted_instances_allocations(self, context, cn,"},{"line_number":1254,"context_line":"                                              migrations):"}],"source_content_type":"text/x-python","patch_set":2,"id":"5f7c97a3_4a4a635b","line":1251,"range":{"start_line":1245,"start_character":8,"end_line":1251,"end_character":74},"in_reply_to":"5f7c97a3_0577b9a1","updated":"2018-07-02 17:52:00.000000000","message":"\u003e I could see how vcenter really gets hurt by this because a single\n \u003e compute host (resource tracker) is tracking all of the VMs in a\n \u003e single vcenter cluster (right Gary?) so you could have a single\n \u003e resource tracker monitoring several hundred if not a 1000 or more\n \u003e VMs.\n\nYeah, there was a real-world case of a customer setting up a nova-compute over a single cluster with approx 1500 instances. This isn\u0027t in the recommended way of doing things but is certainly easy to do (even much larger).\n\nIt would be useful to make it work well at that scale, if only to make it work really well at smaller scales.","commit_id":"7f492a94a278d4b84f063ae5df196cacfc2d8cb3"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"a9f20833dae8223929e79f4fc22bbb53ca8a9098","unresolved":false,"context_lines":[{"line_number":1242,"context_line":"                \"Will auto-correct allocations to handle \""},{"line_number":1243,"context_line":"                \"Ocata-style assumptions.\")"},{"line_number":1244,"context_line":""},{"line_number":1245,"context_line":"        for instance in instances:"},{"line_number":1246,"context_line":"            if instance.vm_state not in vm_states.ALLOW_RESOURCE_REMOVAL:"},{"line_number":1247,"context_line":"                if msg_allocation_refresh:"},{"line_number":1248,"context_line":"                    LOG.debug(msg_allocation_refresh)"},{"line_number":1249,"context_line":"                    msg_allocation_refresh \u003d False"},{"line_number":1250,"context_line":"                self._update_usage_from_instance(context, instance, nodename,"},{"line_number":1251,"context_line":"                    require_allocation_refresh\u003drequire_allocation_refresh)"},{"line_number":1252,"context_line":""},{"line_number":1253,"context_line":"    def _remove_deleted_instances_allocations(self, context, cn,"},{"line_number":1254,"context_line":"                                              migrations):"}],"source_content_type":"text/x-python","patch_set":2,"id":"5f7c97a3_85066921","line":1251,"range":{"start_line":1245,"start_character":8,"end_line":1251,"end_character":74},"in_reply_to":"5f7c97a3_0577b9a1","updated":"2018-06-28 21:11:34.000000000","message":"I believe the platform limit for Power is 1000 LPARs per host.  Whether anyone actually gets close to that on a real (OpenStack-based) PowerVM host, I have no idea.\n\nFor my part, it was easy to see the inefficiency, just academically.  So the fact that Gary was able to cite significant improvement in a real setup was no surprise.  And I would therefore really like to see this fixed.  I just wouldn\u0027t want to inject some other bizarre bug as a result.","commit_id":"7f492a94a278d4b84f063ae5df196cacfc2d8cb3"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"e06b373c316800ff8f57e0a859eef7138d4ab813","unresolved":false,"context_lines":[{"line_number":1242,"context_line":"                \"Will auto-correct allocations to handle \""},{"line_number":1243,"context_line":"                \"Ocata-style assumptions.\")"},{"line_number":1244,"context_line":""},{"line_number":1245,"context_line":"        for instance in instances:"},{"line_number":1246,"context_line":"            if instance.vm_state not in vm_states.ALLOW_RESOURCE_REMOVAL:"},{"line_number":1247,"context_line":"                if msg_allocation_refresh:"},{"line_number":1248,"context_line":"                    LOG.debug(msg_allocation_refresh)"},{"line_number":1249,"context_line":"                    msg_allocation_refresh \u003d False"},{"line_number":1250,"context_line":"                self._update_usage_from_instance(context, instance, nodename,"},{"line_number":1251,"context_line":"                    require_allocation_refresh\u003drequire_allocation_refresh)"},{"line_number":1252,"context_line":""},{"line_number":1253,"context_line":"    def _remove_deleted_instances_allocations(self, context, cn,"},{"line_number":1254,"context_line":"                                              migrations):"}],"source_content_type":"text/x-python","patch_set":2,"id":"5f7c97a3_f9f88a7e","line":1251,"range":{"start_line":1245,"start_character":8,"end_line":1251,"end_character":74},"in_reply_to":"5f7c97a3_4a4a635b","updated":"2018-07-31 14:35:25.000000000","message":"The one problem I could see with removing the stats copy and assignment to the compute node in _update_usage_from_instance() is that other methods are calling it outside the periodic for things like claims, so we\u0027d likely want to pass a flag to _update_usage_from_instance to tell it whether or not to update the compute node stats.","commit_id":"7f492a94a278d4b84f063ae5df196cacfc2d8cb3"}]}