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
https://review.opendev.org/768137 fixed
bug #1908963 by adding a timestamp field to
the "update_service_capabilities" rpc API
call to the scheduler service.
It's possible that during an upgrade, the
share service is upgraded before a given
scheduler service, and an updated client
could start sending messages with this
extra data that wasn't expected. Lets
bump the version so that the client
messages are just waiting for an updated
scheduler to show up and consume the
messages rather than raise syntax
errors.
Partial-Bug: #1908963
Change-Id: I0d9fc311ffd296bd6153b7190f8f5c42f494a39d
Signed-off-by: Goutham Pacha Ravi <gouthampravi@gmail.com>
if rabbitmq is too much pressure or blockage.scheduler
will not received service capabilities, but once the
message queue(rabbitmq) returns to normal, scheduler
will received many service capabilities, these service
capabilities are acquired by manila share at different
times, so the timestamp of service capabilities shoud
added at share manage layer(before rpc), but not
scheduler layer(after rpc), once scheduler get an newer
service capabilities, there is no need to update an
earlier service capabilities.
Closes-Bug: #1908963
Change-Id: I6ce99ed4451c5d02cb4446861fa59e55a94951a5
'Share groups' feature was not finished completely in Ocata timeframe.
There was absent possibility to specify 'availability zone' for
creation of a share group. So, implement it.
The fact of its implementation fixes mentioned bug below.
Closes-Bug: #1662944
Partially-Implements BP manila-share-groups
Change-Id: I000adeb53fe8435465cbedc3c539e6aaae6503c5
Our form of todo extension does not work with sphinx 1.5.2.
Remove it to unblock gate: we can add todos back in later with
more current methods. Also clean up some dangling cross-references
in the doc.
Co-Authored-By: Valeriy Ponomaryov <vponomaryov@mirantis.com>
Change-Id: If74b9e32ad2b5d8d70da60895d85588ff993797e
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
Implemented several improvements to share migration
according to spec [1].
Summary of changes:
- Snapshot restriction in API has been changed to return error only
when parameter force-host-assisted-migration is True
- Added preserve_snapshot to API and migration_check_compatibility
driver interface
- Changed all driver-assisted API parameters to be mandatory
- Added validation to prevent 'force_host_assisted_migration' to be
used alongside driver-assisted parameters
- Changed "same host" validation to reject only if the combination
of "host", "new_share_network" and "new_share_type" is the same as
the source
- Updated migration driver interfaces to support snapshots
- Updated zfsonlinux driver, defaulting preserve_snapshots to False
- Updated dummy driver to support preserve_snapshots
Spec update with latest changes since [1] merged
can be found in [2].
APIImpact
DocImpact
[1] I5717e902373d79ed0d55372afdedfaa98134c24e
[2] If02180ec3b5ae05c9ff18c9f5a054c33f13edcdf
Change-Id: I764b389816319ed0ac5178cadbf809cb632035b4
Partially-implements: blueprint ocata-migration-improvements
This patch adds a 'new_share_type_id' parameter to Share Migration,
where the destination share can be provisioned under a different
share type of choice.
Host-assisted migration handles it by creating a totally new share,
as before.
Driver-assisted migration handles by creating the destination
instance model with the new share type, the driver is responsible
for making the necessary changes to satisfy the provided model.
In order to accomplish this, a database change was required,
transferring the 'share_type_id' field from the 'shares' table
to the 'share_instances' table.
APIImpact
Partially implements: blueprint newton-migration-improvements
Change-Id: I3200eaaa5b66d9b8ce1cbd16c1658db8516c70fb
At Austin 2016 summit there were several improvements to
Share migration feature discussed. This patch implements
these changes.
Changes are:
- Added 'Writable' API parameter: user chooses whether share must
remain writable during migration.
- Added 'Preserve Metadata' API parameter: user chooses whether
share must preserve all file metadata on migration.
- Added 'Non-disruptive' API parameter: user chooses whether
migration of share must be performed non-disruptively.
- Removed existing 'Notify', thus removing 1-phase migration
possibility.
- Renamed existing 'Force Host Copy' parameter to 'Force
Host-assisted Migration'.
- Renamed all 'migration_info' and 'migration_get_info' entries to
'connection_info' and 'connection_get_info'.
- Updated driver interfaces with the new API parameters, drivers
must respect them.
- Changed share/api => scheduler RPCAPI back to asynchronous.
- Added optional SHA-256 validation to perform additional check if
bytes were corrupted during copying.
- Added mount options configuration to Data Service so CIFS shares
can be mounted.
- Driver may override _get_access_mapping if supports a different
access_type/protocol combination than what is defined by default.
- Added CIFS share protocol support and 'user' access type
support to Data Service.
- Reset Task State API now allows task_state to be unset using
'None' value.
- Added possibility to change share-network when migrating a share.
- Bumped microversion to 2.22.
- Removed support of all previous versions of Share Migration APIs.
APIImpact
DocImpact
Implements: blueprint newton-migration-improvements
Change-Id: Ief49a46c86ed3c22d3b31021aff86a9ce0ecbe3b
Formatting errors have crept into the manila devref
and have been accumulating over time. It would
be nice to fix these as part of the devref cleanup.
Closes-Bug: #1583850
Partially-implements: bp improve-manila-developer-docs
Change-Id: I7ec954e720b4b88a21e265cd71ea598ea9a5213b
RPCAPI call to Scheduler to perform share_type and host
validation should be asynchronous so share can be
created in DB with status "manage_error" if validation
is not successful.
This change also addresses incorrect exception type in API
and DB popping fields from supplied parameter.
APIImpact
Closes-bug: #1561139
Change-Id: I928f1d6b5657098f9d2b7917e2e334a1f08903f8
Currently manage API allows managing a share with a share type that
may not make sense in the service host. This patch addresses this
by invoking the scheduler to validate the host before invoking the
backend manager.
APIImpact
Change-Id: I8c780f2518f4a6eacf37cc448c73fbb41f6b7507
Closes-bug: #1544725
Removed functionality of Share Migration relying on Manila Share
Service node, moved code to Data Service node for copy phase.
Added parameter 'notify' and share/api methods for future
implementation (see dependent patches).
Added new copy operation statuses, in order to implement future
API calls to obtain progress and cancel migration.
Added possibility of 2-phase migration for driver migration and
generic (fallback) migration.
Added admin export location support and removed approach of
replacing IP with config parameter.
Added Admin-only API entry points to:
- Migration Cancel (only during copying)
- Reset Task State field
- Migration Get Progress (only during copying)
- Migration Complete (2nd phase migration)
- Notify parameter on Migrate Share
APIImpact
DocImpact
Implements: blueprint data-service-migration
Change-Id: I1d65aac2f36942cd70eb214be561d59a15a4ba26
In manila/share/rpcapi and manila/scheduler/rpcapi
files, 'cctxt' is used to receive the prepared rpcapi
client call context from oslo_messaging. The purpose
of this identifier is not immediately discernible
from the other 'ctxt' used in the files (that denotes
request context).
Fix it to enhance readability.
TrivialFix
Change-Id: I54c614d9e963da23a0aeb92cb196fddf5ec751e6
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
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 implements the scheduler changes for
scheduling the creation of consistency groups,
shares within consistency groups, and cgsnapshots.
The consistency group scheduling filter was added
to allow the filtering of hosts that are not supported
by a specified consistency group. If no CG is specified
on share create then this filter is a no-op. CGs will be
scheduled only to a backend that supports all of its
specified share types.
Partially implements bp manila-consistency-groups
Change-Id: Ia03191085cefb47a17ce99ad3f30ba70412f5802
This commit adds a possibility to create/delete
share instances and allow/disable access to individual
share instances through Share API. It's required minimum
in Manila core to implement share migration functionality.
Also this commit updates methods in Share RPC API,
Share manager, Scheduler RPC API and Share manager
to maintain consistency.
Partially implements bp share-instances
Change-Id: I3af93071b5851944b59a3c5b1a0c2296e1267bfe
The Oslo libraries have moved all of their code out of the 'oslo'
namespace package into per-library packages. The namespace package was
retained during kilo for backwards compatibility, but will be removed by
the liberty-2 milestone. This change removes the use of the namespace
package, replacing it with the new package names.
The patches in the libraries will be put on hold until application
patches have landed, or L2, whichever comes first. At that point, new
versions of the libraries without namespace packages will be released as
a major version update.
Please merge this patch, or an equivalent, before L2 to avoid problems
with those library releases.
Blueprint: remove-namespace-packages
https://blueprints.launchpad.net/oslo-incubator/+spec/remove-namespace-packages
Change-Id: I75e6e15d50ef9830d0581efd4cbcceb3e626f7b7
This change introduces pool-aware scheduler to address the need for
supporting multiple pools from one storage controller.
Derived from the Cinder Implementation of Pool-aware Scheduler -
https://review.openstack.org/#/c/98715/ and
https://review.openstack.org/#/c/119938
Implements blueprint: dynamic-storage-pools
Change-Id: I3aee5ed1f96f972f7d40fbd981393559587c1a23
The oslo team is recommending everyone to switch to the
non-namespaced versions of libraries. Updating the hacking
rule to include a check to prevent oslo.* import from
creeping back in.
oslo.messaging is the only exception because this package doesn't
currently support non-namespaced imports.
Change-Id: I3987e651bc880c8ffa7c0105df0298679dcd3a43
Replace usage of deprecated jsonutils module from oslo-incubator
and use oslo.serialization instead.
A followup-patch will sync with oslo-incubator and remove
the jsonutils module from manila.
Partial-Bug: #1382189
Change-Id: Iafa5090fd0c960ae8e996229ea3352f890decc6c
Manila uses oslo-incubator/rpc as an RPC library.
During Havana, oslo/rpc was cleaned up and moved into
oslo.messaging with a more stable and well-defined API.
oslo-incubator/rpc considered as deprecated and should be
replaced with oslo.messaging in Manila.
Sum changes:
* New dependency oslo.messaging>=1.3.0 is required
* The new rpc module has init() and cleanup() methods which manage the
global oslo.messaging transport state. The TRANSPORT and NOTIFIER
globals are conceptually similar to the current RPCIMPL global,
except we're free to create and use alternate Transport objects.
* The rpc.get_{client,server,notifier}() methods are just helpers
which wrap the global messaging state, specifiy serializers and
specify the use of the eventlet executor.
* In oslo.messaging, a request context is expected to be a dict, so
RequestContextSerializer was added which can serialize to and from
dicts using RequestContext.{to,from}_dict()
* The allowed_rpc_exception_modules configuration option is replaced
by an allowed_remote_exmods get_transport() parameter. This is not
something that users ever need to configure, but it is something
each project using oslo.messaging needs to be able to customize.
* We maintain a global NOTIFIER object and create specializations of
it with specific publisher IDs in order to avoid notification driver
loading overhead.
* rpc.py contains transport aliases for backwards compatibility
purposes. setup.cfg also contains notification driver aliases for
backwards compat.
* messaging.ConfFixture is used in tests to override oslo.messaging
config options, rather than making assumptions about the options
registered by the library.
Partially-implements bp oslo-messaging
Change-Id: I42cd582f3e1ff96c8f6e8957122b8e9176b1771d
Moving file flags.py to manila/common/config.py,
replacing FLAGS by CONF. Rename modules fake_flags to conf_fixture,
test_flags to test_conf, declare_flags to declare_conf,
runtime_flags to runtime_conf like it was done in cinder, nova, glance etc.
Implement bp: use-oslo-conf
Change-Id: I38d869123e5e706d3b06f1844b97ead05e22668f
haixin