)]}'
{"specs/approved/iscsi-deploy-in-band-cleaning.rst":[{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"e2f2bf3dfce86f6b8b8da3abf6883a22f761bbe7","unresolved":false,"context_lines":[{"line_number":97,"context_line":"                empty list if bash ramdisk is used."},{"line_number":98,"context_line":"        \"\"\""},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"* For deployers who have been using DIB ramdisk, the node will be stuck i"},{"line_number":101,"context_line":"  n ``states.CLEANWAIT`` when they try to do cleaning.  This is because"},{"line_number":102,"context_line":"  DIB ramdisk doesn\u0027t heartbeat like agent ramdisk.  Hence, such deployers"},{"line_number":103,"context_line":"  might face the issue with nodes moving to ``states.CLEANFAIL``"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3a29b11f_31daec17","line":100,"updated":"2015-10-23 09:11:10.000000000","message":"nit: weird word wrapping in the middle of \"in\"","commit_id":"efa78ef70f96b6427171dd6f2d68786dbe530e90"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"e2f2bf3dfce86f6b8b8da3abf6883a22f761bbe7","unresolved":false,"context_lines":[{"line_number":118,"context_line":"Alternatives"},{"line_number":119,"context_line":"------------"},{"line_number":120,"context_line":""},{"line_number":121,"context_line":"None."},{"line_number":122,"context_line":""},{"line_number":123,"context_line":"Data model impact"},{"line_number":124,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3a29b11f_51d528e2","line":121,"updated":"2015-10-23 09:11:10.000000000","message":"I don\u0027t quite get what abort would solve..","commit_id":"efa78ef70f96b6427171dd6f2d68786dbe530e90"},{"author":{"_account_id":13719,"name":"Naohiro Tamura","email":"naohirot.openstack@gmail.com","username":"nao"},"change_message_id":"7a8c1063be0a5228d1bb55746c175df1d1546a27","unresolved":false,"context_lines":[{"line_number":118,"context_line":"Alternatives"},{"line_number":119,"context_line":"------------"},{"line_number":120,"context_line":""},{"line_number":121,"context_line":"None."},{"line_number":122,"context_line":""},{"line_number":123,"context_line":"Data model impact"},{"line_number":124,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3a29b11f_a5f79ed1","line":121,"updated":"2015-10-23 06:35:30.000000000","message":"In order to overcome the problem at the line 104, can\u0027t we use the \u0027abort\u0027 [1] as an alternative?\n\n[1] https://review.openstack.org/#/c/201552/\n\nIt could be an alternative, it would be better to mention about \u0027abort\u0027 in this section or other appropriate section.","commit_id":"efa78ef70f96b6427171dd6f2d68786dbe530e90"},{"author":{"_account_id":9315,"name":"ramesh","email":"rameshg87@gmail.com","username":"rameshg87"},"change_message_id":"3b7a3636c0df01b922d7596175a4bcf198660b4e","unresolved":false,"context_lines":[{"line_number":118,"context_line":"Alternatives"},{"line_number":119,"context_line":"------------"},{"line_number":120,"context_line":""},{"line_number":121,"context_line":"None."},{"line_number":122,"context_line":""},{"line_number":123,"context_line":"Data model impact"},{"line_number":124,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3a29b11f_05bd32d7","line":121,"in_reply_to":"3a29b11f_a5f79ed1","updated":"2015-10-23 06:39:32.000000000","message":"Yes, we could use abort.  But it would be bad if we break people\u0027s workflow immediately that has been working for quite a long time.  And abort would require manual intervention every time - people have to watch out for failing nodes after a tear down.  So, I wonder if we can really consider it as an alternative.  \n\nAlso, if aborted, they cannot execute clean steps of other interfaces (like management interface)","commit_id":"efa78ef70f96b6427171dd6f2d68786dbe530e90"}]}