Added support for display count info in share snapshot
list&detail APIs:
1. /v2/snapshots?with_count=True
2. /v2/snapshots/detail?with_count=True
New microversion added 2.79
Closes-bug: #2024556
Change-Id: I37d8ca9022e2ea2c107c6695e20e951d7950043a
Add support share Recycle Bin, the end user can soft delete
share to Recycle Bin, and can restore the share within 7 days,
otherwise the share will be deleted automatically.
DocImpact
APIImpact
Partially-Implements: blueprint manila-share-support-recycle-bin
Change-Id: Ic838eec5fea890be6513514053329b1d2d86b3ba
share snap list, Fuzzy query by name or description is supported, but
the current implementation is first get all the shares, then In the API
layer, the for loop is used to achieve fuzzy matching, if the num of
shares is big,
It will seriously affect the speed of fuzzy matching.Therefore, we
should let the database do the matching to speed up the query.
Moving the pagination params (limit, offset, sorting) to the database
layer for snapshot list, to optimize query speed.
Closes-Bug:#1881865
Partial-Bug:#1831094
Change-Id: I283e78c9e7c2dd626d94cf6c1b01d4e2f9ae8097
Manila APIs have had the requirement to include
project_id in the URLs since the very beginning.
This comes from an old assumption that our APIs
would be differentiated per-tenant on the cloud,
and we would allow different kinds of API endpoints
(public, admin, internal, etc). While it is possible
to set up different endpoints against the API
service, the same and complete API is exposed at
each of these endpoints.
We don't _need_ the project_id information that
we receive in the URL for any of our APIs to
function. We rather authorize tenants by gathering
information from the Identity service (Keystone)
and wrapping that into a RequestContext object
that we then rely on to ensure namespace isolation.
Removing the requirement for "project_id" simplifies
our API endpoint structure in the service catalog
as well as provides a way for system scoped users
to interact with manila without having to declare
their project.
In order to make project_id optional in urls, the
possible values of project_id have to be constrained.
This change introduces a new configuration option
so deployers may control that. This configuration
option defaults to accepting UUIDs with and without
dashes.
Since manila can be used in standalone deployments
without the need for Keystone, this change introduces
a noauth middleware that can work without project_id
in the URL paths.
The API version has been incremented to signal this
change to end users. When 2.60 is available, deployments
may drop "project_id" in the service catalog endpoint
for Manila and end users applications can stop needing
it as well (if they don't already rely on the service
catalog for this data).
APIImpact
Implements: bp remove-project-id-from-urls
Change-Id: I5127e150e8a71e621890f30dba6720b3932cf583
Signed-off-by: Goutham Pacha Ravi <gouthampravi@gmail.com>
When manila API is served behind a proxy, the
"script_name" in the request can have the proxy
component in it. So, this patch fixes the version
selection logic by looking for the version in the
script name string instead of equivalence.
In addition, this patch adds some missing unit
tests and fixes tests that invoke a mocked
wsgi app for testing request context.
Change-Id: I0363d7174f3d7ddefa8ced59b182faed665e9c36
Partial-Bug: #1815038
Closes-Bug: #1818081
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
rpc_backend was an old oslo_messaging option
that was deprecated in stable/newton and removed
in master/stein [2], so stop using it in our
unit tests.
The coverage job in manila was always non-voting,
however, a773e31420
added a common coverage job-template from the
openstack-zuul-jobs repository. This change
inadvertently made the non-voting cover job a
voting job.
Our coverage script isn't perfect, it is known
to fail erroneously on non-code changes, and
some genuine failures are just an indication
to developers and reviewers to make the best
effort to adhere to the script's strict
checks [3].
These changes are unrelated, but must be fixed
together to pass the gate, since we have a
chicken-and-egg problem with both failures
preventing separate fixes from merging
separately.
[1] https://review.openstack.org/#/c/317285/
[2] https://review.openstack.org/#/c/580910/
[3] http://git.openstack.org/cgit/openstack/manila/tree/tools/cover.sh
Closes-Bug: #1796759
Related-Bug: #1797512
Change-Id: Ie349c3866d51ea4e706369ad67bc1155f62f2651
Fix pylint E103 warning raised by usage of
self.__class__ to refer to the derived class
in super() methods.
self.__class__ is a reasonable first argument
to super() in any method of a class, as long
as the method is not going to be invoked in
derived classes.
Python3 removes this ambiguity by not requiring
arguments for the super() method.
[1] https://docs.pylint.org/en/1.6.0/features.html#id33
Change-Id: I6071b6cfd8cff2be3853d739f71b94da990cda97
Please read spec for design detail [1].
Add support to validate IPv6 based addresses
in allow access API when access type is IP.
[1] f7202a6cfe32a057f752a4e393f848f8a0211c36
APIImpact
DocImpact
Change-Id: Ica242007e77a7e21b2151e5fc32401b501d961b2
Partial-Implements: blueprint support-ipv6-access
Add like filter support in ``shares``, ``snapshots``,
``share-networks``, ``share-groups`` list APIs.
APIImpact
Implements BP like-filter
Change-Id: I5fdf6d89d0b6c7fa182ddfaac60979bc6c0fc2a5
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
In a cloud with multi-tenancy, administrators
would like to see the project_id of the tenant
while listing snapshots of all tenants.
Likewise, we also should expose the user_id field
as it would help in cases where tenants have multiple
users.
DocImpact
User and administrator references need to capture
this information.
APIImpact
API changes are micro-versioned.
Change-Id: I3ad655dc9ab7440f205b0e153fccaa99abb79bbd
Closes-Bug: #1587161
Managing a share with a share type that has replication_type
extra_spec must be allowed. Drivers are expected to fail
this operation if the share was part of a replication relationship
that Manila does not know about.
Unmanaging a share with replicas must not be permitted
until all replicas are removed.
Managing and unmanaging of snapshots must not
be permitted for a share that has replicas.
Modify the NetApp driver for manage_existing to check
for existing replicas.
Also fix issue with manage retry where the share
data was being altered inappropriately by a DB API.
Closes-Bug: #1561641
Closes-Bug: #1565903
Co-Authored-By: Goutham Pacha Ravi <gouthamr@netapp.com>
Change-Id: I82f1fef1e30114e017efd00fa7da70aceecab94c
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
Goutham Pacha Ravi