OpenStack Manila Development Dynamic Series--austin summit

1 Manila Mitaka Version overview

At the Austin Summit, theManila Mitaka release driver number reached 18,

M version of the new 14 companies (Chinese companies after Huawei and 99cloud and other companies to join),

This release has completed 43 blueprints, the main blueprint for shared migration, the expansion API into the core,

Added functional testing,QoS support for public features, new data copy services,

Import and export snapshots, add CEPHFS Native driver, and more.

The historical version resolves the bug, the completed blueprint, and the number of commit codes as shown.

2 Manila Enterprise Applications

When it comes to enterprise applications, the low cost, heterogeneous infrastructure is the Manila advantage.

And fills the gap in the management of file sharing services in OpenStack. Several application cases are introduced:

For example, Manila and Docker provide file sharing management services for Docker.

The Manila feature integrates with Sahara to store work templates for Sahara with Manila sharing, and to write and write data in Sahara with file shares.

Sahara users can use the Sahara service to invoke the Manila API interface to complete the Automatic Mount NFS sharing feature.

Manila provides Distributed File System (HDFS) and so on.

Manila is fully supported in SuSE OpenStack Cloud 6,

And the functionality of the integrated Manila is demonstrated in SuSE OpenStack Cloud 6.

3 Manila Newton version planning

For the planning of the next Newton version of Manila, it mainly includes adding snapshot-related features,

Support Share servers replication, improve share migration,

Universal groups Replace consistency groups (compatible with replication groups, migration groups, CGs), container drivers, active-active ha, and so on.

Detailed information is as follows:

1) Manila added 2 snapshot features: One is the new automatic mount read-only snapshot feature for fast recovery of minor changes, such as recovering a file in a share.

In order to avoid conflicts between snapshots and the parent shared access rights of the snapshot,

Added a set of API control snapshot permissions like the share ACL, which allows you to set access permissions separately for the snapshot.

The other is the new snapshot rollback feature for fast recovery of the source share,

Some back ends that do not support creating shares from snapshots (create share from snapshot) can be replaced with this feature.

Snapshots that are rolled back from the snapshot point of time must be deleted because the back-end array implements snapshot rollback. Therefore, temporarily support snapshots that allow rollback to the nearest point in time.

2) added the Per-share-type quotas function, that is, each share type can be configured share capacity, the number of quota information.

This is a feature that is proposed by the operator to control costs by share capacity restrictions on the configuration of the share type quota.

3) Remind each driver to replace the original allow_access, deny_access interface with the update access interface.

So that the ACLs are batched atomic operations in Manila.

4) in order to resolve active-active HA applications, API request contention (i.e., when there is no concurrency control at the database level, managed resources may be modified by different APIs),

A distributed Lock (Zool) is introduced to solve the problem of Manila operation conflicts among various services. Distributed locks are also introduced in Cinder, which is currently in the Code review phase.

5) Manila Add version object, the SQLAlchemy objects currently in use is abstracted into Manila objects,

Use object code and actual database schema to isolate, easier to roll the upgrade and so on.

6) plan to implement the Share Type Update feature (retype).

Manila Retype meaning is an update to the shared type (share type).

For example, the conversion of the shared type of Huawei storage from thin to thick,

If different backend operations are involved, such as from Huawei to Ceph,

The retype feature invokes the migration feature to automatically migrate the source share to a new share created on the eligible backend.

7) The Data Service Helper provides the driver with the standardized operations related to

such as share data copy (create share from snapshot),

Gets the data copy progress, cancels the copy of the data, the callback function specified by driver, and so on.

8) in order to resolve the Manila in the consistency group (consistency groups), replication, migration features may exist on the share group operations,

But the concept of the share group between different characteristics how to fuse the problem.

In practice, for example, we have replication consistency groups, snapshot replication groups, migrating a replication group,

Back up a consistency group, backup a replication group. Communities want to consolidate these groups through a unified API and the smallest possible change in the user experience.

Therefore, the universal group concept is introduced to solve this problem, and unlike the consistency group, it is not necessary to guarantee any specialized operation of the share group.

Of course, the feature-rich backend wants to add its own secret weapon, whether it's CGS, group-based replication, or anything else that might be easier.

Finally, due to the timing of the Austin Summit, the issue of Manila was not discussed, so please follow the related series.

Editor's note: This article comes from OpenStack Open Source Team engineer Zhongjun

OpenStack Manila Development Dynamic Series--austin summit