)]}'
{"nova/compute/manager.py":[{"author":{"_account_id":5511,"name":"Nikola Dipanov","email":"ndipanov@redhat.com","username":"ndipanov"},"change_message_id":"d36346617f06bc950d7a64c6366a4fca18b8e597","unresolved":false,"context_lines":[{"line_number":1466,"context_line":"    def start_instance(self, context, instance):"},{"line_number":1467,"context_line":"        \"\"\"Starting an instance on this host.\"\"\""},{"line_number":1468,"context_line":"        self._notify_about_instance_usage(context, instance, \"power_on.start\")"},{"line_number":1469,"context_line":"        self._ensure_block_devices(context, instance)"},{"line_number":1470,"context_line":"        self.driver.power_on(instance)"},{"line_number":1471,"context_line":"        current_power_state \u003d self._get_power_state(context, instance)"},{"line_number":1472,"context_line":"        instance \u003d self._instance_update(context, instance[\u0027uuid\u0027],"}],"source_content_type":"text/x-python","patch_set":4,"id":"AAAAPX%2F%2FvUI%3D","line":1469,"updated":"2013-06-11 16:39:00.000000000","message":"Hey Brent - A lot of this work is done in the _prep_block_device_method, which is called from _instance_update and rebuild_instance (not from reboot tho). \n\nLike this you would be doing potentially the same thing (or even worse - a slightly different thing) twice.\n\nI think it\u0027s better to find out how to refactor that one to deal with re-connecting then this.","commit_id":"0e0925c8e6e6c746fd504e36c70b61030c92ef46"},{"author":{"_account_id":5511,"name":"Nikola Dipanov","email":"ndipanov@redhat.com","username":"ndipanov"},"change_message_id":"d36346617f06bc950d7a64c6366a4fca18b8e597","unresolved":false,"context_lines":[{"line_number":2210,"context_line":"                    migration, migration[\u0027source_compute\u0027],"},{"line_number":2211,"context_line":"                    reservations)"},{"line_number":2212,"context_line":""},{"line_number":2213,"context_line":"    def _ensure_block_devices(self, context, instance):"},{"line_number":2214,"context_line":"        \"\"\"When restarting a VM after a reboot, or possibly under"},{"line_number":2215,"context_line":"        other conditions, volume sources may require re-initialization."},{"line_number":2216,"context_line":"        e.g. remounting a network attached filesystem."}],"source_content_type":"text/x-python","patch_set":4,"id":"AAAAPX%2F%2FvT4%3D","line":2213,"updated":"2013-06-11 16:39:00.000000000","message":"As in the comment above see _prep_block_device method on this class.","commit_id":"0e0925c8e6e6c746fd504e36c70b61030c92ef46"}],"nova/virt/libvirt/driver.py":[{"author":{"_account_id":1525,"name":"Rafi Khardalian","email":"rafi@metacloud.com","username":"rkhardalian"},"change_message_id":"378e64ad94bea38ae5cfec764b45998994cc2081","unresolved":false,"context_lines":[{"line_number":1462,"context_line":"        xml \u003d self._get_existing_domain_xml(instance, network_info,"},{"line_number":1463,"context_line":"                                            block_device_info)"},{"line_number":1464,"context_line":"        self._create_domain_and_network(xml, instance, network_info,"},{"line_number":1465,"context_line":"                                        block_device_info)"},{"line_number":1466,"context_line":""},{"line_number":1467,"context_line":"    def suspend(self, instance):"},{"line_number":1468,"context_line":"        \"\"\"Suspend the specified instance.\"\"\""}],"source_content_type":"text/x-python","patch_set":7,"id":"AAAAPn%2F%2F24U%3D","line":1465,"updated":"2013-06-19 17:18:27.000000000","message":"This will work just fine but you may want to call _hard_reboot() instead.  The reason is that if any backing files happened to have gone missing during the time the instance was shutdown, they\u0027ll get re-populated via that code path.\n\nI\u0027m going to submit a patch to rename _hard_reboot(), since it\u0027s useful for much more than just reboots.","commit_id":"fc7a2c92eef81b869e8f390b108c36b225fb122b"},{"author":{"_account_id":6681,"name":"Brent Eagles","email":"beagles@redhat.com","username":"beagles"},"change_message_id":"f69eb6f3cc8e894bec4756f88794f722741051a8","unresolved":false,"context_lines":[{"line_number":1462,"context_line":"        xml \u003d self._get_existing_domain_xml(instance, network_info,"},{"line_number":1463,"context_line":"                                            block_device_info)"},{"line_number":1464,"context_line":"        self._create_domain_and_network(xml, instance, network_info,"},{"line_number":1465,"context_line":"                                        block_device_info)"},{"line_number":1466,"context_line":""},{"line_number":1467,"context_line":"    def suspend(self, instance):"},{"line_number":1468,"context_line":"        \"\"\"Suspend the specified instance.\"\"\""}],"source_content_type":"text/x-python","patch_set":7,"id":"AAAAPn%2F%2F21o%3D","line":1465,"in_reply_to":"AAAAPn%2F%2F24U%3D","updated":"2013-06-19 18:00:06.000000000","message":"I was going to do that, saw the _destroy() there and decided not to to touch it. Now looking at power_off and what \"destroy\" means to libvirt, I see my reservations were groundless. Something related to think about is that the logs/exceptions are decidedly libvirt oriented and are not in line with what is going on with nova. I am imagining the conversations with users: \"I looked in the log file and it says an exception occurred when destroying the instance!!! I was starting the VM, not deleting it!\" :) \n\nI\u0027ll modify to simply use _hard_reboot. Cheers!","commit_id":"fc7a2c92eef81b869e8f390b108c36b225fb122b"}],"nova/virt/vmwareapi/vmops.py":[{"author":{"_account_id":191,"name":"Trey Morris","email":"trey.morris@rackspace.com","username":"tr3buchet"},"change_message_id":"1d3a545d663f875817aeb7456e01e6bf4ca1c9f6","unresolved":false,"context_lines":[{"line_number":852,"context_line":"            LOG.debug(_(\"Powered on the VM\"), instance\u003dinstance)"},{"line_number":853,"context_line":""},{"line_number":854,"context_line":"    def power_on(self, context, instance, network_info, block_device_info):"},{"line_number":855,"context_line":"        self._power_on(instance)"},{"line_number":856,"context_line":""},{"line_number":857,"context_line":"    def _get_orig_vm_name_label(self, instance):"},{"line_number":858,"context_line":"        return instance[\u0027name\u0027] + \u0027-orig\u0027"}],"source_content_type":"text/x-python","patch_set":9,"id":"AAAAPn%2F%2Fp3c%3D","line":855,"updated":"2013-06-25 21:30:48.000000000","message":"If the vmware driver is not going to call/use power_on() with the additional arguments, why not just let the driver accept, and ignore, those arguments, calling self._vmops.power_on(instance) as it did before? Why define this new function? Is it called somewhere I didn\u0027t see?","commit_id":"db3989586a8d5bbbcf857b9294a124ecc5fc57e8"}]}