4.5 KiB
CellsV2 - Keypairs API DB migrations
https://blueprints.launchpad.net/nova/+spec/cells-keypairs-api-db
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.
Problem description
The 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.
Use Cases
As a developer, I need to ensure all data that applies across multiple cell partitions is stored in the global API database.
Proposed change
A new 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')
The 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 KeyPair
object.
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.
Alternatives
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
key_name
and key_data
. This alternative is not
preferred as it involves a modification of the instance object and
continues an existing bad practice of duplicating object fields.
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
None
Security impact
None
Notifications impact
None
Other end user impact
None
Performance Impact
None
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.
Developer impact
None
Implementation
Assignee(s)
- Primary assignee:
- Other contributors:
-
None
Work Items
- Create new database table and database migration for
keypairs
. - Update the
KeyPair
object 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.
Dependencies
None
Testing
- 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.
Documentation Impact
None past other documentation for CellsV2. In CellsV2 documentation there should be a list of migrated tables.
References
None
History
Release Name | Description |
---|---|
Newton | Introduced |