RunInstances uses same ID if previous request failed
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Compute (nova) |
Fix Released
|
Medium
|
Ryan Lucio |
Bug Description
Ubuntu 10.10-64
% euca-run-instances ami-tiny --kernel aki-lucid --ramdisk ari-lucid -k nova_key
if this fails due to networking problems or insufficient disk space (the two conditions I hit) I cannot re-run the command due to a duplicate instance-id database error (mysql). The nova db must be dropped and recreated to get past this.
Doing euca-terminate-
% euca-run-instances ami-tiny --kernel aki-lucid --ramdisk ari-lucid -k nova_key
IntegrityError: (IntegrityError) (1062, "Duplicate entry '2147483647' for key 'internal_id'") 'INSERT INTO instances (created_at, updated_at, deleted_at, deleted, internal_id, admin_pass, user_id, project_id, image_id, kernel_id, ramdisk_id, server_name, launch_index, key_name, key_data, state, state_description, memory_mb, vcpus, local_gb, hostname, host, instance_type, user_data, reservation_id, mac_address, scheduled_at, launched_at, terminated_at, display_name, display_
PS> in some situations ./instances/
Related branches
- David Pravec (community): Approve
- Eric Day (community): Approve
- Michael Gundlach (community): Approve
-
Diff: 25 lines (+2/-2)2 files modifiednova/db/sqlalchemy/api.py (+1/-1)
nova/image/local.py (+1/-1)
Changed in nova: | |
assignee: | nobody → Sandy Walsh (sandy-walsh) |
status: | New → In Progress |
Changed in nova: | |
status: | In Progress → Fix Committed |
Changed in nova: | |
milestone: | none → 2011.1 |
status: | Fix Committed → Fix Released |
I'm completely baffled why would it try to create another instance with the same instance_id. Those are supposed to be unique (picked at random, and checked for uniqueness).
Anyways, we do need a better way to handle failed RunInstances calls. The end users will expect their virtual machines to eventually start, so just nuking the entry from the DB seems rude.