Open Stack

Hi, guys 

I find that nova define VIR_DOMAIN_SHUTDOWN and VIR_DOMAIN_SHUTOFF as equal.  
And the comment in source code writes  
'
    # The libvirt API doc says that DOMAIN_SHUTDOWN means the domain 
    # is being shut down. So technically the domain is still 
    # running. SHUTOFF is the real powered off state.  But we will map 
    # both to SHUTDOWN anyway.
'
This design cause some problems. For example, in _clean_shutdown function, 
the author assume the VM is really shutdown if its power state in SHUTDOWN.
But in fact, SHUTDOWN state could either be VIR_DOMAIN_SHUTDOWN  or 
VIR_DOMAIN_SHUTOFF. So this assumption is not right and may cause other 
problems like https://bugs.launchpad.net/nova/+bug/1642689 

   def _clean_shutdown(self, instance, timeout, retry_interval):
        """Attempt to shutdown the instance gracefully.
        :param instance: The instance to be shutdown
        :param timeout: How long to wait in seconds for the instance to
                        shutdown
        :param retry_interval: How often in seconds to signal the instance
                               to shutdown while waiting
        :returns: True if the shutdown succeeded
        """

        # List of states that represent a shutdown instance
        SHUTDOWN_STATES = [power_state.SHUTDOWN,
                           power_state.CRASHED]

        try:
            guest = self._host.get_guest(instance)
        except exception.InstanceNotFound:
            # If the instance has gone then we don't need to
            # wait for it to shutdown
            return True

        state = guest.get_power_state(self._host)
        if state in SHUTDOWN_STATES:
            LOG.info(_LI("Instance already shutdown."),
                     instance=instance)
            return True

So I wonder why the original design let VIR_DOMAIN_SHUTDOWN 
equals VIR_DOMAIN_SHUTOFF? Is there anyone knows?


luogangyi at chinamobile.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170217/51be9ec4/attachment.html>