Missing exception handling mechanism in 'schedule_and_build_instances' for DBError at line 1180 of nova/conductor/manager.py
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Compute (nova) |
Opinion
|
Low
|
Unassigned |
Bug Description
Description
==============
If an error occurs during instance creation, the user won't be able to know what exactly happened with the VM that remains always building. As usual, the workflow of creating a VM was interrupted by an exception in the method schedule_
Steps to reproduce
=======
1) Create a VM;
2) Inject an out-of-range value in "schedule_
3) An exception will be thrown, but seems there no exist an appropriate action when this DBError happens.
Expected result
==================
The VM is put in 'error' state
Actual result
================
The VM is in 'build' state indeterminately, and the user never will know (without searching in the logs) what happened with the VM.
Environment
==============
Devstack/
Logs & Configs
=================
Logs attached.
description: | updated |
summary: |
Missing exception handling mechanism in 'schedule_and_build_instances' - for DBError at line 1180 + for DBError at line 1180 of nova/conductor/manager.py |
tags: |
added: fault-injection removed: fault |
Changed in nova: | |
status: | Triaged → Opinion |
Is this just an example of how you're recreating the fault?
""" and_build_ instances. args.build_ requests- >'nova_ object. data'.instance. 'nova_object. data'.instance_ type_id" , this will be enough to cause a DBError. For instance, it can be used the 1E+22 value.
Inject an out-of-range value in "schedule_
"""
Because unless I'm missing something, that's not a real fault that can be injected externally from a user because the instance_type_id comes from the flavors.id which isn't going to be 1E+22.