Thanks WingWJ. It would also be great to track this in a bug. Vish
On Jun 26, 2014, at 5:30 AM, wu jiang <[email protected]> wrote: > Hi Phil, > > Ok, I'll submit a patch to add a new task_state(like 'STARTING_BUILD') in > these two days. > And related modifications will be definitely added in the Doc. > > Thanks for your help. :) > > WingWJ > > > On Thu, Jun 26, 2014 at 6:42 PM, Day, Phil <[email protected]> wrote: > Why do others think – do we want a spec to add an additional task_state value > that will be set in a well defined place. Kind of feels overkill for me in > terms of the review effort that would take compared to just reviewing the > code - its not as there are going to be lots of alternatives to consider here. > > > > From: wu jiang [mailto:[email protected]] > Sent: 26 June 2014 09:19 > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [nova] Why is there a 'None' task_state between > 'SCHEDULING' & 'BLOCK_DEVICE_MAPPING'? > > > > 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 <[email protected]> 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:[email protected]] > > 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
