)]}'
{"ironic_python_agent/hardware.py":[{"author":{"_account_id":10342,"name":"Jay Faulkner","display_name":"JayF","email":"jay@jvf.cc","username":"JayF","status":"youtube.com/@oss-gr / podcast.gr-oss.io"},"change_message_id":"040ffa3c34b0fb140f194d504a9498cde3b6759b","unresolved":true,"context_lines":[{"line_number":1402,"context_line":"        \"\"\""},{"line_number":1403,"context_line":"        burnin.stress_ng_cpu(node)"},{"line_number":1404,"context_line":""},{"line_number":1405,"context_line":"    def burnin_memory(self, node, ports):"},{"line_number":1406,"context_line":"        \"\"\"Burn-in the memory"},{"line_number":1407,"context_line":""},{"line_number":1408,"context_line":"        :param node: Ironic node object"}],"source_content_type":"text/x-python","patch_set":2,"id":"94da9424_95249d34","line":1405,"updated":"2021-05-04 18:00:58.000000000","message":"We already have other burnin steps added, so this feedback is probably too late to be actioned, but I really wish we had isolated all these burn-in steps inside a separate hardware manager.","commit_id":"5c222560f07fff9478b063d401f4415e1139f496"},{"author":{"_account_id":15519,"name":"Iury Gregory Melo Ferreira","display_name":"Iury Gregory","email":"iurygregory@gmail.com","username":"iurygregory"},"change_message_id":"0f384637ea79788932bcb09e82bbdb3d3fd54c06","unresolved":true,"context_lines":[{"line_number":1402,"context_line":"        \"\"\""},{"line_number":1403,"context_line":"        burnin.stress_ng_cpu(node)"},{"line_number":1404,"context_line":""},{"line_number":1405,"context_line":"    def burnin_memory(self, node, ports):"},{"line_number":1406,"context_line":"        \"\"\"Burn-in the memory"},{"line_number":1407,"context_line":""},{"line_number":1408,"context_line":"        :param node: Ironic node object"}],"source_content_type":"text/x-python","patch_set":2,"id":"1e4b15d0_7fd3b5b1","line":1405,"in_reply_to":"88bea962_fd79e34e","updated":"2021-05-11 08:11:15.000000000","message":"I agree, we can move forward with the remaining ones and do a follow-up if we think we should move to a dedicated hardware manager.","commit_id":"5c222560f07fff9478b063d401f4415e1139f496"},{"author":{"_account_id":11292,"name":"Arne Wiebalck","email":"Arne.Wiebalck@cern.ch","username":"wiebalck"},"change_message_id":"e991cfe28dfc400eeb4853d5f017d90939eb2f5a","unresolved":true,"context_lines":[{"line_number":1402,"context_line":"        \"\"\""},{"line_number":1403,"context_line":"        burnin.stress_ng_cpu(node)"},{"line_number":1404,"context_line":""},{"line_number":1405,"context_line":"    def burnin_memory(self, node, ports):"},{"line_number":1406,"context_line":"        \"\"\"Burn-in the memory"},{"line_number":1407,"context_line":""},{"line_number":1408,"context_line":"        :param node: Ironic node object"}],"source_content_type":"text/x-python","patch_set":2,"id":"88bea962_fd79e34e","line":1405,"in_reply_to":"94da9424_95249d34","updated":"2021-05-11 08:05:54.000000000","message":"My thinking was to have these (relatively generic steps) in the generic manager to allow for downstream managers to inherit these steps and activate/use them in an easy way, similar to s/w RAID or pstore. I guess this would also be possible with a dedicated hardware manager (?). Anyway, as you mention, since we have other burn-in steps merged this way already, I would suggest to complete the remaining ones (disk, network) in the same way. If then there is a strong feeling to re-factor, we could do this in a follow-up.","commit_id":"5c222560f07fff9478b063d401f4415e1139f496"}]}