Reboot operation fails if force_disk_config is switched to True after spawning

[Mathew Odden]

A hard reboot operation fails if force_disk_config is switch to True after spawning the instance without a config drive.

This was found using the libvirt driver, I'm not sure if it affects other drivers.

Steps to recreate would be:
1. Spawn an instance without a config drive
2. Change force_config_drive to True in your nova.conf
3. Restart nova-compute
4. Attempt to reboot the instance

An error similar to the following message will be displayed in the nova compute logs:

2013-10-18 15:26:42.268 ERROR nova.compute.manager [req-ae365347-f863-4bf3-9fc1-f2e13a8aeb6a 8d656ddf92e24f88a91a51a2c4dd5252 951ae3eceeff40db97fa6aca540a6738] [instance: 2e685095-9b7b-4711-aba6-2a7794fdafd5] Cannot reboot instance: [Errno 2] No such file or directory: '/var/lib/nova/instances/2e685095-9b7b-4711-aba6-2a7794fdafd5/disk.config'

[Michael Still (mikal)]

This is a special case of bug 1303714 I think. The only time we should care about the value of force_config_drive is on first boot of the instance. A hard reboot should just give you what you already had, even if the value of this flag has changed in the mean time.

[Sean Dague (sdague)]

No indication that this is still in progress.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Sean Dague (<email address hidden>) on branch: master
Review: https://review.openstack.org/92899
Reason: This review is > 4 weeks without comment, and failed Jenkins the last time it was checked. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results.

[Davanum Srinivas (DIMS) (dims-v)]

Removing "In Progress" status and assignee as change is abandoned.

[Matt Riedemann (mriedem)]

Stephen, are you working on this? It's been in progress for a few months now and doesn't have a patch up so I'm going to remove the assignee in case someone else wants to work on this.

[Markus Zoeller (markus_z) (mzoeller)]

This is an automated cleanup. This bug report has been closed because it
is older than 18 months and there is no open code change to fix this.
After this time it is unlikely that the circumstances which lead to
the observed issue can be reproduced.

If you can reproduce the bug, please:
* reopen the bug report (set to status "New")
* AND add the detailed steps to reproduce the issue (if applicable)
* AND leave a comment "CONFIRMED FOR: <RELEASE_NAME>"
  Only still supported release names are valid (LIBERTY, MITAKA, OCATA, NEWTON).
  Valid example: CONFIRMED FOR: LIBERTY

[OpenStack Infra (hudson-openstack)]

Change abandoned by Matt Riedemann (<email address hidden>) on branch: master
Review: https://review.openstack.org/92899

[melanie witt (melwitt)]

This bug has been open for a long time and I haven't yet seen consensus on whether or not it's a bug. That is, some have stated that the force_config_drive setting is only to be considered when an instance is first booted and subsequent reboots will refer to the existing config drive, if one exists. So at best I think this is Medium importance unless something changes.

[Sean Dague (sdague)]

There are no currently open reviews on this bug, changing
the status back to the previous state and unassigning. If
there are active reviews related to this bug, please include
links in comments.

[Sean Dague (sdague)]

Found open reviews for this bug in gerrit, setting to In Progress.

review: https://review.openstack.org/364814 in branch: master

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/485930

[OpenStack Infra (hudson-openstack)]

Change abandoned by Sean Dague (<email address hidden>) on branch: master
Review: https://review.openstack.org/364814
Reason: This review is > 4 weeks without comment, and is not mergable in it's current state. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results.

[Matthew Booth (mbooth-9)]

I believe this is a bug. We have the context of how the instance was created in instance.config_drive. I believe https://review.openstack.org/485930 is the correct fix.