Open Stack

Looking at this a bit deeper the comment in _start_buidling() says that its doing this to “Save the host and launched_on fields and log appropriately “.    But as far as I can see those don’t actually get set until the claim is made against the resource tracker a bit later in the process, so this whole update might just be not needed – although I still like the idea of a state to show that the request has been taken off the queue by the compute manager.

From: Day, Phil
Sent: 25 June 2014 10:35
To: OpenStack Development Mailing List
Subject: RE: [openstack-dev] [nova] Why is there a 'None' task_state between 'SCHEDULING' & 'BLOCK_DEVICE_MAPPING'?

Hi WingWJ,

I agree that we shouldn’t have a task state of None while an operation is in progress.  I’m pretty sure back in the day this didn’t use to be the case and task_state stayed as Scheduling until it went to Networking  (now of course networking and BDM happen in parallel, so you have to be very quick to see the Networking state).

Personally I would like to see the extra granularity of knowing that a request has been started on the compute manager (and knowing that the request was started rather than is still sitting on the queue makes the decision to put it into an error state when the manager is re-started more robust).

Maybe a task state of “STARTING_BUILD” for this case ?

BTW I don’t think _start_building() is called anymore now that we’ve switched to conductor calling build_and_run_instance() – but the same task_state issue exist in there well.

From: wu jiang [mailto:wingwj at gmail.com]
Sent: 25 June 2014 08:19
To: OpenStack Development Mailing List
Subject: [openstack-dev] [nova] Why is there a 'None' task_state between 'SCHEDULING' & 'BLOCK_DEVICE_MAPPING'?

Hi all,

Recently, some of my instances were stuck in task_state 'None' during VM creation in my environment.

So I checked & found there's a 'None' task_state between 'SCHEDULING' & 'BLOCK_DEVICE_MAPPING'.

The related codes are implemented like this:

#    def _start_building():
#        self._instance_update(context, instance['uuid'],
#                              vm_state=vm_states.BUILDING,
#                              task_state=None,
#                              expected_task_state=(task_states.SCHEDULING,
#                                                   None))

So if compute node is rebooted after that procession, all building VMs on it will always stay in 'None' task_state. And it's useless and not convenient for locating problems.

Why not a new task_state for this step?


WingWJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140625/05a14848/attachment.html>