Migrate will change instance_type_id of instance
Bug #809570 reported by
Johannes Erdfelt
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| OpenStack Compute (nova) |
Fix Released
|
Medium
|
Johannes Erdfelt | ||
Bug Description
When migrating an instance to another host, the instance_type_id of the instance changes.
This is because instance_type.id is used in place of flavorid when calling prep_resize(). As a result, the instance_type loaded in prep_resize() is (usually, depending on database) different than the instance_type in resize().
Related branches
lp:~johannes.erdfelt/nova/lp809570
- Brian Lamar (community): Needs Information
- William Wolf (community): Approve
- Rick Harris (community): Approve
- Devin Carlen (community): Approve
-
Diff: 200 lines (+91/-16)6 files modifiednova/api/openstack/create_instance_helper.py (+1/-1)
nova/compute/api.py (+1/-1)
nova/compute/manager.py (+11/-10)
nova/db/sqlalchemy/migrate_repo/versions/036_change_flavor_id_in_migrations.py (+72/-0)
nova/db/sqlalchemy/models.py (+3/-3)
nova/tests/test_compute.py (+3/-1)
Revision history for this message
| Johannes Erdfelt (johannes.erdfelt) wrote | #1 |
Revision history for this message
| Johannes Erdfelt (johannes.erdfelt) wrote | #2 |
Revision history for this message
| Matt Dietz (cerberus) wrote | #3 |
Revision history for this message
| Johannes Erdfelt (johannes.erdfelt) wrote | #4 |
| Changed in nova: | |
| importance: | Undecided → Medium |
| status: | New → Confirmed |
| Changed in nova: | |
| assignee: | nobody → Johannes Erdfelt (johannes.erdfelt) |
| Changed in nova: | |
| status: | Confirmed → In Progress |
| Changed in nova: | |
| status: | In Progress → Fix Committed |
| Changed in nova: | |
| milestone: | none → diablo-4 |
| Changed in nova: | |
| milestone: | diablo-4 → 2011.3 |
| status: | Fix Committed → Fix Released |
To post a comment you must log in.
It's not exactly obvious why there are two different unique ids for an instance_type, but it's probably related to why the code is confused on which one to use.
Ideally, removing one and using one unique id would be the best solution.
Alternatively, changing the code to use either id or flavor_id consistently internally (keeping the API unchanged for compatibility reasons) to avoid this kind of problem in the future.