Export locations are usually too difficult to memo
rize.Currently, there is no way to determine the
export location before the share is created, so
users wait until the share creation request gets
completed, and then they check the export
locations to mount the share. The generated
export locations are often not human readable
and it is hard to memorize and control them.
Implements: bp/human-readable-export-locations
Change-Id: I72ac7e24ddd4330d76cafd5e7f78bac2b0174883
This change modifies the status and error handling
logic of the /shares API when it fails to handle
the specified share_type in the request. The updated
logic ensures that appropriate responses are
generated to handle this scenario effectively.
Closes-Bug: #1944478
Change-Id: I8d4b30daae2fe8c88c30d93d402bf2e5a558f804
Access rules rules allow API will now take three additional
parameters:
- lock_visibility: when True, only services, administrators and
the same user will be able to see the content of ``access_to`` and
access_key.
- lock_deletion: when True, the access rule will be locked for
deletion. Only services, administrators or the user that placed
the lock will be able to drop the access rule.
- lock_reason: a reason for the lock. This parameter should only
be provided in the presence of at least one of the former
parameters.
In order to delete an access rule that is currently locked, the
requester will need to specify ``unrestrict=True`` in the request.
In case a service placed the restrictions, only the own service or
the system administrator will be able to release it.
This change also implements filters to the access list API. It is
now possible to filter access rules based on `access_to`,
`access_type`, `access_level` and `access_key`.
DocImpact
Change-Id: Iea422c9d6bc99a81cd88c5f4b7055d6a1cf97fdc
In case of snapshot create/update, if display name or description is
above max limit (fields created in db with limit 255), manila
internally throws DB exception. But the error reported to user is not
meaningful.
Fix by validating name/description length should not cross max limit.
Closes-bug: #2023964
Change-Id: I6b1a274da3692700650f84736877c0ae98d46c81
Manila can now configure a share network with multiple subnets
in an availability zone. Also, it can add a new subnet for an
availability that has share servers, which will triger an update
share server allocations.
Changes:
- API:
- Bump version to 2.70.
- setup share network with multiple subents per az.
- Block manage server with multiple subnets.
- Allow add subnet for in-use share servers.
- `share_network_subnet_id` is dropped from ShareServer view
- `share_network_subnet_ids` is added in ShareServer view
- `network_allocation_update_support` is added to ShareServer and
ShareNetwork views.
- Add a check operation for share network subnet create.
- DB:
- Remove `share_network_subnet_id` from share_servers.
- Create mapping table `share_server_share_network_subnet_mappings`.
- Fix queries with new db design.
- Add migration downgrade and upgrade alembic.
- Add `share_network_subnet_id` to the NetworkAllocations.
- Scheduler:
- Change `AvailabilityZoneFilter` to take in account if the
host supports the allocation required by the setup request.
- Manager:
- Bump RPC API version.
- `_setup_server` allocating multiple subnets.
- Modify signature of driver `_setup_server` interface, passing a
list of `network_info` for each subnet.
- Share server DB creation to inform a list of subnets and
create with `network_allocation_update_support`.
- Implement `check_update_share_server_network_allocations` and
`update_share_server_network_allocations`.
- Drivers:
- For legacy compatibility, all drivers implementing `_setup_server`
consume the first element of the `network_ino`.
- Dummy Driver:
- Implement `_setup_server` with new signature as multiple subnet.
- Modify the `backend_details` to save allocations for all subnets.
- Report update allocation and share server multiple subnet support.
- Implement `check_update_share_server_network_allocations` and
`update_share_server_network_allocations` interfaces.
Signed-off-by: Felipe Rodrigues <felipefuty01@gmail.com>
Co-Authored-By: Andre Beltrami <debeltrami@gmail.com>
Co-Authored-By: Fábio Oliveira <fabioaurelio1269@gmail.com>
Co-Authored-By: Nahim Alves de Souza <nahimsouza@outlook.com>
Co-Authored-By: Caique Mello <caique_mellosbo@hotmail.com>
DocImpact
APIImpact
Partially-Implements: blueprint multiple-share-network-subnets
Change-Id: I7de9de4ae509182e9494bba604979cce03acceec
Add an force parameter to the API layer that lets the user choose
whether to go through the scheduler or not, which is boolean.and
default is False,set True means extend share directly, set False
means extend share will go through scheduler.
Add an new min_version 2.64 to extend share api. force parameter
only support min_version >= 2.64.
Closes-Bug:#1855391
Change-Id: I6da36a687a37c78a7fb7d3f252318d03d4a05133
This patch implements the update of security service's association
with in-use share networks. The following changes were added:
- New share network APIs: `share_network_security_service_update`
and `share_network_reset_state`.
- A new `status` attribute was added to share network model to
identify when it's in a modification state, called 'network_change'.
Other supported status that were added: 'active' and 'error'.
- New 'security_service_update_support' property was added to both
share server and share network models, to identify when this resources
are able to process security service update for in-use share networks.
- New driver interface was added to support update of security service's
configuration of a given share server.
DocImpact
APIImpact
Partially Implements: bp add-security-service-in-use-share-networks
Co-Authored-By: Carlos Eduardo <ces.eduardo98@gmail.com>
Co-Authored-By: Douglas Viroel <viroel@gmail.com>
Co-Authored-By: Andre Beltrami <debeltrami@gmail.com>
Change-Id: I129a794dfd2d179fa2b9a2fed050459d6f00b0de
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>
This patch modifies the database api layer to fix the pagination
slowness bug, which causes a delay while the administrator tries
to list shares using the `--limit` option.
This change was tested in a very busy environment with 800 shares.
Before the change, the operation took about 25 seconds to be
finished. Now, the operation takes about 3 seconds in the same
environment.
Change-Id: I89659452b0e033631f1318a2eabb7e120c9e5743
Closes-bug: #1795463
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>
Public shares are visible across all keystone
projects and are "accessible" by all projects
within a multi-tenant cloud. More often than not,
only privileged users can create and manage shares
that EVERYONE on the cloud can really mount and use.
Manila deployers want a way to disable
unprivileged users from create public shares. Feedback
from deployers has been that public shares created on one
private tenant network (DHSS=True scenario) cannot
be used within another private tenant network belonging
to a different project. So, if users unintentionally create
public shares, they end up pollute the dashboards of users
in other projects. So, we need to make public share
creation a "privileged" feature. This can be achieved by
introducing a manila API policy that defaults to
only allowing the "admin" role. So, this commit will:
- Introduce two new policies:
- share:create_public_share and
- share:set_public_share
- Set the default check string for these policies
to rule:admin_api. They will accept the default
rule temporarily, and log a deprecation warning
message.
- Remove some redundant policy checks in code
and move the policy check up in the API so we
can fail unauthorized requests faster.
When making an API change that potentially changes
the return code from being "successful" (HTTP 2xx)
to returning failure (in this case: HTTP 403,
NotAuthorized), we typically maintain API backwards
compatibility by failing the requests ONLY with newer
API microversions. Following this pattern for API
policy changes will introduce a security hole, i.e.,
users can always create public shares with previous
versions even when an administrator explicitly
sets up policy to disable the action. This is why
this change will not maintain API backwards
compatibility.
APIImpact
Closes-Bug: #1801763
Change-Id: Ib4fc9a82b6a3e5f8e50f0bc8a89d0445eecab028
Administrators configure share types and make them
available to projects within an OpenStack cloud.
These share types will define capabilities to match
back-end storage pools that manila provisions shares
within. Administrators may want to limit share types
to specific Availability zones, given they may have
different classes of storage in different availability
zones in the cloud. A major use case of this is edge
computing, where, provisioning can be driven to specific
edge locations with the help of share types.
This commit will:
- Introduce 'availability_zones' as a new common share type
extra spec that is user visible when configured.
- In and beyond microversion 2.48, validate that the AZ
chosen in the POST /shares API is supported by the configured
availability zones for the share type being used.
- Share types can be filtered by AZs through extra-specs:
$ manila type-list --extra-specs availability_zone=nova
now gives you all types that explicitly (and implicitly)
are supported within the AZ 'nova'.
- Improve experimental APIs:
- Add validation of AZ to POST /share-replicas
- Add validation of AZ to POST /share-groups
- Add validation of AZ to
POST /shares/id {'action': 'migration_start'}
- Also fix old unit tests by using a helper method to
generate appropriate mock values.
DocImpact
Change-Id: Idf274cd73e3b1b33f49668fca768ae676ca30164
Implements: bp share-type-supported-azs
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
When request default share type and show share type detailed,
the share type results is not correct, because the values of
attribute required_extra_specs is always empty.
Change-Id: I68fc4e2ba30bbd87b5417fe48688edd96cbcee5d
Closes-Bug: #1733742
The shares view uses the 'Share' model to access certain properties such
as the share type or the share type id. These properties are, however,
only proxied to the 'ShareInstance' model. This patch proposes to access
these properties through the 'ShareInstance' model directly in order to
avoid warning messages for proxied properties which pollute the m-api logs.
Closes-Bug: #1692058
Change-Id: I28fa366e106df51c7406673874bd993a44c500bf
Currently, The user access name is limited to 32 characters in manila API service,
but actually the user access name is longer than 32 characters. so we need
to change user access name limit from 32 to 255 characters
APIImpact
Closes-bug: 1674908
Change-Id: I68d8afabcd3fef57e472b4067ea8949e0aa8f53a
Also, allow filtering by host based on policy 'list_by_host' that
defaults to 'admin only'.
Do not bump API, because it is not considered as expected behavior,
hence should not be kept for old microversions.
Co-Authored-By: Valeriy Ponomaryov <vponomaryov@mirantis.com>
APIImpact
Change-Id: I799bb7378927b6c3ee0f9fe88fd9876a03dd85b5
Closes bug: 1664370
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
Remove the experimental consistency group APIs and
replace them with the experimental Share Group APIs.
DocImpact
APIImpact
Partially-implements-blueprint: manila-share-groups
Change-Id: I79a80a62ae4e0015d6161edc2b93fd1f9ba69537
- Pull up policy check to beginning of the APIs.
- Avoid making access rules changes when one or
more instances of the share are in an invalid state.
- Add back the per rule share instance access status.
This restoration provides better visibility for which
rules were applied successfully.
- Remove 'updating' and 'updating_multiple' as valid
states for the share instance access rules status.
- Deprecate the access rule state 'new' in favor of
'queued_to_apply' and the share instance access rules
status 'out_of_sync' in favor of 'syncing'.
In a new API micro-version:
- Allow access rule changes irrespective of the share's
access_rules_status.
- Expose new access rule states and share's
access_rules_status values.
Access rules for each share instance now transition
from 'queued_to_apply' to 'applying' to 'active' or 'error';
and from 'active', 'queued_to_apply', 'applying' or 'error'
to 'queued_to_deny' to 'denying' to 'deleted'.
APIImpact
DocImpact
Partially-implements: bp fix-and-improve-access-rules
Co-Authored-By: Mike Rooney <rooneym@netapp.com>
Change-Id: Ic25e63215b5ba723cbc8cab7c51789c698e76f28
The snapshot_support extra spec has always meant two
things: a driver can take snapshots and create shares
from snapshots. As we add alternate snapshot semantics,
it is likely that some drivers will want to support
snapshots and some of the new semantics while being
unable to create new shares from snapshots.
This work adds a new extra spec,
create_share_from_snapshot_support, that removes the
overloading on snapshot_support. It also makes the
existing snapshot_support extra spec optional,
allowing admins to create types without setting
snapshot_support; shares created with such types
will not support snapshots.
APIImpact
DocImpact
Co-Authored-By: Goutham Pacha Ravi <gouthamr@netapp.com>
Implements: blueprint add-create-share-from-snapshot-extra-spec
Change-Id: Ib0ad5fbfdf6297665c208149b08c8d21b3c232be
For backends with internal authentication system,
e.g. Ceph, that return ``access_key`` (credential) for
client identities that are granted share access:
* Retrieve ``access_key`` as return value of driver's
update_access()
* Store ``access_key`` in ShareAccessMapping model
* Expose it in access_list API
APIImpact
DocImpact
Partially implements bp auth-access-keys
Co-Authored-By: John Spray <jspray@redhat.com>
Change-Id: I486064f117cf3001dba7735ca92a7d89aee3ce5b
For the moment it is possible to schedule share creation with DHSS=true
share type but without share network. But it makes no sense, and
expected to fail. So, perform check on API level.
APIImpact
When create share with share type(DHSS=true) and not input share
network, API will return HTTPBadRequest and message:
"Share network must be set when the driver_handles_share_servers
is true."
Closes-Bug: #1525125
Change-Id: Icdfabff7b1d3b6e95dd1dd58a0155de637056657
This driver enables use of the Ceph filesystem for
Manila shares. Clients require a native CephFS
client to access the share. The interface
to Ceph is CephFSVolumeClient, included in
the 'Jewel' Ceph release and later.
APIImpact
The API microversion is bumped to 2.13 to add a
new access type, cephx, supported by the driver.
Co-Authored-By: Ramana Raja <rraja@redhat.com>
Implements: blueprint cephfs-driver
Change-Id: I33801215f64eacb9dade4d92f11f659173abb7f5
The API code emits a ton of deprecation warnings from the view builder
code using deprecated properties on the share DB object which proxies
to the share instance, so this changes the code to use the share.instance
property instead.
Note that since the tests are mocking out the share as a dict in a lot of
places, we have to handle accessing the instance as a dict entry rather
than an attribute on a sqlalchemy object. Because of this, the wrapper
class in the stubs module needed to be updated to actually work like a
dict container. This is done by extending the abstract base class
collections.Mapping and overriding the update method. Now the runtime
code can access attributes on the share like a dict (which old tests are
still using outside of the stubs module) or an attribute like would be
the case with the sqlalchemy object.
Partial-Bug: #1510507
Change-Id: I114b67dfeef0f46022230f91c6807a69ea9175a2
After port of extensions to core API we need to rename their URLs.
So, rename URLs and bump microversion for it.
Make new URLs work only with new microversion(s) 2.7+
and old with old microversions 1.0-2.6.
Add separate API router for v2 API as now we should split v1 and v2
logic.
Also, move updated APIs under v2 directory that will be used by both
API routers - v1 and v2.
List of updated collections is following:
- os-availability-zone -> availability-zones
- os-services -> services
- os-quota-sets -> quota-sets
- os-quota-class-sets -> quota-class-sets
- os-share-manage -> shares/manage
- os-share-unmanage -> shares/%s/action
List of updated member actions is following:
- os-share-unmanage/%(share_id)s/unmanage -> shares/%(share_id)s/action
- types/%(id)s/os-share-type-access -> types/%(id)s/share_type_access
List of updated action names is following:
- os-access_allow -> access_allow
- os-access_deny -> access_deny
- os-access_list -> access_list
- os-reset_status -> reset_status
- os-force_delete -> force_delete
- os-migrate_share -> migrate_share
- os-extend -> extend
- os-shrink -> shrink
List of updated attribute names is following:
- os-share-type-access -> share-type-access
Partially implements bp ext-to-core
Change-Id: I82f00114db985b4b3bf4db0a64191559508ac600
Changes:
- Register admin actions API as core API.
- Remove extension code for admin actions.
- Leave rename of admin actions API 'post' data for future update which
will be done with bump of microversion
after port of all extensions to core API.
Partially implements bp ext-to-core
Closes-Bug: #1510620
Change-Id: Ic8804cff5fa46003d2991372c6eb2a854b886dec
Changes:
- Register share actions API as core API.
- Remove extension code for share actions.
- Leave rename of share actions API 'put' data for future update which
will be done with bump of microversion
after port of all extensions to core API.
Partially implements bp ext-to-core
Change-Id: I7fef38c37ae539473b6e3d2a0758c336b2a7d33c
Fix incorrect order assertEqual(observed, expected) as below.
assertEqual(observed, expected) => assertEqual(expected, observed)
Target of this patch:
manila/tests/api/*
Note:
I also fix following asserts aruond above fixed parts.
assertEqual(xx, True), assertEqual(True, xx) => assertTrue(xx)
As for assertFalse,
I do not convert assertEqual(xx, False) to assertFalse(xx)
because assertFalse(None) does not raise exception.
Change-Id: I8131946efef654235b5e32344b3f5e42ab3d3ced
Partial-Bug: #1259292
A previous patch added experimental=True to hide task_state field
for any API call that would return share fields, such as "create"
and "get" calls if different than microversion "2.5" with
experimental=True. Turns out the field task_state should be
returned always if microversion is "2.5" or above because it
relates to a change in DB, not only to the usage of Share Migration
feature. This patch fixes it by removing experimental=True
dependency to show task_state field.
Closes-bug: #1497352
Change-Id: Ic07d63ebcfe25c1cfa3fac1e75e2e186fbcec25b
Recently was introduced feature where snapshots become optional.
Share started have new attr "snapshot_support". But it is absent in
share payload and, hence, can not be used outside of Manila.
Also, fix lost import of translation function for related snapshot API.
Change-Id: Iddb0cf1e046b9d480a22e79b33c8674a2405362e
Closes-Bug: #1491345
Closes-Bug: #1491346
After Share Migration was included, the task_state field was
added to be displayed on GET requests, but API versions prior to
2.5 should not see this field. This patch fixes that by using
microversions.
Closes-bug: #1494746
Change-Id: Ie755ae53fe8efdf1702a0ecbabf022a5fe4beb93
To prevent a microversioned client from managing a non-microversioned
Manila server, Manila must update its REST endpoints by adding /v2 for
all microversioned APIs.
This commit does the following:
* Add /v2 to the URL map, connected to all the same /v1 API methods
* Renumber the microversion sequence starting from 2.0
* Update the versions API to reflect v2
* Publish the new endpoint to Keystone in the DevStack plug-in
* Update relevant documentation
* Update Tempest tests for microversions
APIImpact
Co-Authored-By: Andrew Kerr <andrew.kerr@netapp.com>
Closes-Bug: 1488624
Change-Id: I56a516b5f81914557dd2465746629431cfd6deac
Share Migration allows a share to be migrated from
one host#pool to another host#pool through the
"manila migrate <share> <host#pool>" command. It first
calls the driver to perform it in an optimized way if
possible. If the driver returns that it did not migrate,
it performs a generic migration.
A new field has been added to "shares" table: task_state,
which tracks migration status.
For driver migration, the method migrate_share in driver
base class should be overridden.
For generic migration, drivers may use new config options
to achieve the necessary configuration:
- migration_mounting_backend_ip: If backend has additional
exports IP for admin network, specify it here.
- migration_data_copy_node_ip: IP of entity performing
migration between backends, such as manila node or
data copy service node. This may not apply for
DHSS = true drivers.
- migration_protocol_mount_command: specify mount command
with protocol and additional parameters. Advisable to restrict
protocols per backend. Defaults to "mount -t <share_proto>".
If additional customization is needed, drivers may override
certain methods:
- _mount_share: return the mount command.
- _umount_share: return the umount command.
- _get_access_rule_for_data_copy: return an access rule with
the IP address which will allow the manila node or data copy node
to mount the share after added permission through
allow-access API command.
Change-Id: I8dde892cb7c0180b2b56d8c7d680dfe2320c2ec7
Implements: blueprint share-migration
This patch adds the /consistency-groups and /cgsnapshots
endpoints as well as AdminActions for both.
Partially implements bp manila-consistency-groups
APIImpact
Change-Id: I5fd0d3341766fdba4d92f4a43c3d1186e7a4b38e
Rework availability zones support which was inherited from Cinder:
- Add public API extension
- Preserve AZ if creating a share from a snapshot
- Always set AZ in Share API or Share Manager
- Update db schema and create db migration
- Update appropriate unit tests
APIImpact
Partially-Implements: blueprint availability-zones
Change-Id: Iea9fbc3fea5c0128772115c028989121f397e0c5
We have several entities in Manila that do have statuses:
- Shares
- Snapshots
- Share Servers
- Share Access Rules
But some share and all share server statuses use uppercase for it.
Make all of them consistent and transform them to lowercase.
Add migrations for it.
Also, remove two unused statuses and reuse all statuses from common place.
Change-Id: I53e6a768c98977d3d94e761349b7446a9dfb4936
Closes-Bug: #1459598
Many storage controllers actually have more than one
"export location" that clients can mount to access any
given share. Manila only allows storing 1 of these today,
which is a bothersome limitation.
Partially implements bp multiple-export-locations
Change-Id: Ib9d497e76762d4862bc5c87e6186e1d096b1d2a6
For the moment only owner of share can see it. There are use cases when
we may want to share it for all, for example, only with "ro" access.
Shares should be able to be visible for all tenants - additional attr
'is_public=True/False' will work for it.
Add 'is_public' column to share model and add migration which creates
this new column (default is public=False).
Allow to pass new 'public' param to share api methods 'create' and
'get_all'.
Change DB API functions 'share_get_all_by_project' and '_share_get_all_with_filters'
to add public shares from all projects when 'public=True' is provided.
Implements bp level-of-visibility-for-shares
Change-Id: I444f5b3aceea8322d947722e945ff81c0b2b84cc
Implement possibility to set up default share type for share creation.
If default share type is set up and in case no share type is specified,
a default share type will be provided with the share creation request.
It is useful when we want some specific back end to be used in common
cases instead of weighed back ends.
How to use it:
1) add to manila.conf file following option
default_share_type = some_st_name
to [DEFAULT] group of config.
2) restart manila API service if was started
3) create share type with name "some_st_name"
4) add some extra specs to share type, for example:
share_backend_name = cheap_backend
Implements blueprint default-volume-type
Change-Id: Ief32825360cbb3e7df9149e8980c11c5018f52f7
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
The Manila test module uses a class called StubOutForTesting, which
is an awkward holdover from when the unit tests were using Mox.
Alex wrote a more elegant and capable mocker method,
manila.test.TestCase.mock_object, in the Cinder project which we
have now added to Manila. So to remove the duplicate functionality
and legacy code, all references to self.stubs.Set() in the Manila
tests should be replaced with self.mock_object() and any related
dead code should be removed.
Resolves-bug: #1415602
Change-Id: Ie5f203c0b2cb57ad00d9ec8db0529075b6fef261
jayaanand.borra@netapp.com