)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"cad6dda9f9ba02783e6bc4c0817d708d083275f4","unresolved":false,"context_lines":[{"line_number":6,"context_line":""},{"line_number":7,"context_line":"Log trace when updating host states"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"Because host_state.update() is called for all compute nodes, logging"},{"line_number":10,"context_line":"within update() will cause a performance hit with any reasonable number"},{"line_number":11,"context_line":"of compute nodes. So this drops the logging in update() down to trace,"},{"line_number":12,"context_line":"so even with debug logging on, the performance hit is not seen (as"},{"line_number":13,"context_line":"much)."},{"line_number":14,"context_line":""},{"line_number":15,"context_line":"Closes-Bug: #1620692"},{"line_number":16,"context_line":"Change-Id: I8bba16c94c2bdd114bc011382747ebca25ea5a50"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"9a89bdaa_043161ec","line":13,"range":{"start_line":9,"start_character":0,"end_line":13,"end_character":6},"updated":"2016-09-06 18:35:48.000000000","message":"You had actual numbers for this, with and without debug logging and a given number of nodes, it would be good to share that info here in the commit message.","commit_id":"b39ac3f279e3bc9546a917a93ef44c4c1ce77442"}],"nova/scheduler/host_manager.py":[{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"06d79debaab30e9f1763e53bd2726f63d316467e","unresolved":false,"context_lines":[{"line_number":165,"context_line":"            # shared host state should be updated in a consistent way to make"},{"line_number":166,"context_line":"            # sure its data is valid under concurrent write operations."},{"line_number":167,"context_line":"            if compute is not None:"},{"line_number":168,"context_line":"                LOG.trace(\"Update host state from compute node: %s\", compute)"},{"line_number":169,"context_line":"                self._update_from_compute_node(compute)"},{"line_number":170,"context_line":"            if aggregates is not None:"},{"line_number":171,"context_line":"                LOG.trace(\"Update host state with aggregates: %s\", aggregates)"}],"source_content_type":"text/x-python","patch_set":1,"id":"9a89bdaa_f1599d5b","line":168,"updated":"2016-09-06 18:35:05.000000000","message":"Looks like these were added in:\n\nhttps://review.openstack.org/#/c/259891/\n\nJust FYI, they were part of a bigger change.","commit_id":"b39ac3f279e3bc9546a917a93ef44c4c1ce77442"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"aa2a4fe79cc5acbadaf509d7718cc7eedfb0844c","unresolved":false,"context_lines":[{"line_number":168,"context_line":"                LOG.trace(\"Update host state from compute node: %s\", compute)"},{"line_number":169,"context_line":"                self._update_from_compute_node(compute)"},{"line_number":170,"context_line":"            if aggregates is not None:"},{"line_number":171,"context_line":"                LOG.trace(\"Update host state with aggregates: %s\", aggregates)"},{"line_number":172,"context_line":"                self.aggregates \u003d aggregates"},{"line_number":173,"context_line":"            if service is not None:"},{"line_number":174,"context_line":"                LOG.trace(\"Update host state with service dict: %s\", service)"}],"source_content_type":"text/x-python","patch_set":1,"id":"9a89bdaa_c464d9e6","line":171,"range":{"start_line":171,"start_character":20,"end_line":171,"end_character":25},"updated":"2016-09-06 18:37:03.000000000","message":"Based on the logging guidelines:\n\nhttps://specs.openstack.org/openstack/openstack-specs/specs/log-guidelines.html\n\n\"Trace: In functions which support this level, details every parameter and operation to help diagnose subtle bugs. This should only be enabled for specific areas of interest or the log volume will be overwhelming. Some system performance degradation should be expected.\"\n\nThis seems justified as it\u0027s impacting performance and you should have to opt into TRACE as a log level knowing it\u0027s going to impact your performance.","commit_id":"b39ac3f279e3bc9546a917a93ef44c4c1ce77442"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"d2bf5ef630c5f73bab549e2cd765845f4961a6f8","unresolved":false,"context_lines":[{"line_number":165,"context_line":"            # shared host state should be updated in a consistent way to make"},{"line_number":166,"context_line":"            # sure its data is valid under concurrent write operations."},{"line_number":167,"context_line":"            if compute is not None:"},{"line_number":168,"context_line":"                LOG.trace(\"Update host state from compute node: %s\", compute)"},{"line_number":169,"context_line":"                self._update_from_compute_node(compute)"},{"line_number":170,"context_line":"            if aggregates is not None:"},{"line_number":171,"context_line":"                LOG.trace(\"Update host state with aggregates: %s\", aggregates)"}],"source_content_type":"text/x-python","patch_set":2,"id":"9a89bdaa_a7a437a6","line":168,"range":{"start_line":168,"start_character":20,"end_line":168,"end_character":25},"updated":"2016-09-06 19:12:55.000000000","message":"FYI, there isn\u0027t a good way to actually turn this on yet, hence this oslo.log RFE:\n\nhttps://bugs.launchpad.net/oslo.log/+bug/1620789","commit_id":"ac17d55b7d36ef078aca1b4979622067e7eecf6f"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"aac3bc41e0acf24554062723fd6467bf707ddd08","unresolved":false,"context_lines":[{"line_number":165,"context_line":"            # shared host state should be updated in a consistent way to make"},{"line_number":166,"context_line":"            # sure its data is valid under concurrent write operations."},{"line_number":167,"context_line":"            if compute is not None:"},{"line_number":168,"context_line":"                LOG.trace(\"Update host state from compute node: %s\", compute)"},{"line_number":169,"context_line":"                self._update_from_compute_node(compute)"},{"line_number":170,"context_line":"            if aggregates is not None:"},{"line_number":171,"context_line":"                LOG.trace(\"Update host state with aggregates: %s\", aggregates)"}],"source_content_type":"text/x-python","patch_set":2,"id":"9a89bdaa_7e18c475","line":168,"range":{"start_line":168,"start_character":20,"end_line":168,"end_character":25},"in_reply_to":"9a89bdaa_21ac808b","updated":"2016-09-07 14:41:36.000000000","message":"You can run with a different config for each service, e.g. we could have a nova-scheduler.conf and run the scheduler service with that. For us, our control nodes have nova-api, conductor and scheduler on the same host, at least right now, so we\u0027d have to have separate configs for each service on each host. There was something else that brought that up too, I can\u0027t remember what that was right now though. Via config management it\u0027s not impossible, it\u0027s just more of a pain, especially because it\u0027s not always clear what options are needed in all config files for each service.\n\nOur short term workaround for now was just to run with DEBUG\u003dfalse on our control nodes and DEBUG\u003dtrue in our computes by default.","commit_id":"ac17d55b7d36ef078aca1b4979622067e7eecf6f"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"1ac36ec602d190705cf43e8012fa0531f5f0149a","unresolved":false,"context_lines":[{"line_number":165,"context_line":"            # shared host state should be updated in a consistent way to make"},{"line_number":166,"context_line":"            # sure its data is valid under concurrent write operations."},{"line_number":167,"context_line":"            if compute is not None:"},{"line_number":168,"context_line":"                LOG.trace(\"Update host state from compute node: %s\", compute)"},{"line_number":169,"context_line":"                self._update_from_compute_node(compute)"},{"line_number":170,"context_line":"            if aggregates is not None:"},{"line_number":171,"context_line":"                LOG.trace(\"Update host state with aggregates: %s\", aggregates)"}],"source_content_type":"text/x-python","patch_set":2,"id":"9a89bdaa_7e50c4d4","line":168,"range":{"start_line":168,"start_character":20,"end_line":168,"end_character":25},"in_reply_to":"9a89bdaa_7e18c475","updated":"2016-09-07 14:45:55.000000000","message":"Hmm, yeah I guess we could also try running nova-scheduler with the --nodebug option on the command line and see if that overwrites CONF.debug\u003dTrue in nova.conf. I\u0027d have to test that out.","commit_id":"ac17d55b7d36ef078aca1b4979622067e7eecf6f"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"6bfe0178000c1d37885eef01421c143f14c1ef49","unresolved":false,"context_lines":[{"line_number":165,"context_line":"            # shared host state should be updated in a consistent way to make"},{"line_number":166,"context_line":"            # sure its data is valid under concurrent write operations."},{"line_number":167,"context_line":"            if compute is not None:"},{"line_number":168,"context_line":"                LOG.trace(\"Update host state from compute node: %s\", compute)"},{"line_number":169,"context_line":"                self._update_from_compute_node(compute)"},{"line_number":170,"context_line":"            if aggregates is not None:"},{"line_number":171,"context_line":"                LOG.trace(\"Update host state with aggregates: %s\", aggregates)"}],"source_content_type":"text/x-python","patch_set":2,"id":"9a89bdaa_197ef218","line":168,"range":{"start_line":168,"start_character":20,"end_line":168,"end_character":25},"in_reply_to":"9a89bdaa_7e50c4d4","updated":"2016-09-07 15:03:03.000000000","message":"However, for the record, I still think the fact that these debug statements cause such an impact in performance is a bug, and they should be TRACE calls if we\u0027re going to make them at all, because they fall under the definition of the TRACE log level more than DEBUG, so I\u0027m going to push forward with adding a CONF.trace option in oslo.log for ocata.","commit_id":"ac17d55b7d36ef078aca1b4979622067e7eecf6f"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ec9a5dd440fe069adaef95f434182f6def3a279d","unresolved":false,"context_lines":[{"line_number":165,"context_line":"            # shared host state should be updated in a consistent way to make"},{"line_number":166,"context_line":"            # sure its data is valid under concurrent write operations."},{"line_number":167,"context_line":"            if compute is not None:"},{"line_number":168,"context_line":"                LOG.trace(\"Update host state from compute node: %s\", compute)"},{"line_number":169,"context_line":"                self._update_from_compute_node(compute)"},{"line_number":170,"context_line":"            if aggregates is not None:"},{"line_number":171,"context_line":"                LOG.trace(\"Update host state with aggregates: %s\", aggregates)"}],"source_content_type":"text/x-python","patch_set":2,"id":"9a89bdaa_c3c9265b","line":168,"range":{"start_line":168,"start_character":20,"end_line":168,"end_character":25},"in_reply_to":"9a89bdaa_82e1e100","updated":"2016-09-06 23:37:33.000000000","message":"I see a few options:\n\n1. Do nothing, leave this, and just let everyone handle it on their own by using debug or not with the scheduler. The problem we have is nova-scheduler runs on the same control nodes as nova-api and nova-conductor, and we don\u0027t necessarily want to turn off debug logging for nova-api.\n\n2. Add a new option for just nova-scheduler, like CONF.scheduler.trace\u003dFalse or something, which allows us to control TRACE level logging for things like this in the scheduler. I\u0027m not crazy about that since we already have LOG.trace available.\n\n3. Make this dependent on getting a CONF.trace option into oslo.log. I don\u0027t think that change is that hard, but it puts us out until Ocata. That\u0027s probably OK given the workaround of just not running with debug logging in #1 above.\n\n4. Delete these debug statements, I\u0027m not sure how useful they are or not. They were added when the locking code was added, so I\u0027m guessing they were put in while developing that change to make sure things were sane.\n\n--\n\nGiven #3 is something I think needs to happen long-term anyway since we have LOG.trace available and it\u0027s used:\n\nhttp://codesearch.openstack.org/?q\u003dLOG\\.trace\\%28\u0026i\u003dnope\u0026files\u003d\u0026repos\u003d\n\nWe should just go with option 3 and make this change dependent on that becoming available in oslo.log, which pushes this to Ocata, but I think that\u0027s fair given we\u0027re about 2 weeks away from that anyway.","commit_id":"ac17d55b7d36ef078aca1b4979622067e7eecf6f"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"9d60c87aabc6ec463556ef4b5b73baa440fa2650","unresolved":false,"context_lines":[{"line_number":165,"context_line":"            # shared host state should be updated in a consistent way to make"},{"line_number":166,"context_line":"            # sure its data is valid under concurrent write operations."},{"line_number":167,"context_line":"            if compute is not None:"},{"line_number":168,"context_line":"                LOG.trace(\"Update host state from compute node: %s\", compute)"},{"line_number":169,"context_line":"                self._update_from_compute_node(compute)"},{"line_number":170,"context_line":"            if aggregates is not None:"},{"line_number":171,"context_line":"                LOG.trace(\"Update host state with aggregates: %s\", aggregates)"}],"source_content_type":"text/x-python","patch_set":2,"id":"9a89bdaa_82e1e100","line":168,"range":{"start_line":168,"start_character":20,"end_line":168,"end_character":25},"in_reply_to":"9a89bdaa_a7a437a6","updated":"2016-09-06 19:33:43.000000000","message":"Is it a good idea to change this when there\u0027s no way to turn it on yet?","commit_id":"ac17d55b7d36ef078aca1b4979622067e7eecf6f"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"e7ac0cc14be957b2078841b173a9940cbd9e6934","unresolved":false,"context_lines":[{"line_number":165,"context_line":"            # shared host state should be updated in a consistent way to make"},{"line_number":166,"context_line":"            # sure its data is valid under concurrent write operations."},{"line_number":167,"context_line":"            if compute is not None:"},{"line_number":168,"context_line":"                LOG.trace(\"Update host state from compute node: %s\", compute)"},{"line_number":169,"context_line":"                self._update_from_compute_node(compute)"},{"line_number":170,"context_line":"            if aggregates is not None:"},{"line_number":171,"context_line":"                LOG.trace(\"Update host state with aggregates: %s\", aggregates)"}],"source_content_type":"text/x-python","patch_set":2,"id":"9a89bdaa_dee3b9a2","line":168,"range":{"start_line":168,"start_character":20,"end_line":168,"end_character":25},"in_reply_to":"9a89bdaa_bea27597","updated":"2016-09-07 00:38:40.000000000","message":"I agree option #3 sounds like the best way to handle this, assuming these statements are useful to anyone.\n\nOtherwise, option #4 could be the way to go after sanity-checking with operators.","commit_id":"ac17d55b7d36ef078aca1b4979622067e7eecf6f"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"d1162f218bfa9feafa443b64cd92db8d74e08f50","unresolved":false,"context_lines":[{"line_number":165,"context_line":"            # shared host state should be updated in a consistent way to make"},{"line_number":166,"context_line":"            # sure its data is valid under concurrent write operations."},{"line_number":167,"context_line":"            if compute is not None:"},{"line_number":168,"context_line":"                LOG.trace(\"Update host state from compute node: %s\", compute)"},{"line_number":169,"context_line":"                self._update_from_compute_node(compute)"},{"line_number":170,"context_line":"            if aggregates is not None:"},{"line_number":171,"context_line":"                LOG.trace(\"Update host state with aggregates: %s\", aggregates)"}],"source_content_type":"text/x-python","patch_set":2,"id":"9a89bdaa_bea27597","line":168,"range":{"start_line":168,"start_character":20,"end_line":168,"end_character":25},"in_reply_to":"9a89bdaa_c3c9265b","updated":"2016-09-07 00:23:10.000000000","message":"I\u0027m testing out a CONF.trace option here:\n\nhttps://review.openstack.org/#/c/366423/","commit_id":"ac17d55b7d36ef078aca1b4979622067e7eecf6f"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"278ff88ab0c1755da671933507f16378cd4b48fc","unresolved":false,"context_lines":[{"line_number":165,"context_line":"            # shared host state should be updated in a consistent way to make"},{"line_number":166,"context_line":"            # sure its data is valid under concurrent write operations."},{"line_number":167,"context_line":"            if compute is not None:"},{"line_number":168,"context_line":"                LOG.trace(\"Update host state from compute node: %s\", compute)"},{"line_number":169,"context_line":"                self._update_from_compute_node(compute)"},{"line_number":170,"context_line":"            if aggregates is not None:"},{"line_number":171,"context_line":"                LOG.trace(\"Update host state with aggregates: %s\", aggregates)"}],"source_content_type":"text/x-python","patch_set":2,"id":"9a89bdaa_f8b7b037","line":168,"range":{"start_line":168,"start_character":20,"end_line":168,"end_character":25},"in_reply_to":"9a89bdaa_dee3b9a2","updated":"2016-09-07 02:14:56.000000000","message":"FYI, this is what it looks like with CONF.trace\u003dTrue:\n\nhttp://logs.openstack.org/23/366423/1/check/gate-tempest-dsvm-neutron-src-oslo.log/7017d40/logs/screen-n-sch.txt.gz#_2016-09-07_00_49_55_145","commit_id":"ac17d55b7d36ef078aca1b4979622067e7eecf6f"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"c8768fb140734186bedb5f8f972493cb3f88377c","unresolved":false,"context_lines":[{"line_number":165,"context_line":"            # shared host state should be updated in a consistent way to make"},{"line_number":166,"context_line":"            # sure its data is valid under concurrent write operations."},{"line_number":167,"context_line":"            if compute is not None:"},{"line_number":168,"context_line":"                LOG.trace(\"Update host state from compute node: %s\", compute)"},{"line_number":169,"context_line":"                self._update_from_compute_node(compute)"},{"line_number":170,"context_line":"            if aggregates is not None:"},{"line_number":171,"context_line":"                LOG.trace(\"Update host state with aggregates: %s\", aggregates)"}],"source_content_type":"text/x-python","patch_set":2,"id":"9a89bdaa_21ac808b","line":168,"range":{"start_line":168,"start_character":20,"end_line":168,"end_character":25},"in_reply_to":"9a89bdaa_f8b7b037","updated":"2016-09-07 07:24:53.000000000","message":"FWIW, what I don\u0027t understand is that you seem to say it\u0027s impossible to run DEBUG for a specific service, right?\n\nCouldn\u0027t we just assume some service needing to run in DEBUG mode would have a separate conf file, or that we would override the log value at the command line ?\n\nEither way, like I said yesterday on IRC, I\u0027m very not convinced that adding a new log level (being TRACE) for that specific method would really benefit.","commit_id":"ac17d55b7d36ef078aca1b4979622067e7eecf6f"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"7410ceabcf4a249d707993390fe953ba045da02b","unresolved":false,"context_lines":[{"line_number":175,"context_line":"                self.service \u003d ReadOnlyDict(service)"},{"line_number":176,"context_line":"            if inst_dict is not None:"},{"line_number":177,"context_line":"                LOG.trace(\"Update host state with instances: %s\", inst_dict)"},{"line_number":178,"context_line":"                self.instances \u003d inst_dict"},{"line_number":179,"context_line":""},{"line_number":180,"context_line":"        return _locked_update(self, compute, service, aggregates, inst_dict)"},{"line_number":181,"context_line":""}],"source_content_type":"text/x-python","patch_set":2,"id":"9a89bdaa_222735b7","line":178,"updated":"2016-09-06 19:24:03.000000000","message":"So I think the real problem is that sometimes operators need to run DEBUG level in production so as to get crucial information for some bad placement, but to be honest, if that situation was having good levels, they wouldn\u0027t need to run that debug. Sure, that patch wouldn\u0027t hurt by reducing the log verbosity for debug, but I honestly think we don\u0027t really help the operators.","commit_id":"ac17d55b7d36ef078aca1b4979622067e7eecf6f"},{"author":{"_account_id":2750,"name":"Sean Dague","email":"sean@dague.net","username":"sdague"},"change_message_id":"928ec2c951da4f4c4c7dbdd8671a94184e5a9874","unresolved":false,"context_lines":[{"line_number":175,"context_line":"                self.service \u003d ReadOnlyDict(service)"},{"line_number":176,"context_line":"            if inst_dict is not None:"},{"line_number":177,"context_line":"                LOG.trace(\"Update host state with instances: %s\", inst_dict)"},{"line_number":178,"context_line":"                self.instances \u003d inst_dict"},{"line_number":179,"context_line":""},{"line_number":180,"context_line":"        return _locked_update(self, compute, service, aggregates, inst_dict)"},{"line_number":181,"context_line":""}],"source_content_type":"text/x-python","patch_set":2,"id":"9a89bdaa_5803980d","line":178,"in_reply_to":"9a89bdaa_222735b7","updated":"2016-09-09 13:36:14.000000000","message":"@ryan, have you looked at what happens if you move the debug log out of the critical section? So basically do the debug logging up front, only do the critical section for the variable assignments. Would be curious what the select destinations looks like under that case. Because then the lock wouldn\u0027t be held very long in the inst_dict case. Those numbers mostly make it feel like the issue is that there is so much contension on the lock, that every ms spent doing anything stacks up the requests on it even further.","commit_id":"ac17d55b7d36ef078aca1b4979622067e7eecf6f"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"359be7463fd88957d2d8ca870443c70e8b3b984d","unresolved":false,"context_lines":[{"line_number":179,"context_line":"            if inst_dict is not None:"},{"line_number":180,"context_line":"                LOG.trace(\"Update host state with instances: %s\","},{"line_number":181,"context_line":"                          list(inst_dict))"},{"line_number":182,"context_line":"                self.instances \u003d inst_dict"},{"line_number":183,"context_line":""},{"line_number":184,"context_line":"        return _locked_update(self, compute, service, aggregates, inst_dict)"},{"line_number":185,"context_line":""}],"source_content_type":"text/x-python","patch_set":4,"id":"3f79a3b5_6073e917","line":182,"updated":"2018-09-12 16:31:12.000000000","message":"well, I\u0027m very well torn with this and I don\u0027t know the right angle to follow for that.\n\nThere are many ways to consider the issue. We can surely change the level and put TRACE on it, but when wouldn\u0027t that punt the problem down to another level ?\n\nAnyway, if we go with this change, I think we should communicate as an upgrade impact that some logs are being moved to the TRACE level.","commit_id":"d8c2088d9c34a4cff1ba6c3c9e611e7b7f965e7f"},{"author":{"_account_id":9373,"name":"Vlad Gusev","email":"vlad.esten@gmail.com","username":"s10"},"change_message_id":"ed4d3d888710cc80634d8a5485cc3eb9433ff451","unresolved":false,"context_lines":[{"line_number":179,"context_line":"            if inst_dict is not None:"},{"line_number":180,"context_line":"                LOG.trace(\"Update host state with instances: %s\","},{"line_number":181,"context_line":"                          list(inst_dict))"},{"line_number":182,"context_line":"                self.instances \u003d inst_dict"},{"line_number":183,"context_line":""},{"line_number":184,"context_line":"        return _locked_update(self, compute, service, aggregates, inst_dict)"},{"line_number":185,"context_line":""}],"source_content_type":"text/x-python","patch_set":4,"id":"3f79a3b5_74540f23","line":182,"in_reply_to":"3f79a3b5_6073e917","updated":"2018-10-08 12:09:37.000000000","message":"There\u0027s almost nothing can be done with the fact that current debug inst_dict logs can produce megabytes per second of useless logs for large deployments, which should be written before scheduling because of the @synchronized.\n\nI agree that release note about this change should be added.","commit_id":"d8c2088d9c34a4cff1ba6c3c9e611e7b7f965e7f"}]}