CellsV2 - Keypairs API DB migrations¶
Keypair database tables that currently reside in the nova database must be migrated to the API database. This is because Keypairs are exposed in the API and must span across cells.
key_pairs table is currently located in the cell database. As Keypairs
is a concept that is exposed in the API it must be moved to the API database.
As a developer, I need to ensure all data that applies across multiple cell partitions is stored in the global API database.
key_pairs database model will be created in the API database:
class KeyPair(API_BASE): """Represents a public key pair for ssh / WinRM.""" __tablename__ = 'key_pairs' __table_args__ = ( schema.UniqueConstraint("user_id", "name", name="uniq_key_pairs0user_id0name"), ) id = Column(Integer, primary_key=True, nullable=False) name = Column(String(255), nullable=False) user_id = Column(String(255)) fingerprint = Column(String(255)) public_key = Column(MediumText()) type = Column(Enum('ssh', 'x509', name='keypair_types'), nullable=False, server_default='ssh')
KeyPair object will be modified to use the new API database model.
Methods related to keypairs that are currently in the database API will be
moved to the
Migration to the API database will follow the existing pattern established by the merged flavor migration series.
The metadata service currently reads the
key_pairs table directly. We
would like to prevent this once the table has been moved to the API database.
Instead the entire
KeyPair object will be serialized in-to the
instance_extra table. This will require an additional column:
keypair = orm.deferred(Column(Text))
Database migrations will be performed to include this new column on instance extra. It will be populated on creation of the instance object if a key pair is to be inserted. It will be read out from the metadata service.
I do not believe that there is an alternative to putting the Keypairs table
in the API db. Alternatives for passing the keypair information to the
metadata service could be adding a field to the instance object to store
key_type. Fields are already present for
This alternative is not preferred as it involves a modification of the
instance object and continues an existing bad practice of duplicating
Data model impact¶
There will be a large data model impact as many new tables will be created in the API database. The data models have been detailed in the above sections.
REST API impact¶
Other end user impact¶
Other deployer impact¶
Deployers must be aware that Keypairs data is being migrated on upgrade, but this should take place during their normal upgrade operations.
- Primary assignee:
- Other contributors:
Create new database table and database migration for
KeyPairobject to use the new models.
Create migration methods for moving data to the API database.
Modify nova-compute service to use keypair information from instance-extra.
Add required unit tests for database access functions to the API db.
Add functional testing for migration of keypair data.
Add new unit tests for access to keypair data in metadata service.
None past other documentation for CellsV2. In CellsV2 documentation there should be a list of migrated tables.