From 6e3dd3c74d0316edc349d4349cb53d3d574aa002 Mon Sep 17 00:00:00 2001 From: Mark Doffman Date: Wed, 4 May 2016 11:08:32 -0500 Subject: [PATCH] Migrate keypair table to the API DB blueprint cells-keypairs-api-db Change-Id: I07318be02f23cf674eeed298e9e546310f4ebe04 --- .../newton/approved/cells-keypairs-api-db.rst | 177 ++++++++++++++++++ 1 file changed, 177 insertions(+) create mode 100644 specs/newton/approved/cells-keypairs-api-db.rst diff --git a/specs/newton/approved/cells-keypairs-api-db.rst b/specs/newton/approved/cells-keypairs-api-db.rst new file mode 100644 index 000000000..864390dad --- /dev/null +++ b/specs/newton/approved/cells-keypairs-api-db.rst @@ -0,0 +1,177 @@ +.. + This work is licensed under a Creative Commons Attribution 3.0 Unported + License. + A + http://creativecommons.org/licenses/by/3.0/legalcode + +==================================== +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. [1]_ + +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 +======= + +.. list-table:: Revisions + :header-rows: 1 + + * - Release Name + - Description + * - Newton + - Introduced