Hi Phil, thanks for your reply. So should I need to submit a patch/spec to add it now?
On Wed, Jun 25, 2014 at 5:53 PM, Day, Phil <philip....@hp.com> wrote: > 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:win...@gmail.com <win...@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 > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
