Not defined keypairs in instance_extra cellsV1 DBs
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| OpenStack Compute (nova) |
High
|
Unassigned | ||
| Ocata |
High
|
Surya Seetharaman |
Bug Description
In newton there was the data migration to fill the "keypair" in instance_extra table.
The migration checks if an instance has a keypair and then adds the keypair entry in the instance_extra table. This works if the keypair still exists in the keypair table.
However, when running with cellsV1 the keypairs only exist in top DB and the migration only works in the instance_extra table of that DB.
This means that in all cells DBs the instance_extra has the keypair not defined.
This is important when migrating to cellsV2 because we will rely in the cells DBs.
We should have a migration that gets the keypairs from nova_api DB to fill the keypair in instance_extra of the different cells DBs.
Changed in nova: | |
assignee: | nobody → Surya Seetharaman (tssurya) |
tags: | added: cells db upgrade |
melanie witt (melwitt) wrote : | #2 |
I think some of this is expected with the syncing up-down of instance data from parent cell to child cells and vice versa. There's some incompleteness there as Surya explained that some instance_extra fields are populated in the child cell DBs and some aren't.
Besides all that, we do need to fix up the migration path for operators moving from cells v1 -> cells v2 to properly populate instances' instance_extra data in cells v2 cell databases.
Changed in nova: | |
importance: | Undecided → High |
status: | New → Confirmed |
Changed in nova: | |
assignee: | Surya Seetharaman (tssurya) → nobody |
Sam Morrison (sorrison) wrote : | #3 |
Was there any work around for this?
We are just planning cellsv1->v2 migration and we are hitting this. Thinking of writing some code but wondering if you already have something CERN?
Fix proposed to branch: stable/ocata
Review: https:/
Surya Seetharaman (tssurya) wrote : | #5 |
@sorrison: We basically did what's in the patch, a temp migration tool to get us past that :). Since it was a migration, wasn't sure if it would get merged upstream, so didn't propose it. However you could use it downstream and if you have any questions feel free to ask.
Sam Morrison (sorrison) wrote : | #6 |
Cool thanks, ended up doing it with 2 things.
1. Save keypairs in compute cell DB with https:/
And reinstate the old migration to run it after 1 was deployed https:/
Surya Seetharaman (tssurya) wrote : | #7 |
@sorrison: nice!
Change abandoned by Surya Seetharaman (<email address hidden>) on branch: stable/ocata
Review: https:/
Reason: purpose served.
Also, new instances don't have the keypair (NULL) defined in instance_extra in child cells DBs when running cellsV1. This is happening in Ocata.