openstack/manila-specs
Code Issues Proposed changes

Merge "Update Create Share from Snapshot in Another Pool"

Browse Source
This commit is contained in:
Zuul 2020-02-14 18:53:34 +00:00 committed by Gerrit Code Review
commit 822c616f5c
1 changed files with 90 additions and 70 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

160
specs/train/create-share-from-snapshot-in-another-pool.rst → specs/ussuri/create-share-from-snapshot-in-another-pool.rst
View File

@ -53,12 +53,12 @@ option allows different results:
This will certainly not work for any of the drivers in manila. This will certainly not work for any of the drivers in manila.
The main benefit from enabling this option is that the scheduler can select The main benefit from enabling this option is that the scheduler can select
a different compatible back end to place the new share, even when the source's a different compatible back end to place the new share, even when the source
share has space enough to handle it. In order to have it working properly, we share's back end has space enough to handle it. In order to have it working
need to address the following: properly, we need to address the following:
* Guarantee that only compatible back ends will receive requests; * Guarantee that only compatible back ends will receive requests;
* Guarantee that, when more that one compatible back end is available, the * Guarantee that, when more than one compatible back end is available, the
scheduler will choose the best fit; scheduler will choose the best fit;
* No regressions are inserted to the current behavior when the option is * No regressions are inserted to the current behavior when the option is
disabled. disabled.
@ -88,7 +88,7 @@ shares from snapshot:
ends will be weighed based on configured weigher classes. ends will be weighed based on configured weigher classes.
2. **User provides the destination AZ.** The scheduler will filter out all back 2. **User provides the destination AZ.** The scheduler will filter out all back
ends that does not belong to the user's specified AZ and all back ends that ends that do not belong to the user's specified AZ and all back ends that
are not compatible with source share's pool. The list of compatible back are not compatible with source share's pool. The list of compatible back
ends will be weighed based on configured weigher classes. ends will be weighed based on configured weigher classes.
@ -108,7 +108,7 @@ as expected:
1. Change how the API handles the availability zone parameter, which is 1. Change how the API handles the availability zone parameter, which is
currently ignored when creating new shares from snapshots; currently ignored when creating new shares from snapshots;
2. Modify the scheduler's filter ``ShareReplicationFilter``, to identify 2. Create a new scheduler's filter ``CreateFromSnapshotFilter``, to identify
compatible back ends; compatible back ends;
3. Create a new weigher, to improve the scheduler's selection of the best 3. Create a new weigher, to improve the scheduler's selection of the best
@ -118,7 +118,10 @@ destination pool;
snapshot. The driver interface for ``create_share_from_snapshot`` will be snapshot. The driver interface for ``create_share_from_snapshot`` will be
updated to return a model update when an asynchronous operation is needed. updated to return a model update when an asynchronous operation is needed.
5. Provide a proper configuration and guidelines for the feature. 5. Create a new periodic task to track and update the status of shares that
were created from snapshots.
6. Provide a proper configuration and guidelines for the feature.
The required changes are detailed in the following subsections. The required changes are detailed in the following subsections.
@ -129,7 +132,8 @@ snapshot (potentially a bug, as it should return an error stating that a
different AZ should not be specified). With the option different AZ should not be specified). With the option
``use_scheduler_creating_share_from_snapshot`` enabled, the API will need to ``use_scheduler_creating_share_from_snapshot`` enabled, the API will need to
forward the AZ parameter into the request sent to the scheduler, otherwise, forward the AZ parameter into the request sent to the scheduler, otherwise,
the request will fail and the user notified about the reasons of the failure. the request will fail and the user will be notified about the reasons of the
failure.
Scheduler's Improvement Scheduler's Improvement
@ -140,16 +144,16 @@ shares from snapshots in pools or back ends different than the source share's.
This ability will be addressed by existing filters and the use of an already This ability will be addressed by existing filters and the use of an already
implemented property:``replication_domain``. implemented property:``replication_domain``.
The replication feature are tightly related to the ability of creating a share The replication feature is tightly related to the ability of creating a share
in another pools. If two or more back ends are coupled for replication, they in another pool. If two or more back ends are coupled for replication, they
commonly have a fast data between each other, that can be used by some storage commonly have a fast data link between each other, that can be used by some
vendors to move, copy and replicate data among the back ends in the replication storage vendors to move, copy and replicate data among the back ends in the
domain. replication domain.
This spec proposes to modify the behavior of the ``ShareReplicationFilter``, This spec proposes to create a new filter, ``CreateFromSnapshotFilter``,
that uses the property ``replication_domain`` to identify compatible storage to use the property ``replication_domain`` to identify compatible storage
back ends, to also identify pools and back ends capable of creating shares from back ends, i.e., remote pools and back ends capable of creating shares from
snapshots in a efficient way. snapshots in an efficient way.
In this proposal it is considered that back ends that can replicate data In this proposal it is considered that back ends that can replicate data
between each other should also be able to create new shares in an efficient between each other should also be able to create new shares in an efficient
@ -178,7 +182,7 @@ source share's location. If the source and destination hosts are located on:
choice (e.g. 75 points) choice (e.g. 75 points)
3. different back ends with the same AZ: the destination host is a good 3. different back ends with the same AZ: the destination host is a good
choice (e.g. 50 points) choice (e.g. 50 points)
4. different back ends and AZ's: the destination host isn't so good choice 4. different back ends and AZ's: the destination host isn't a good choice
(e.g. 25 points) (e.g. 25 points)
Even so, this strategy still doesn't solve the used space balance use case at Even so, this strategy still doesn't solve the used space balance use case at
@ -201,64 +205,69 @@ working within the same AZ. But at the end, it is up to him/her to decide when
a host should be filtered when creating shares from snapshot. a host should be filtered when creating shares from snapshot.
We can finally combine these approaches presented here and describe our We can finally combine these approaches presented here and describe our
proposed scheduling algorithm: proposed scheduling algorithm improvement:
1. We start by checking the source share's back end capabilities to obtain the 1. The scheduler request will be updated to include source share's host
scope of back end candidates that matches the specified AZ (or the source location needed by the new filter and weigher functions. It will be
share's AZ if unspecified), which can be either: submitted through a list of scheduler filters, including the
``AvailabilityZoneFilter`` which will exclude back ends that don't satisfy
an availability zone restriction, if specified by the user during the share
creation.
a. The same source pool or other pools in the same back end, if the AZ is 2. Alongside the scope of back ends determined by regular filters, we submit
unspecified or if the specified AZ is the same as the source share's them through the ``CreateFromSnapshotFilter`` in order to filter
one. incompatible back ends that don't fulfill at least one of the restrictions:
b. Other back ends and respective pools that match the same string set
in ``replication_domain`` and the specified AZ
(or the same AZ as the source share's if unspecified).
2. From the scope of back ends determined, we submit them through the a. Pools located in the same parent's share back end.
``ShareReplicationFilter`` in order to filter incompatible back ends. After b. Back ends and respective pools that match the same parent's share string
that, we submit them through the regular scheduler filters and weighers. If set in ``replication_domain``.
there are no valid weighed back ends, we error out with the usual
``No valid host found`` message.
3. In case there is more than one candidate and the source pool is among them, 3. After that, we submit them through the regular weighers. If there are no
the new ``HostAffinityWeigher`` can be used, if enabled by the cloud valid weighed back ends, we error out with the usual ``No valid host found``
administrator, to weigh hosts that belong to the same source's pool and/or message.
back end.
4. In case there is more than one candidate, the new ``HostAffinityWeigher``
will be used to weigh hosts based on their proximity to the source's pool.
In this proposal, we assume that drivers that implement replication features In this proposal, we assume that drivers that implement replication features
between compatible back ends shall also be capable of creating new shares from between compatible back ends shall also be capable of creating new shares from
snapshots in another pool or back end different from the source's share. snapshots in another pool or back end different from the source's share.
It is acknowledged that the proposed scheduler behavior for the operation of
creating a new share from a snapshot are a departure from the conventional
scheduler behavior of picking up all configured back ends, filtering and
weighing them.
Share Manager's Updates Share Manager's Updates
----------------------- -----------------------
When creating new shares from snapshots, the driver interface When creating new shares from snapshots, the driver interface
``create_share_from_snapshot`` is called and a string or a list of export ``create_share_from_snapshot`` is called and a string or a list of export
locations is expected as return in a success scenario. However, by enabling the locations is expected as return in a success scenario. However, by enabling the
creation of shares from snapshot in another pool or backend can potentially creation of shares from snapshot in another pool or back end can potentially
increase the time spent by the driver to complete the requested operation, increase the time spent by the driver to complete the requested operation,
considering that it may lead to a data copy between different pools or considering that it may lead to a data copy between different pools or
backends. To avoid performance impacts, the driver interface will be updated to back ends. To avoid performance impacts, the driver interface will be updated to
work in an asynchronous way, by returning a model update, containing the status work in an asynchronous way, by returning a model update, containing the status
of the new share and a list of export locations, if available at share creation of the new share and a list of export locations, if available at share creation
time. The share status returned can be one of the following: time. The driver can return one of the following status to indicate the current
status of the share creation from snapshot:
1. **STATUS_AVAILABLE**: the share was already created on the destination pool 1. **STATUS_AVAILABLE**: the share was already created on the destination pool
and an export location should be available. and an export location should be available.
2. **STATUS_CREATING**: the share is in ``creating`` status and can take some 2. **STATUS_CREATING_FROM_SNAPSHOT**: the share is in ``creating`` status and
time to be available to the user. The manager will need to periodically check can take some time to be available to the user. The share manager will
the status of this share through driver periodic health check. periodically check the status of this share through a new periodic task.
During the periodic driver stats check, the share manager will need to verify For backward compatibility, the vendors can continue to suppress the share
the shares that are in CREATING status and check with the driver if they are status from the returned dictionary, that the share will be considered as
already available. The manager will apply all updates to the database and available to user.
notify the user about it.
A new intermediate status, ``STATUS_CREATING_FROM_SNAPSHOT``, will be added to
assist share manager on filtering shares that are still working on copying data
from a source snapshot. The new status will also be available to end users that
request shares information through the API.
The share manager will have a new periodic task responsible for checking,
using driver's interfaces, if shares that are in
``STATUS_CREATING_FROM_SNAPSHOT`` state have an update in their status. The
manager will apply changes to the database and notify the user about them.
Alternatives Alternatives
------------ ------------
@ -288,7 +297,9 @@ and partially solve the use cases:
Data model impact Data model impact
----------------- -----------------
None. A new ``progress`` field will be added to
``manila.db.sqlalchemy.models.ShareInstance`` indicating the progress of a
share creation.
REST API impact REST API impact
--------------- ---------------
@ -305,13 +316,13 @@ API will return a HTTP 400, Bad Request.
Driver impact Driver impact
------------- -------------
There is no impact for drivers that does not support or want to support the There is no impact for drivers that do not support or want to support the
proposed feature. If the cloud administrator enables the option proposed feature. If the cloud administrator enables the option
``use_scheduler_creating_share_from_snapshot``, the scheduler filter will ``use_scheduler_creating_share_from_snapshot``, the scheduler filter will
guarantee that unsupported back ends will not receive these kind of requests. guarantee that unsupported back ends will not receive these kind of requests.
Vendors that want to support this feature will need to change their drivers Vendors that want to support this feature will need to change their drivers
implementation to properly handle this use case. In order to have it working, implementation to properly handle this use case. In order to have it working,
some pre-requisites are needed: some prerequisites are needed:
1. Use the configuration option ``replication_domain`` and supply it to the 1. Use the configuration option ``replication_domain`` and supply it to the
scheduler together with the storage pool stats. scheduler together with the storage pool stats.
@ -321,6 +332,14 @@ modified to accept a destination pool different from the source share's pool,
and be prepared to return asynchronously if a slow copy operation is needed to and be prepared to return asynchronously if a slow copy operation is needed to
complete the share creation. complete the share creation.
3. Implement a new driver interface, ``get_share_status``, that will be used by
the share manager to periodically check the status of shares created from
snapshots. The driver will be able to provide the current status, the creation
progress information in a percentage value, and the export locations for
shares that become available. If omitted, the progress information will be set
to **0%** for shares in ``STATUS_CREATING_FROM_SNAPSHOT`` and **100%** for
shares in ``STATUS_AVAILABLE``.
Security impact Security impact
--------------- ---------------
@ -341,15 +360,15 @@ Other end user impact
--------------------- ---------------------
No changes to python-manilaclient are necessary. End users will be able to No changes to python-manilaclient are necessary. End users will be able to
create new shares from snapshots in AZs other than the source share's using the create new shares from snapshots in AZs other than the source share's using
current python-manilaclient. the current python-manilaclient.
Performance Impact Performance Impact
------------------ ------------------
The performance impact should be minimal. The share manager will need to check The performance impact should be minimal. The share manager will need to check
in regular intervals whether the driver has finished the share creation for in regular intervals whether the driver has finished the share creation for
shares that remain with status equal to ``STATUS_CREATING``. shares that remain with status equal to ``STATUS_CREATING_FROM_SNAPSHOT``.
Other deployer impact Other deployer impact
--------------------- ---------------------
@ -378,19 +397,20 @@ Work Items
* Implement main patch for manila that includes: * Implement main patch for manila that includes:
* Share API adjustments to pass AZ parameter; * Share API adjustments to pass AZ parameter;
* ShareInstance's new ``progress`` field will be included to provide the
total progress of a share creation.
* Scheduler's new weigher will be added to rate host based on their * Scheduler's new weigher will be added to rate host based on their
proximity to the source's share (only enable when creation from proximity to the source's share;
snapshot); * Scheduler's new filter ``CreateFromSnapshotFilter`` will be added to
* Scheduler's filter ``ShareReplicationFilter`` will be modify to filter filter out incompatible back ends, only when the source share's
out incompatible back ends, only when the source share's ``snapshot_id`` ``snapshot_id`` is provided.
is provided.
* Share manager will introduce new periodic checks for asynchronous * Share manager will introduce new periodic checks for asynchronous
operations, update share's status in the database and notify users about operations, update share's status in the database and notify users about
share's status changes. share's status changes;
* New driver interface to check for updates on shares that were created
from snapshots in an asynchronous mode.
* Testing: * Testing:
* Implement enhancements to the devstack plugin to deploy a first party
driver with multiple AZs;
* Implement functionality in ZFSonLinux driver to validate correct * Implement functionality in ZFSonLinux driver to validate correct
scheduling and share creation from snapshot on different pools. scheduling and share creation from snapshot on different pools.
@ -412,10 +432,9 @@ given AZ different than the existing one. Negative tests will check if user's
requested AZ is available and if the operation is compatible with the requested AZ is available and if the operation is compatible with the
configured option ``use_scheduler_creating_share_from_snapshot``. configured option ``use_scheduler_creating_share_from_snapshot``.
The new test will be run at the gate for the ZFSonLinux driver with Devstack The new tests will run at the gate for the ZFSonLinux driver configured with
plugin enhancements to set up multiple AZs. Vendors that implement support for at least two AZs. Vendors that implement support for the new capabilities in
the new capabilities in their drivers will be encouraged to run the test in their drivers will be encouraged to run the tests in their third party CI.
their third party CI.
Documentation Impact Documentation Impact
@ -440,3 +459,4 @@ References
[1] https://etherpad.openstack.org/p/manila-ptg-planning-denver-2018 [1] https://etherpad.openstack.org/p/manila-ptg-planning-denver-2018
[2] https://etherpad.openstack.org/p/manila-ptg-train [2] https://etherpad.openstack.org/p/manila-ptg-train
[3] https://etherpad.openstack.org/p/shanghai-ptg-manila-virtual