Add CRUD APIs for resource locks with support
for preventing deletion of shares (applies to
soft-deletions and unmanage operations as well).
Change-Id: I146bc09e4e8a39797e22458ff6860346e11e592e
Implements: bp/allow-locking-shares-against-deletion
Signed-off-by: Goutham Pacha Ravi <gouthampravi@gmail.com>
This feature allows admin to set share size limit for a project.
The defaults will either come from the default values
set in the quota configuration option or via manila.conf
if the user has configured default values for quotas there.
The quota_per_share_gigabytes defaults to -1["No Limit"] always
unless changed in manila.conf by admin.
Closes-Bug: #1811943
Change-Id: Ida126c8c419b8bf4d2a194f061a0809d52b47ab8
This patch adds the possibility to create share networks with
multiple subnets in Manila. It also updates the share server api
to receive "share_network_subnet_id" instead of "share_network_id".
Each share network subnet must be associated with only one
availability zone. Each share network must have a single default
share network subnet.
DocImpact
APIImpact
Depends-On: I13bb48e7c03e16c26946ccf9d48e80592391a3d1
Partially-implements: bp share-network-multiple-subnets
Change-Id: Id8814a8b26c9b9dcb1fe71d0d7e9b79e8b8a9210
Closes-Bug: #1588144
Co-Authored-By: lseki <luciomitsuru.seki@fit-tecnologia.org.br>
Co-Authored-By: dviroel <viroel@gmail.com>
This patch adds Manage/Unmanage of share servers in
Manila. It also updates the Manage Share API to accept
a "share_server_id" parameter, and updates Unmanage
of Share and Snapshots API to allow unmanaging of
shares and snapshots in DHSS=True.
Managed share servers are not deleted automatically
by manila, and if a single share is unmanaged in
DHSS=True, the respective share server will not be
deleted automatically as well.
Managing share servers require that the driver
implements 2 functions:
- get_share_server_network_info: obtain IPs from
share server.
- manage_server: perform required operations to
manage and return dict of backend_details.
Unmanaging share servers require that the driver
overrides unmanage_server function.
The IPs obtained from the backend are validated
by the Network plugin, so ports with the exact
IPs must exist in the subnet and admin subnet
associated with the share network specified
when managing the share server (unless
StandaloneNetworkPlugin is used).
It is recommended to rename the backend resource
if possible when managing the share server, to
prevent issues with re-managing a share server
that has already been managed.
This patch bumps the API microversion to 2.49.
APIImpact
DocImpact
Depends-On: I17c74b2aa242918188eeff368232c762a4b31093
Partially-implements: bp manage-unmanage-with-share-servers
Change-Id: I108961e7436ba13550ef2b8f02079c6e599a6166
There is a particular scenario when creating a new Manila share,
whether through creating a new share or managing an existing one, where
if no share type was explicitly specified and no default share type was
configured the error message would not substitute the share type ID into
the exception message. This is because, in this case, there was no share
type ID to substitute into the string.
This patch creates a new exception for explicitly handling the case
where there is no default share type and no share type is explicitly
given. It gives an appropriate error message about there not being a
default share type and that there was no share type explicitly given as
well as what would need to be done to remedy the situation.
Change-Id: I068b55d4b77dc24b53fe93d870bb84e1aef661a5
Closes-Bug: #1700346
Before it was possible to create share group types mapping them to
share types using only share type IDs and when we were providing its
names we were getting DB error and HTTP 500 as a response.
Fix it by properly looking for share type by both its unique values -
ID and name. Also, raise proper 404 error when nothing is found.
Add functional tests covering this case.
Change-Id: I216f935383a87f6d679c431bc46cfa8977a6d8ab
Depends-On: Ic555d241f98d0fa027897c69a7115d1be88f6c96
Closes-Bug: #1659625
This new feature gives the user the ability to allow and
deny access to the snapshots, so that they could be mounted in
read-only mode to retrieve files.
APIImpact
DocImpact
Co-Authored-By: Rodrigo Barbieri <rodrigo.barbieri@fit-tecnologia.org.br>
Co-Authored-By: Alyson Rosa <alyson.rosa@fit-tecnologia.org.br>
Co-Authored-By: Miriam Yumi <miriam.peixoto@fit-tecnologia.org.br>
Partially-implements: blueprint manila-mountable-snapshots
Change-Id: I65f398a05f82eef31ec317d70dfa101483b44b30
When taking a snapshot of a replicated share, users would
expect the snapshot to be available across the replicas.
Currently, Manila assumes that drivers will take snapshots
along with the share data.
Different backends implement replication differently. Many
of them assume that replicas are 'in_sync' with the primary
if they have been synchronized within a particular window
of time (sometimes referred to as 'recovery point objective').
Since snapshots are point in time actions on a share, drivers
must ensure that the replication of a snapshot begins as soon
as it is available on the primary/'active' instance.
To ensure that snapshots are indeed available across replicas:
1) Track snapshots across replicas as different
snapshot instances.
2) Make an 'aggregate_status' property to convey the
availability of a snapshot across all the active/in_sync
replicas of a share.
3) Provide all the information necessary for drivers to:
- Create a snapshot on the primary and send it across
to all replicas
- Delete a snapshot on the primary and ensure that it is
deleted on the replicas as well.
4) Set snapshot instance to 'error' if it was in any transitional
state when its replica was 'promoted' to become an 'active'
instance.
5) Pass down snapshot instances during create, delete and update
replica driver calls.
6) Update replica interfaces to pass in snapshot instance data. Always
include 'available' snapshots in the update_replica call to ensure
that drivers confirm their presence on the replica in order to report
that the replica is 'in_sync'.
Also, grab the share_type afresh from parent share/snapshot
to allow 'replication_key' to be copied to the share model during
share creation.
Rename SnapshotNotFound to SnapshotResourceNotFound to
signify a missing snapshot object on backends.
APIImpact
The 'status' attribute of the snapshot is now the 'aggregate_status'
of the instances of the snapshot. No key changes have been made
in the JSON response. However, API actions will be gated against
'aggregate_status' of the snapshot instances when more than one
instance exists.
Closes-Bug: #1546303
Closes-Bug: #1551064
Change-Id: I63203df00904d209e9e92eda7c79206e5ef8d611
Add APIs to support manage and unmanage share snapshots.
Also add support in the Generic driver.
This only supports for DHSS=False driver mode.
Add provider_location column to the share_snapshots table
to save data used to identify the snapshot on the backend.
Also need to bump microversion.
APIImpact
DocImpact
Change-Id: I87a066173c85d969607d132accd9f0e9bd49c235
Implements: blueprint manage-unmanage-snapshot
This patch provides the scheduler support to filter share
backends matching replication capabilities reported by the
hosts and the replication_type extra_spec provided via the
share_type during share creation.
It also adds wsgi routes, API endpoints and driver entry
routines to support the actions: list, show, create, delete
and promote share replicas. It augments the ShareInstance
DB model with a 'replica_state' attribute and the Share DB
Model with 'replication_type' attribute to support these
workflows.
Replica states are periodically updated from the respective
backends that the replicas are created on.
APIImpact
Impact on existing APIs:
In Microversion 2.11, the /shares APIs return 2 additional
fields during index and show calls for each share: 'has_replicas'
and 'replication_type'. Similarly, the field 'replica_state' is
added to the API response for /share-instances.
Also, deletion of a share that has replicas is forbidden,
returning error code 403.
DocImpact
Co-Authored-By: Alex Meade <mr.alex.meade@gmail.com>
Implements: blueprint manila-share-replication
Change-Id: I10515d55b1291c34777a31d8c6a3a1954f551235
Some upcoming features require more than one export location and
possibility to mark them with specific labels like fast/slow or
rw/ro.
So, implement 'export locations metadata' feature:
- It allows to set any key-value pairs for each export location.
- These key-value pairs can be set only by share manager using
response from various share driver methods.
- Example of update is implemented using Generic driver
"create_instance" method.
- Metadata can be updated for any export location in any place
of share manager where db function "share_export_locations_update"
is called.
- Keys from export location metadata table will be added to 'share' and
'share instances' views as export location attributes.
Also:
- Add new attr 'is_admin_only' for existing export locations model.
If set to True, then only admins will be able to see them. Unless
policy is changed.
- Add APIs for reading export locations by share and share instance IDs.
- Remove 'export_location' and 'export_locations' attrs
from 'share' and 'share instance' views.
- Bump microversion as new APIs implemented.
APIImpact
Implements bp export-location-metadata
Change-Id: I36d1aa8d9302e097ffb08d239cf7a81101d2c1cb
Added ensure_share implementation that checks share
availability and re-exports the given share.
Unit tests are added as well as a new ShareResourceNotFound
Exception (with its own unit test).
Change-Id: Ifbb144fa16df5d0ff3560d1a7476b75e5ccf184a
Closes-Bug: #1510552
At manila.exception:
msg_fmt => message
Reason:
When msg_fmt is passed to parent class, the information is not shown
because parent class expect variable 'message'.
Change-Id: I3e1346e7d6258eac4a5df965e4315090fbfcda0b
Closes-Bug: #1487247
This change adds support for share_type, share_types, and share_type_id
along side the corresponding volume_type, volume_types and
volume_type_id fields in the API. This change was made as share_type and
its references are more intuitive in comparison to volume_type.
Both entries are returned to ensure API compatibility but preference is
given to share_type[s,_id].
The database migration introduced in this change should work on MySQL
and Postgres, but will not work on SQLite. Because there is no point
in supporting SQLite, tests for it are removed.
Implements blueprint: rename-volume-type-to-share-type
Change-Id: Ifa23ee6520b5238c7de3d5bce7b7bbde02a4a61d
Change exception in db method, because previous one had necessary
parameter which is undefined in db function. The undefined parameter
in the previous exception caused a new exception to be thrown.
Change-Id: I52ccb813d33d7c382f9447252fc5a1017ff625ac
Closes-Bug: #1364394
Import the following change from Cinder to fix a problem with translated
exceptions.
Co-Authored-By: git-harry <git-harry@live.co.uk>
Author: git-harry <git-harry@live.co.uk>
Date: Thu Apr 17 10:49:49 2014 +0100
CinderException args to strings when exceptions
CinderException message and kwargs are converted to strings if the
argument is itself an exception.
Exceptions passed as arguments to CinderException happen in many
areas
of the code. This causes an error when oslo.messaging tries to
serialise
the exception.
Change-Id: I1399c939bbca47ab8362ac3bbe0e9a349c6d5572
Closes-Bug: #1301249
Change-Id: If36f1af0b2e9cc7ec263bdacfe5aa4d49c4c9b85
Fix these issues and enable E126 and E127:
E126 continuation line over-indented for hanging indent
E127 continuation line over-indented for visual indent
Also fix a few occurences in the touched files of:
E128 continuation line under-indented for visual indent
H405 multi line docstring summary not separated with an empty line
Partial-Bug: #1333290
Change-Id: If822401fc7e1db49d595a0736a0dff8e00dfd217
Use oslo.db library instead of own implementation.
Oslo.db code contains different utils for work with db api, db session,
migrations, test classes for db testing, tools for automatic retry
db.api query if db connection was lost, etc.
Oslo.db code was tested better as it is currently used in many projects,
there will be no need in testing our own implementation.
In many cases our own implementation of work with db duplicates
oslo.db code.
Remove:
- manila/common/sqlalchemyutils.py;
- manila/db/sqlalchemy/utils.py;
- manila/db/sqlalchemy/session.py;
- manila/db/sqlalchemy/migration.py;
- DBError, wrap_db_error, InvalidUnicodeParameter exceptions;
- db_sync, db_version, db_version_control, _find_migrate_repo
function
and replace it with appropriate oslo.db functions.
Add 'joinedload' statement to db queries if necessary.
Fix unit tests, clean up test_migrations.py
Implements bp oslo.db
Change-Id: I48a4da797594cf020f67f78024bd0f86b5abd5ef
Removed unused exceptions and fixed several inheritance
issues, that causes wrong responce codes.
exceptions MigrationNotFound and MigrationNotFoundByStatus
are left, because manila just doesn't have migrations yet.
Change-Id: Icf39422927fc7754c5c47ab717fad178ed44a0dc
Related-Bug: #1325934
It allows us to use a bunch of skip
decorators, addCleanup method with
2.6 and 2.7 python versions.
Provides more strict usage of setUp
and tearDown methods.
Change-Id: I62144ba43d62e3becb90427d5d6600f97db458df
Goutham Pacha Ravi