Re: [openstack-dev] [nova] Why is there a 'None' task_state between 'SCHEDULING' & 'BLOCK_DEVICE_MAPPING'?

2014-06-26 Thread Vishvananda Ishaya
Thanks WingWJ. It would also be great to track this in a bug.

Vish

On Jun 26, 2014, at 5:30 AM, wu jiang  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  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:win...@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  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]
> 
> 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
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova] Why is there a 'None' task_state between 'SCHEDULING' & 'BLOCK_DEVICE_MAPPING'?

2014-06-26 Thread Sandy Walsh
Nice ... that's always bugged me.


From: wu jiang [win...@gmail.com]
Sent: Thursday, June 26, 2014 9:30 AM
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,

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 
mailto:philip@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:win...@gmail.com<mailto:win...@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 
mailto: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]
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<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto: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


Re: [openstack-dev] [nova] Why is there a 'None' task_state between 'SCHEDULING' & 'BLOCK_DEVICE_MAPPING'?

2014-06-26 Thread wu jiang
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  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:win...@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  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 ]
>
> *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
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova] Why is there a 'None' task_state between 'SCHEDULING' & 'BLOCK_DEVICE_MAPPING'?

2014-06-26 Thread Day, Phil
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:win...@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 
mailto: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]
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<mailto: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


Re: [openstack-dev] [nova] Why is there a 'None' task_state between 'SCHEDULING' & 'BLOCK_DEVICE_MAPPING'?

2014-06-26 Thread wu jiang
 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  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 ]
> *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


Re: [openstack-dev] [nova] Why is there a 'None' task_state between 'SCHEDULING' & 'BLOCK_DEVICE_MAPPING'?

2014-06-25 Thread Day, Phil
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]
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


Re: [openstack-dev] [nova] Why is there a 'None' task_state between 'SCHEDULING' & 'BLOCK_DEVICE_MAPPING'?

2014-06-25 Thread Day, Phil
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]
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] [nova] Why is there a 'None' task_state between 'SCHEDULING' & 'BLOCK_DEVICE_MAPPING'?

2014-06-25 Thread wu jiang
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