Open Stack

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 <philip.day at hp.com> 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:wingwj at gmail.com]
> *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 <philip.day at 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:wingwj at gmail.com <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
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140626/db8e613e/attachment.html>