OpenStack Compute (nova)

Not defined keypairs in instance_extra cellsV1 DBs

Bug #1761197 reported by Belmiro Moreira
20
This bug affects 4 people
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Confirmed
High
Unassigned
Ocata
In Progress
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.

Tags: cells db upgrade
Surya Seetharaman (tssurya)
Changed in nova:
assignee: nobody → Surya Seetharaman (tssurya)
Matt Riedemann (mriedem)
tags: added: cells db upgrade
Revision history for this message
Belmiro Moreira (moreira-belmiro-email-lists) wrote :

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.

Revision history for this message
melanie witt (melwitt) wrote :

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
Surya Seetharaman (tssurya)
Changed in nova:
assignee: Surya Seetharaman (tssurya) → nobody
Revision history for this message
Sam Morrison (sorrison) wrote :

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?

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to nova (stable/ocata)

Fix proposed to branch: stable/ocata
Review: https://review.opendev.org/657995

Revision history for this message
Surya Seetharaman (tssurya) wrote :

@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.

Revision history for this message
Sam Morrison (sorrison) wrote :

Cool thanks, ended up doing it with 2 things.

1. Save keypairs in compute cell DB with https://github.com/NeCTAR-RC/nova/commit/962b7ff90c8e03d1f7e5f1c30820884d63d6be91

And reinstate the old migration to run it after 1 was deployed https://github.com/NeCTAR-RC/nova/commit/6f4f8f3b5dd9a484a904800bf0a3786f494e6803

Revision history for this message
Surya Seetharaman (tssurya) wrote :

@sorrison: nice!

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on nova (stable/ocata)

Change abandoned by Surya Seetharaman (<email address hidden>) on branch: stable/ocata
Review: https://review.opendev.org/657995
Reason: purpose served.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.