When manila services are stopped or restarted via stop(), the DB
entries are not deleted, they are destroyed only in kill() method. In
cluster deployments, where multiple instances of manila services are
deployed via PODs, unique hostname is derived from node name. However
if pods are deployed again and launched on new hosts/nodes, the old
entries of manila service remains as it is.
Fix it by adding 'state' column in 'services' table and introducing
per service cleanup function. On service stop, state is changed to
'stopped' and cleanup function will delete 'stopped' services unless
they are 'up' again before cleanup periodic interval.
Closes-bug: #1990839
Change-Id: I8b71c4c27ff8fcb25616a95a5ed8362a7f4ffc61
Fixed the issue in the share migration where the replica quotas
were not being accounted. Manila now tries to allocate share
replica quotas for the migrated share if the destination share type
has a `replication_type`.
If the migration fails or get cancelled, the quotas will be
reverted.
Change-Id: Ie0a08a61c79dc8ea2a7a240363e94b26a80e64a4
Closes-Bug: 1910752
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 change adds a new hook to Manager class called init_host_with_rpc()
to allow services like scheduler to do something once RPC is ready.
Copied from cinder 65fa80c361
and 60c563f72d
Change-Id: Iac6507a6e395c55f0fec453650009f08c2bb6563
Closes-Bug: #1271568
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 we failed to manage a share, we don't need to commit the quota usages. so
we should skip quota usages cuts when delete or unmange the share with
status of "error_manage". and the size of error_manage share should be
zero.
Closes-Bug:#1883506
Change-Id: I5c81dd6780890c55c8c6a92491c3f4f507531fdb
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
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
Adds a task to manila-scheduler service which periodically (once per day
by default) cleans up expired user messages. In user messages spec I
preferred doing this cleanup by a "manila-manage" command invoked by
user. But because it would mean another task management for admin and
because cinder uses periodic task too, I diverged from the spec.
Change-Id: If0ba2383d4d7eaca4dee8a0d39f39c5481bfbfdd
Partially-Implements: bp user-messages
Instead of creating a user message only from scheduler during
resource creation, a message is created directly by share manager
which allows more detailed error reporting.
Partially-implements: blueprint user-messages
Change-Id: Ic7d25a144905a39c56ababe8bd666b01bc0d0aef
For quite some time, OpenStack services have wanted to be able to send
messages to API end users (by user I do not mean the operator, but the
user that is interacting with the client).
This patch implements basic user messages with the following APIs.
GET /messages
GET /messages/<message_id>
DELETE /messages/<message_id>
Implements the basic /messages resource and tempest tests
The patch is aligned with related cinder patch where possible:
I8a635a07ed6ff93ccb71df8c404c927d1ecef005
DocImpact
APIImpact
Needed-By: I5ffb840a271c518f62ee1accfd8e20a97f45594d
Needed-By: I9ce096eebda3249687268e361b7141dea4032b57
Needed-By: Ic7d25a144905a39c56ababe8bd666b01bc0d0aef
Partially-implements: blueprint user-messages
Co-Authored-By: Jan Provaznik <jprovazn@redhat.com>
Change-Id: Ia0cc524e0bfb2ca5e495e575e17e9911c746690b
Currently we would have uncommit reservations in database if
the commit operation failed. This could obstruct creating new
shares or others which would consume quota. This patch adds
a perodic task to clean this expired reservations.
Also fix bug in db.reservation_expire method(We dropped
attribute 'usage' from Reservation, but it's still used
in this method).
Closes-Bug: #1669449
Change-Id: I3dc0973ebac5eb33832e242c72059be1eb954369
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
Currently, when we set share-state to 'manage-error', share-size
is set to 1 at all places except this one. Which results in error
logged during delete-share, w.r.t quota.
This fix sets share-size to 1 when share state is
set to 'manage_error'.
Change-Id: I96343ffd4f273b01c0376713717cdc89ea9a873a
Closes-Bug: #1587636
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
Tempest tests were not appropriate for driver-assisted migration,
so this was fixed.
Also, improved docstrings and fixed workflow for drivers when
implementing 2-phase migration to be accurate with tempest and
handle AZs, which were previously locked to the source share's
AZ.
Driver-assisted migration now creates an additional
share instance to better handle and support driver methods.
Updated allow_access and deny_access APIs to allow users to mount
migrating shares before issuing 'migration-complete'.
APIImpact
Closes-bug: #1594922
Change-Id: If4bfaf7e9d963b83c13a6fea241c2eda14f7f409
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
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
Currently, while scheduling a new replica, the ShareReplicationFilter
passes any host that shares the replication_domain of the active
replica's host. On successive runs on the CI, it was observed
that the same host was chosen multiple times. In a real
deployment, there is no practicality in allowing replication
within the same pool.
Pass more information to assist the filter in disqualifying hosts that
already host replicas for the share.
Also treat NoValidHost exception differently from other scheduler
exceptions to be consistent with other scheduling failures.
Change-Id: Iedc7b752c7fc477d6257d100e2277378d59f1fde
Closes-Bug: #1554282
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
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
With oslo-incubator going away, we need to pull those classes into
the Manila code base, along with their unit tests. This presents a
good opportunity to do some long-needed housecleaning. This commit
does the following:
1. Moves the scheduler classes from openstack.common to manila.
2. Adds the unit tests from olso-incubator into Manila.
3. Removes duplication among the combined scheduler modules.
4. Moves scheduler drivers into a sub-module.
5. Normalizes class and module naming throughout the scheduler.
6. Splits some unit test files so they match the names of the
modules that they test.
7. Converts usage of mox & oslotest to mock & unittest.
8. Adds a few unit tests to boost coverage levels.
Implements: blueprint reorganize-manila-scheduler
Change-Id: I7aa237e17787e89a95bb198093ea9bc9498279cd
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
Change the log level 'WARNING' to 'ERROR' in scheduler.manage.py.
Because if the log level is WARNING, The root cause can not be
found quickly when a new share creation fails in scheduler mode.
In other words, this log level is more suitable for 'ERROR'.
Change-Id: Ic6b5a7e84e9dd8c3381b2c3760c9dcc6d434f8ed
Closes-Bug: #1481745
Manage share functionality adds possibility to add existing
shares to manila. On other hand unmanage functionality adds
possibility to remove shares from manila, but without physical
removal from share backend.
Due to high implementation complexity and risks it was
decided to implement manage/unmanage methods only for
driver_manage_share_servers=False driver's and implement
this functionality for other cases in future. Also administrator
can't unmanage shares that were created with a share_server.
- Add manage() and unmanage() methods in admin API
- Add manage_share() and unmanage_share() methods to share rpcapi
and share manager
- Update share rpcapi version to 1.1
- Add manage_existing(), unmanage() methods
to share driver
- Add appropriate unit tests.
Partially implements bp manage-shares
Change-Id: Iedfd85cb6bdfade67c04f62c04756ac192db6b66
Module 'log' from oslo-incubator was removed after release of oslo_log library.
So, start using oslo_log, but keep oslo-incubator code yet other common modules
within Manila codebase use it.
Implements bp use-oslo-log-lib
Change-Id: I88224f7c2bd99adb78140dfc3fa73cea437f29cd
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
LOG.warn etc. should be translated separately and thus messages need to
be marked with _LW for LOG.warn, _LI for LOG.info and _LE for LOG.errors
and LOG.exception.
Mark all LOG invocations with proper translation marker.
Use ',' instead of '%' when adding variables to log messages to allow
lazy evaluation.
Add new hacking checks for these.
Change-Id: I31d3ee50f30c63d7d647b1c2b1eae50bf96f0c74
Change usage of modules that are deprecated in oslo-incubator.
Use the corresponding module from oslo.utils.
A followup patch will sync with oslo-incubator and remove the now
obsolete modules.
Change-Id: I4f949de57e333832dcc7c1e256ce82e2db0144cb
Partial-Bug: #1382189
oslo.i18n provides the i18n function that were provided by
oslo-incubator's gettextutils module
Import _ where needed, oslo.i18n deprecated the builtin method.
Closes-Bug: #1382187
Change-Id: I12aa1c725aa4bb52a9aa46e9c3d2b303839de48b
LOG.xxx("Hello %s" % xyz) should be LOG.xxx("Hello %s", xyz).
This allows the logging package to skip creating the
formatted log message if the message is not going to be emitted because
of the current log level.
The change touches error, warning and info LOG messages.
Adjust test suite for the above change since LOG now uses two parameters
instead of one.
Fix grammar, add missing "." to log messages in some places.
Change-Id: I86404c34502f07ed6dbda1c82b13db888c60f074
Make help strings consistent:
* Add missing spaces between words
* Capitalize first word of help
* Add "." at end of string
* Improve wording and capitalization
This follows the oslo.config style guide:
http://docs.openstack.org/developer/oslo.config/styleguide.html
Change-Id: I8243909249423b6b58ccda0d800856f46b0953c5
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