)]}'
{"nova/compute/manager.py":[{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"0de9298dad1c27a91fa474eedb1e79aba2156df7","unresolved":false,"context_lines":[{"line_number":6022,"context_line":"                            instance\u003ddb_instance)"},{"line_number":6023,"context_line":"                try:"},{"line_number":6024,"context_line":"                    if (vm_power_state \u003d\u003d RUNNING and"},{"line_number":6025,"context_line":"                            CONF.resume_guests_state_on_host_boot):"},{"line_number":6026,"context_line":"                        LOG.warning(_LW(\u0027Rebooting the instance to sync up \u0027"},{"line_number":6027,"context_line":"                                        \u0027the nova-compute service with the \u0027"},{"line_number":6028,"context_line":"                                        \u0027hypervisor.\u0027),"}],"source_content_type":"text/x-python","patch_set":1,"id":"da20952f_0801e137","line":6025,"updated":"2015-08-31 18:25:48.000000000","message":"Obviously this config option name is not the best for this context - so we could add a new one or rename this one so it has dual purposes.","commit_id":"6d669f2f02491b31b43a2e500d40e598fe1b0372"},{"author":{"_account_id":1653,"name":"garyk","email":"gkotton@vmware.com","username":"garyk"},"change_message_id":"2798b8dee292573bdc8144c825c970ee1eade197","unresolved":false,"context_lines":[{"line_number":6022,"context_line":"                            instance\u003ddb_instance)"},{"line_number":6023,"context_line":"                try:"},{"line_number":6024,"context_line":"                    if (vm_power_state \u003d\u003d RUNNING and"},{"line_number":6025,"context_line":"                            CONF.resume_guests_state_on_host_boot):"},{"line_number":6026,"context_line":"                        LOG.warning(_LW(\u0027Rebooting the instance to sync up \u0027"},{"line_number":6027,"context_line":"                                        \u0027the nova-compute service with the \u0027"},{"line_number":6028,"context_line":"                                        \u0027hypervisor.\u0027),"}],"source_content_type":"text/x-python","patch_set":1,"id":"da20952f_082481c2","line":6025,"in_reply_to":"da20952f_0801e137","updated":"2015-08-31 18:28:47.000000000","message":"i would introduce a new configuration variable\n\ni think that there should also be an option for just continuing without doing a reboot - for example if this is started by the underlying hypervisor","commit_id":"6d669f2f02491b31b43a2e500d40e598fe1b0372"},{"author":{"_account_id":1653,"name":"garyk","email":"gkotton@vmware.com","username":"garyk"},"change_message_id":"5734ad94f3bcbda7416575245ff2a0e1410498b6","unresolved":false,"context_lines":[{"line_number":6022,"context_line":"                            instance\u003ddb_instance)"},{"line_number":6023,"context_line":"                try:"},{"line_number":6024,"context_line":"                    if (vm_power_state \u003d\u003d power_state.RUNNING and"},{"line_number":6025,"context_line":"                            CONF.resume_guests_state_on_host_boot):"},{"line_number":6026,"context_line":"                        LOG.warning(_LW(\u0027Rebooting the instance to sync up \u0027"},{"line_number":6027,"context_line":"                                        \u0027the nova-compute service with the \u0027"},{"line_number":6028,"context_line":"                                        \u0027hypervisor.\u0027),"}],"source_content_type":"text/x-python","patch_set":2,"id":"da20952f_61318a59","line":6025,"updated":"2015-09-01 02:51:35.000000000","message":"i think that we should introduce a new configuration variable that has the following options:\n1. reboot\n2. stop\n3. use hypervisor state\n\nI think the use the existing varible is and can be problematic. For example in some drivers one may not need to set resume_guests_state_on_host_boot as restarting the compute node should not restart instances.\n\nAlso in the case of libvirt this may also break existing workflows.","commit_id":"f764f473d34d1d939c557071c9ed6add7fbf0a66"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"683bcb3fae17bf8f9cfdcd672126a4181d7238c6","unresolved":false,"context_lines":[{"line_number":6022,"context_line":"                            instance\u003ddb_instance)"},{"line_number":6023,"context_line":"                try:"},{"line_number":6024,"context_line":"                    if (vm_power_state \u003d\u003d power_state.RUNNING and"},{"line_number":6025,"context_line":"                            CONF.resume_guests_state_on_host_boot):"},{"line_number":6026,"context_line":"                        LOG.warning(_LW(\u0027Rebooting the instance to sync up \u0027"},{"line_number":6027,"context_line":"                                        \u0027the nova-compute service with the \u0027"},{"line_number":6028,"context_line":"                                        \u0027hypervisor.\u0027),"}],"source_content_type":"text/x-python","patch_set":2,"id":"9a1a9d01_9b8ebdce","line":6025,"in_reply_to":"9a1a9d01_3bf0d166","updated":"2015-09-29 20:05:11.000000000","message":"If we put it in error state we could post an instance fault with it so the admin/user could see why it went to error state.","commit_id":"f764f473d34d1d939c557071c9ed6add7fbf0a66"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"85481bc56f9dc206e8f9270b7e2ffe75e7ed2444","unresolved":false,"context_lines":[{"line_number":6022,"context_line":"                            instance\u003ddb_instance)"},{"line_number":6023,"context_line":"                try:"},{"line_number":6024,"context_line":"                    if (vm_power_state \u003d\u003d power_state.RUNNING and"},{"line_number":6025,"context_line":"                            CONF.resume_guests_state_on_host_boot):"},{"line_number":6026,"context_line":"                        LOG.warning(_LW(\u0027Rebooting the instance to sync up \u0027"},{"line_number":6027,"context_line":"                                        \u0027the nova-compute service with the \u0027"},{"line_number":6028,"context_line":"                                        \u0027hypervisor.\u0027),"}],"source_content_type":"text/x-python","patch_set":2,"id":"9a1a9d01_4f893f74","line":6025,"in_reply_to":"9a1a9d01_4f061f1e","updated":"2015-09-29 21:37:00.000000000","message":"Clarified in IRC.  I was missing the vmware case where in pass one the vm_state is active and hypervisor power state is shutdown, so the task stops the instance.  Then in pass 2 the vm_state is stopped by the hypervisor says the guest is running.  Today we stop it, but if we added the flag in pass 1 we\u0027d see, oh we stopped the thing in the first place, must have been some HA event or whatever, let\u0027s just reboot it.","commit_id":"f764f473d34d1d939c557071c9ed6add7fbf0a66"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"77f7b035c2b0442a2196da676db3ff0c267e3a1f","unresolved":false,"context_lines":[{"line_number":6022,"context_line":"                            instance\u003ddb_instance)"},{"line_number":6023,"context_line":"                try:"},{"line_number":6024,"context_line":"                    if (vm_power_state \u003d\u003d power_state.RUNNING and"},{"line_number":6025,"context_line":"                            CONF.resume_guests_state_on_host_boot):"},{"line_number":6026,"context_line":"                        LOG.warning(_LW(\u0027Rebooting the instance to sync up \u0027"},{"line_number":6027,"context_line":"                                        \u0027the nova-compute service with the \u0027"},{"line_number":6028,"context_line":"                                        \u0027hypervisor.\u0027),"}],"source_content_type":"text/x-python","patch_set":2,"id":"9a1a9d01_3bf0d166","line":6025,"in_reply_to":"9a1a9d01_58ceeb2e","updated":"2015-09-29 20:04:07.000000000","message":"ctrath had another idea which is put the instance into error state because we don\u0027t know what to do with it, but then that leaves the corrective action up to the user, i.e. they could do a \u0027nova reset-state --active\u0027 on it which puts it back into ACTIVE state if it\u0027s actually running on the hypervisor (we could even do that in the task itself).  Or they could do a hard reboot on it themselves if it\u0027s in error state.","commit_id":"f764f473d34d1d939c557071c9ed6add7fbf0a66"},{"author":{"_account_id":5441,"name":"Andrew Laski","email":"andrew@lascii.com","username":"alaski"},"change_message_id":"72318382d61b2e73d8af797cc4539683db8efebb","unresolved":false,"context_lines":[{"line_number":6022,"context_line":"                            instance\u003ddb_instance)"},{"line_number":6023,"context_line":"                try:"},{"line_number":6024,"context_line":"                    if (vm_power_state \u003d\u003d power_state.RUNNING and"},{"line_number":6025,"context_line":"                            CONF.resume_guests_state_on_host_boot):"},{"line_number":6026,"context_line":"                        LOG.warning(_LW(\u0027Rebooting the instance to sync up \u0027"},{"line_number":6027,"context_line":"                                        \u0027the nova-compute service with the \u0027"},{"line_number":6028,"context_line":"                                        \u0027hypervisor.\u0027),"}],"source_content_type":"text/x-python","patch_set":2,"id":"9a1a9d01_6f1be373","line":6025,"in_reply_to":"9a1a9d01_84a5fe47","updated":"2015-09-29 21:32:46.000000000","message":"Fair point, we probably would.  But it would be more isolated.","commit_id":"f764f473d34d1d939c557071c9ed6add7fbf0a66"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"7c3a5232f9a1ef48a9684682e3437d3a17e2774f","unresolved":false,"context_lines":[{"line_number":6022,"context_line":"                            instance\u003ddb_instance)"},{"line_number":6023,"context_line":"                try:"},{"line_number":6024,"context_line":"                    if (vm_power_state \u003d\u003d power_state.RUNNING and"},{"line_number":6025,"context_line":"                            CONF.resume_guests_state_on_host_boot):"},{"line_number":6026,"context_line":"                        LOG.warning(_LW(\u0027Rebooting the instance to sync up \u0027"},{"line_number":6027,"context_line":"                                        \u0027the nova-compute service with the \u0027"},{"line_number":6028,"context_line":"                                        \u0027hypervisor.\u0027),"}],"source_content_type":"text/x-python","patch_set":2,"id":"9a1a9d01_4f061f1e","line":6025,"in_reply_to":"9a1a9d01_84a5fe47","updated":"2015-09-29 21:34:03.000000000","message":"We probably need to clarify in what case we set the flag and how it\u0027s handled.  We talked about a 2 pass approach in IRC but I\u0027m a bit fuzzy on it now again.  I thought we were saying something like:\n\n1. pass one the vm_state is stopped but running in hypervisor\n\n2. we stop the instance and set the sysmeta flag (sync_stopped\u003dTrue or whatever)\n\n3. pass two the vm_state is stopped and flag is set - but at this point if the guest isn\u0027t running on the hypervisor because we stopped it in #1, then we don\u0027t get to a point where we reboot it - so in that case how do we distinguish when to reboot it?","commit_id":"f764f473d34d1d939c557071c9ed6add7fbf0a66"},{"author":{"_account_id":5441,"name":"Andrew Laski","email":"andrew@lascii.com","username":"alaski"},"change_message_id":"637aeb85deecd855cbf39917e802db204de18299","unresolved":false,"context_lines":[{"line_number":6022,"context_line":"                            instance\u003ddb_instance)"},{"line_number":6023,"context_line":"                try:"},{"line_number":6024,"context_line":"                    if (vm_power_state \u003d\u003d power_state.RUNNING and"},{"line_number":6025,"context_line":"                            CONF.resume_guests_state_on_host_boot):"},{"line_number":6026,"context_line":"                        LOG.warning(_LW(\u0027Rebooting the instance to sync up \u0027"},{"line_number":6027,"context_line":"                                        \u0027the nova-compute service with the \u0027"},{"line_number":6028,"context_line":"                                        \u0027hypervisor.\u0027),"}],"source_content_type":"text/x-python","patch_set":2,"id":"9a1a9d01_c4253609","line":6025,"in_reply_to":"9a1a9d01_9b8ebdce","updated":"2015-09-29 21:22:42.000000000","message":"My concern here is that the config option allows operators to switch between having this work for the case where a user made an API request to stop an instance, and having this work for the case where the instance is stopped due to the hypervisor saying it should be at one point and then now saying that it shouldn\u0027t be.  In the first case the force_stop is correct and in the second a reboot or error state or something else would be correct.\n\nWhat would be preferable is if we could distinguish between them so that we could do the right thing for each.  I would suggest that we continue to force_stop here unless there\u0027s an indication that the vm_state \u003d\u003d vm_states.STOPPED because of a previous power state sync or lifecycle event.  Perhaps something like a system_metadata entry (mriedems idea).  Then no config option is necessary and operators don\u0027t have to choose which case to support.","commit_id":"f764f473d34d1d939c557071c9ed6add7fbf0a66"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"1be3f0e2b8df75f3656d55e76abee2385628a453","unresolved":false,"context_lines":[{"line_number":6022,"context_line":"                            instance\u003ddb_instance)"},{"line_number":6023,"context_line":"                try:"},{"line_number":6024,"context_line":"                    if (vm_power_state \u003d\u003d power_state.RUNNING and"},{"line_number":6025,"context_line":"                            CONF.resume_guests_state_on_host_boot):"},{"line_number":6026,"context_line":"                        LOG.warning(_LW(\u0027Rebooting the instance to sync up \u0027"},{"line_number":6027,"context_line":"                                        \u0027the nova-compute service with the \u0027"},{"line_number":6028,"context_line":"                                        \u0027hypervisor.\u0027),"}],"source_content_type":"text/x-python","patch_set":2,"id":"9a1a9d01_84a5fe47","line":6025,"in_reply_to":"9a1a9d01_c4253609","updated":"2015-09-29 21:28:00.000000000","message":"I still think in the non-user case (hypervisor blip or whatever) we\u0027d still have a config option where the operator can tell it what to do, i.e. stop/reboot/error/noop.","commit_id":"f764f473d34d1d939c557071c9ed6add7fbf0a66"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"235c9e5b5c5b5583d3fcdf456d014a379d068ba8","unresolved":false,"context_lines":[{"line_number":6022,"context_line":"                            instance\u003ddb_instance)"},{"line_number":6023,"context_line":"                try:"},{"line_number":6024,"context_line":"                    if (vm_power_state \u003d\u003d power_state.RUNNING and"},{"line_number":6025,"context_line":"                            CONF.resume_guests_state_on_host_boot):"},{"line_number":6026,"context_line":"                        LOG.warning(_LW(\u0027Rebooting the instance to sync up \u0027"},{"line_number":6027,"context_line":"                                        \u0027the nova-compute service with the \u0027"},{"line_number":6028,"context_line":"                                        \u0027hypervisor.\u0027),"}],"source_content_type":"text/x-python","patch_set":2,"id":"9a1a9d01_58ceeb2e","line":6025,"in_reply_to":"da20952f_61318a59","updated":"2015-09-29 19:43:43.000000000","message":"Yeah so this was just a WIP to get the idea of what this could look like. I agree a new config option would be needed rather than reusing CONF.resume_guests_state_on_host_boot since that\u0027s really just for init_host.\n\nI only really see two options here though, stop and reboot with \u0027stop\u0027 being the default since that\u0027s what this does today.  I guess you could also have a noop option if you just want it logged.\n\nI\u0027m not sure how you\u0027d handle a \u0027use hypervisor state\u0027 unless you mean actually just updating the vm_state in the nova database.  I think that\u0027d be risky since we probably don\u0027t know what state the networking and block devices are in since something obviously blew up on the hypervisor side.\n\nReboot is not ideal since it still takes down your instance, but at least it brings it back up, or attempts to, whereas stop is just a stop even though it was running on the hypervisor.","commit_id":"f764f473d34d1d939c557071c9ed6add7fbf0a66"}]}