search

termie / nova-migration-demo

Nova is a cloud computing fabric controller (the main part of an IaaS system). It is written in Python.
http://openstack.org/projects/compute/
Apache License 2.0
2 stars 0 forks source link

OSAPI: A server with DB state of 'shutdown' shows as 'ACTIVE'. #346

Open termie opened 13 years ago

termie commented 13 years ago

Nova trunk 2011.2~gamma2~ (981):

Using the OSAPI a server with a DB state of 'shutdown' shows up as 'ACTIVE' in the API.

mysql> select id, state, state_description from instances; +----+-------+-------------------+ | id | state | state_description | +----+-------+-------------------+ | 1 | 5 | shutdown | +----+-------+-------------------+

root@nova1:~# nova list +----+------+--------+-----------+------------+ | ID | Name | Status | Public IP | Private IP | +----+------+--------+-----------+------------+ | 1 | Yo Dawg | ACTIVE | | 172.19.1.2 | +----+------+--------+-----------+------------+

root@nova1:~# euca-describe-instances RESERVATION r-lo6v517h admin default INSTANCE i-00000001 ami-00000003 172.19.1.2 172.19.1.2 shutdown None (admin, xen-compute) 0 m1.tiny 2011-04-12T15:20:03Z nova

Imported from Launchpad using lp2gh.

termie commented 13 years ago

(by pvo) This has always been a difference in how the actual state of the vm reflected the difference in what is essentially a billing status. The vm is technically active and could be restarted as it is available for customer interaction.

If the status of 'shutdown' or 'rebooting' or any other possible action on a vm is to be reflected in the state should it be another field in the api? The vm could be in ACTIVE status and shutdown. That seems reasonable.

termie commented 13 years ago

(by dan-prince) Sure. The issue I have here is where a catastrophic failure of happened and the node still shows up as being 'Active'.

In my case:

-No VM was created -I have a stack trace in nova-compute explaining why -The openstack API shows a status of 'ACTIVE'.

In this case I would actually expect to see a state of 'ERROR' in the status log but I don't. Looking at the code there are a couple things going on here that seem problematic. On a catestrophic failure we seem to set the state to 'SHUTDOWN' instead of 'ERROR'. Additionally even if we did set the state to 'ERROR' in the virt layer there is a function in the compute manager called _poll_instance_states which will change the DB status of 'ERROR' to 'SHUTOFF' if the instance doesn't match what is in the DB. All of this leaves you with a node which marked as 'ACTIVE' in the OS API which implies the node is in a usable state.

termie commented 13 years ago

(by alex-meade) I'm changing it to more accurately represent the instances power state for the time being. This is definitely something that needs to be determined in the future. I don't necessary think the user should be bombarded with a bunch of power states but I do think what it says needs to be meaningful. Or like Paul said, lets show both the billing status and power state.

termie commented 13 years ago

(by jaypipes) Hi, what's the reason this is in In Progress? AFAIK, the fix was merged, no?