)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"e84f4c024cb16b8faecd7c094ea022585c511e3f","unresolved":false,"context_lines":[{"line_number":14,"context_line":"then make device_path in connection_info refer"},{"line_number":15,"context_line":"to the new decrypted device."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"When rebooting an instance, Nova instance is shut down without any"},{"line_number":18,"context_line":"detaching operations. This seems incorrect, ideally it should detach"},{"line_number":19,"context_line":"encryptor when powering off, and re-attach when starting."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"Change-Id: I9427d67080c5cbab84bbcdc24f37673abb301df3"},{"line_number":22,"context_line":"Closes-Bug: #1597234"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"1ac06dbe_47fd6539","line":19,"range":{"start_line":17,"start_character":0,"end_line":19,"end_character":57},"updated":"2016-08-25 19:09:28.000000000","message":"Why do you think that? Detaching and reattaching seems like unnecessary work to me.","commit_id":"aa03eec64e69d180ff11cc2d511d89b19a8268c6"},{"author":{"_account_id":22257,"name":"Manish","email":"deolalkar.manish@hpe.com","username":"manishd"},"change_message_id":"77657e7ccf463fb0d29097c048834ffce95c9bf8","unresolved":false,"context_lines":[{"line_number":14,"context_line":"then make device_path in connection_info refer"},{"line_number":15,"context_line":"to the new decrypted device."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"When rebooting an instance, Nova instance is shut down without any"},{"line_number":18,"context_line":"detaching operations. This seems incorrect, ideally it should detach"},{"line_number":19,"context_line":"encryptor when powering off, and re-attach when starting."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"Change-Id: I9427d67080c5cbab84bbcdc24f37673abb301df3"},{"line_number":22,"context_line":"Closes-Bug: #1597234"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"fa7ab95a_7696ca95","line":19,"range":{"start_line":17,"start_character":0,"end_line":19,"end_character":57},"in_reply_to":"1ac06dbe_47fd6539","updated":"2016-08-26 04:46:18.000000000","message":"Thanks for reviewing Dan.\n\nplease refer below details:- \n\nFor non-encrypted volume, Nova calls connect_volume to do attaching. This returns connection_info which includes \u0027device_path\u0027 that shows the device path in computer host.\n\nWith encrypted volume, after the above steps, it needs to decrypt the device. It creates a decrpted device with \u0027cryptset open\u0027, and then make device_path in connection_info refer to the new decrypted device.\n\nWhen rebooting an VM, Nova instance is shut down without any detaching/disconnection operations. But when starting, it calls connect_volume for every block device. For encrypted volumes, as device_path refers to a decrypted device after opening. It can\u0027t be run with scsi_id. As a result, call to connect_volume on the decrypted device leads exception.\n\nPossible Solutions were:-\n1. Skip the connect_volume for Encrypted Volumes during reboot\n2. to disconnect dmcrypt device when down and then re-attach the device when up\n\nSecond solution makes sense and was suggested in community.","commit_id":"aa03eec64e69d180ff11cc2d511d89b19a8268c6"},{"author":{"_account_id":15961,"name":"lisali","email":"xiaoyan.li@intel.com","username":"lisali"},"change_message_id":"18656e73120edb56bcc2001ef5453eb0554094af","unresolved":false,"context_lines":[{"line_number":14,"context_line":"then make device_path in connection_info refer"},{"line_number":15,"context_line":"to the new decrypted device."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"When rebooting an instance, Nova instance is shut down without any"},{"line_number":18,"context_line":"detaching operations. This seems incorrect, ideally it should detach"},{"line_number":19,"context_line":"encryptor when powering off, and re-attach when starting."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"Change-Id: I9427d67080c5cbab84bbcdc24f37673abb301df3"},{"line_number":22,"context_line":"Closes-Bug: #1597234"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"7a8ec9b2_2c1786a4","line":19,"range":{"start_line":17,"start_character":0,"end_line":19,"end_character":57},"in_reply_to":"7a8ec9b2_07d63cc5","updated":"2016-09-14 07:26:46.000000000","message":"The similar problem also exists when VM shuts down and reboots.\n\nI think it is better to detach when reboot/shutdown, especially for shutdown. \n\n1. It is safer to detach encryptor when shutting down.\n\n2. It  checks whether volume is good to use when attaching at boot time. If we use solution 1, this step is skipped.\n\n3. It is reasonable that to detach/attach encryptors when hard rebooting a VM.","commit_id":"aa03eec64e69d180ff11cc2d511d89b19a8268c6"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"70caf76bc99d83cdd9dfac546051444096f7ab70","unresolved":false,"context_lines":[{"line_number":14,"context_line":"then make device_path in connection_info refer"},{"line_number":15,"context_line":"to the new decrypted device."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"When rebooting an instance, Nova instance is shut down without any"},{"line_number":18,"context_line":"detaching operations. This seems incorrect, ideally it should detach"},{"line_number":19,"context_line":"encryptor when powering off, and re-attach when starting."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"Change-Id: I9427d67080c5cbab84bbcdc24f37673abb301df3"},{"line_number":22,"context_line":"Closes-Bug: #1597234"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"7a8ec9b2_07d63cc5","line":19,"range":{"start_line":17,"start_character":0,"end_line":19,"end_character":57},"in_reply_to":"fa7ab95a_7696ca95","updated":"2016-09-13 18:39:21.000000000","message":"The second solution creates more churn and more opportunity for us to fail when talking to cinder, just to do a reboot. If we don\u0027t need to do a thing on reboot, then just fix that. If we need to pass more information to the lower layers so they know the encrypted device, then do that.\n\nJust hacking it to detach and reattach is bolting on something to a bolt-on, and increases the opportunity to fail just because of load-based failures in cinder-api or any number of other things.","commit_id":"aa03eec64e69d180ff11cc2d511d89b19a8268c6"}],"nova/virt/libvirt/driver.py":[{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"70caf76bc99d83cdd9dfac546051444096f7ab70","unresolved":false,"context_lines":[{"line_number":2315,"context_line":"        self._create_domain_and_network(context, xml, instance, network_info,"},{"line_number":2316,"context_line":"                                        disk_info,"},{"line_number":2317,"context_line":"                                        block_device_info\u003dblock_device_info,"},{"line_number":2318,"context_line":"                                        reboot\u003dFalse,"},{"line_number":2319,"context_line":"                                        vifs_already_plugged\u003dTrue)"},{"line_number":2320,"context_line":"        self._prepare_pci_devices_for_use("},{"line_number":2321,"context_line":"            pci_manager.get_instance_pci_devs(instance, \u0027all\u0027))"}],"source_content_type":"text/x-python","patch_set":2,"id":"7a8ec9b2_a7302809","line":2318,"updated":"2016-09-13 18:39:21.000000000","message":"This is not cool, IMHO, because you *are* rebooting. If you have to do this, you need to change this to connect_things\u003dFalse or something that indicates what you\u0027re actually doing.","commit_id":"aa03eec64e69d180ff11cc2d511d89b19a8268c6"},{"author":{"_account_id":6608,"name":"Paul Carlton","email":"paul.carlton2@hpe.com","username":"paul-carlton2"},"change_message_id":"61fd8ba8e288147eb4ae41ea86f4ded05f7609fa","unresolved":false,"context_lines":[{"line_number":2315,"context_line":"        self._create_domain_and_network(context, xml, instance, network_info,"},{"line_number":2316,"context_line":"                                        disk_info,"},{"line_number":2317,"context_line":"                                        block_device_info\u003dblock_device_info,"},{"line_number":2318,"context_line":"                                        reboot\u003dFalse,"},{"line_number":2319,"context_line":"                                        vifs_already_plugged\u003dTrue)"},{"line_number":2320,"context_line":"        self._prepare_pci_devices_for_use("},{"line_number":2321,"context_line":"            pci_manager.get_instance_pci_devs(instance, \u0027all\u0027))"}],"source_content_type":"text/x-python","patch_set":2,"id":"ba5da102_f6a039f6","line":2318,"in_reply_to":"7a8ec9b2_a7302809","updated":"2016-11-03 16:16:54.000000000","message":"Done","commit_id":"aa03eec64e69d180ff11cc2d511d89b19a8268c6"}],"nova/volume/encryptors/luks.py":[{"author":{"_account_id":6608,"name":"Paul Carlton","email":"paul.carlton2@hpe.com","username":"paul-carlton2"},"change_message_id":"d042efb3ca1e08e3245dd7254839e0ff733cf890","unresolved":false,"context_lines":[{"line_number":136,"context_line":"            LOG.debug(\"recovering link of encrypted volume %s\", self.dev_path)"},{"line_number":137,"context_line":"            utils.execute(\u0027ln\u0027, \u0027--symbolic\u0027, \u0027--force\u0027,"},{"line_number":138,"context_line":"                          original_device, self.symlink_path,"},{"line_number":139,"context_line":"                          run_as_root\u003dTrue, check_exit_code\u003dTrue)"}],"source_content_type":"text/x-python","patch_set":3,"id":"9a629dbe_193a1e37","line":139,"updated":"2016-11-07 13:02:53.000000000","message":"Manish, seems to me that creating this link is failing because the /dev/mapper/crypt... file is missing, possibly removed by the above cryptsetup luksClose operation?  I think you need to make this code cater for the scenario where that file is missing?\n\nThe reboot operation is calling _connect_volume which (if I skip over the issue with the missing /dev/mapper/crypt... file in closedown) fails because the /dev/disk/by-path/ip... file is not present.  This is so because it failed to create it as a link to the /dev/mapper/crypt...file due to that being missing.  Seems to me that the teardown is not leaving it in the expected state.\n\nThus the right approach seems to me to be to cater for the worst case scenario i.e. catch errors like the failed ln and/or verify the target file exists before attempting the ln.  Then check what artifacts relating to the encrypted volume exist and if not as expected teardown the connection and rebuild it?","commit_id":"67fdd403aa68e7ae2ef2b3d6d29cabf25be94fe1"}]}