WIP: optimized same store type image migration

Change-Id: I9752348419b99b2cb6f073121c41b73dd3b8cce9

specs/2024.2/approved/glance/optimized-image-migration.rst

@@ -0,0 +1,148 @@
+..
+ This work is licensed under a Creative Commons Attribution 3.0 Unported
+ License.
+
+ http://creativecommons.org/licenses/by/3.0/legalcode
+
+=========================
+Optimized image migration
+=========================
+
+Decommissioning one store in favor of another store is a common use case for
+deployments which could be due to multiple reasons.
+The main challenge in this scenario is migrating all the images from the old
+store to the new store.
+
+Problem description
+===================
+
+Currently there are two ways to migrate images from one store to another:
+1. Download the image from source store, upload the image to the destination
+store and delete the original image from source store
+2. Use the copy-image import plugin to copy the image from source to
+destination store and delete the original image from source store
+
+The second approach is much better and requires less human intervention but
+it still has 2 problems:
+1. Requires operators to issue copy image and wait for it to complete before
+removing the image from source store.
+2. Doesn't provide a way for stores to optimize the operation when the source
+and destination stores are of same type.
+
+
+Proposed change
+===============
+
+We will introduce a new API in glance which will work as follows:
+
+1. Implement a generic migrate mechanism which will use copy-image + delete image
+operations to emulate migration from of image from source store to destination store
+2. Implement an interface for stores to override and provide their optimized approach
+3. Specific store needs to implement their optimized way to migrate the image else
+it will fall back to the generic migration
+
+In case of cinder store, if the image is to be moved from one cinder store to another,
+we can issue a retype operation that is optimized on the backend side which will allow
+the image-volume to be migrated faster as compared to the generic workflow.
+
+Alternatives
+------------
+
+Keep using the current approach of copy-image + delete image operation.
+
+Data model impact
+-----------------
+
+None
+
+REST API impact
+---------------
+
+A new API will be introduced that will perform the migration of image:
+
+/v2/images/<image-id>/migrate
+
+Security impact
+---------------
+
+None
+
+Notifications impact
+--------------------
+
+None
+
+Other end user impact
+---------------------
+
+A new CLI command will be introduced to migrate images from one store to another.
+
+openstack image migrate <image-id> <destination-store>
+
+Note that source store can be fetched from image.
+
+Performance Impact
+------------------
+
+The optimized migration path, if implemented for same store type migration,
+will enhance the performance significantly.
+Even the generic migration path will offer performance benefit as we won't
+have to wait for one operation to finish before executing another one manually.
+
+Other deployer impact
+---------------------
+
+None
+
+Developer impact
+----------------
+
+The following this needs to be implemented:
+
+* A generic interface for glance store drivers
+* A generic implementation of image migration in glance
+* Implementing optimization on a per store basis
+
+
+Implementation
+==============
+
+Assignee(s)
+-----------
+
+Primary assignee:
+  None
+
+Other contributors:
+  None
+
+Work Items
+----------
+
+The following this needs to be implemented:
+
+* A generic interface for glance store drivers
+* A generic implementation of image migration in glance
+* Implementing optimization on a per store basis
+
+Dependencies
+============
+
+* Glance requires the glance store generic interface to be implemented
+
+Testing
+=======
+
+UTs, functional testing, integration testing.
+
+
+Documentation Impact
+====================
+
+Document the new migrate API and the optimization use cases.
+
+
+References
+==========
+
+None