This document outlines steps and notes for operators for reference when upgrading their Shared File System service (manila) from previous versions of OpenStack. The service aims to provide a minimal downtime upgrade experience. Since the service does not operate in the data plane, the accessibility of any provisioned resources such as shares, share snapshots, share groups, share replicas, share servers, security services and share networks will not be affected during an upgrade. Clients can continue to actively use these resources while the service control plane is being upgraded.
It is highly recommended that you:
manila-manage
command offers a database downgrade
command, it is not supported for production use. The only way to recover
from a failed update is to restore the database from a backup.Shared File System service components (scheduler, share-manager, data-manager) are python processes listening for messages on a AMQP queue. When the operator sends SIGTERM signal to the process, they stop getting new work from the queue, complete any outstanding work and then terminate.
The Shared File System service only supports cold upgrades, meaning that the
service plane is expected to be down during the database upgrade. Database
upgrades include schema changes as well as data migrations to accommodate
newer versions of the schema. Once upgraded, downgrading the database is not
supported. When the database has been upgraded, older services may misbehave
when accessing database objects, so ensure all manila-*
services are down
before you upgrade the database.
Shared File System service resources are soft deleted in the database, so users are able to track instances in the DB that are created and destroyed in production. Soft-deletion also helps cloud operators adhere to data retention policies. Not purging soft-deleted entries affects DB performance as indices grow very large and data migrations take longer as there is more data to migrate. It is recommended that you prune the service database before upgrading to prevent unnecessary data migrations. Pruning permanently deletes soft deleted database records.
manila-manage db purge <age_in_days>
manila-status upgrade check
command to validate that the service
is ready for upgrade.Note
The manila-data service may be processing time consuming data migrations.
Shutting it down will interrupt any ongoing migrations, and these will not
be automatically started when the service comes back up. You can check
the status on ongoing migrations with manila migration-get-progress
command; issue manila migration-complete
for any ongoing migrations
that have completed their data copy phase.
manila-manage db sync
from any node with the latest manila
packages.services
by running manila service-list
. If there are
any orphaned records, run manila-manage service cleanup
to delete them.The Shared File System service code is continually tested for upgrade from a previous release to the current release using Grenade. Grenade is an OpenStack test harness project that validates upgrade scenarios between releases. It uses DevStack to initially perform a base OpenStack install and then upgrade to a target version. Tests include the creation of a variety of Shared File System service resources on the prior release, and verification for their existence and functionality after the upgrade.
Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.