DB Migration Tool

https://blueprints.launchpad.net/tacker/+spec/db-migration-tool

This specification describes a tool to perform DB migration from v1 API to v2 API.

Problem description

Tacker supports multi-version API: v1 API based on SOL 003 v2.6.1 [1] and v2 API based on v3.3.1 [2]. Since v2 API doesn’t have backward compatibility for v1 API, the v1 API users who want to shift from v1 API to v2 API have to terminate their VNF once and re-instantiate them with v2 API. However, this will incur a service outage and thus not realistic. Moreover, some VNFs run for more than 5 years, which consequently means that Tacker cannot deprecate an old API version for more than 5 years. This can be a barrier to the future update roadmap of Tacker when it plans to implement a new ETSI SOL release, e.g., Rel. 4. This is simply because, without the deprecation of an old API, the maintenance cost increases as the supported versions increase. Therefore, a means of migrating from v1 API to v2 API without service outage of the VNF is necessary. This specification proposes a DB migration tool for API version update.

Proposed change

We would implement a DB migration tool by adding DB migration functionality to the tacker-db-manage command. Details are described below.

1) Target tables of migration:

Target tables to be migrated

  • VnfInstanceV2

  • VnfLcmOpOccV2

Source tables to be migrated

  • vnf

  • vnf_attribute

  • vnf_instances

  • vnf_instantiated_info

  • vnf_lcm_op_occs

2) Target VNFs:

One of the following can be selected when executing the command.

  • The VNF that is specified by VNFID

  • All VNFs that their records in the vnf_instances table for which the “deleted” field is not 1.

3) Tool execution method:

DB migration is executed by the following command.

$ tacker-db-manage migrate-to-v2 { --all | [ --mark-delete --api-ver { v1 | v2 } ] --vnf-id <vnf-id> } [--keep-orig]

The options are defined as follows:

  • --all: Migrate all VNFs on vnf_instances that “deleted” field is not 1

  • --vnf-id <vnf-id>: The specific VNF will be migrated

  • --keep-orig: Keep v1 records without erasing them (Erasing them is default)

--keep-orig option can be specfied to keep the pre-migration records, oppositely, the --mark-delete --api-ver { v1 | v2 } --vnf-id <vnf-id> option can be used to complete or rollback the migration:

  • --mark-delete --api-ver v1 --vnf-id <vnf-id>: To complete the migration and erase the records before migration. It updates the value of the v1 records’ “deleted” field to 1 with specific VNF and complete DB migration

  • --mark-delete --api-ver v2 --vnf-id <vnf-id>: To rollback the migration and erase the records after the migration. It updates the value of the v2 records’ “deleted” field to 1 with specific VNF and rollback DB migration

Then records can be deleted completely by executing the tacker-db-manage command with subcommand of purge_deleted.

4) Sequence of tool execution:

When the command is

$ tacker-db-manage migrate-to-v2 --all [ --keep-orig ]

When the command is

$ tacker-db-manage migrate-to-v2 --vnf-id <vnf-id> [ --keep-orig ]

When the command is

$ tacker-db-manage migrate-to-v2 --mark-delete --api-ver v1 --vnf-id <vnf-id>

When the command is

$ tacker-db-manage migrate-to-v2 --mark-delete --api-ver v2 --vnf-id <vnf-id>

Data model impact

None

REST API impact

None

Security impact

None

Notifications impact

None

Other end user impact

None

Performance Impact

None

Other deployer impact

None

Developer impact

None

Implementation

Assignee(s)

Primary assignee:

Masaki Oyama <ma-ooyama@kddi.com>

Other contributors:

Kinjou Yukihiro <yu-kinjou@kddi.com>

Xu Hongjin <ho-xu@kddi.com>

Work Items

  • Implement migration function to tacker-db-manage command

  • Add unit test

  • Add functional test

  • Add user document

Dependencies

None

Testing

Unit test and functional test will be added.

Documentation Impact

Documentation about tool usage will be added.

References