Jump to: navigation, search

Manila/SAP enterprise team

< Manila
Revision as of 17:42, 8 August 2016 by Bswartz (talk | contribs) (Lowering priority as #2 is not so important once we have #1)

Misson

The SAP Manila enterprise team tries to address topics to make Manila enterprise ready. The listed topics can be bugs, features or even long running tasks.

Open Topics:

No Issue Description Priority Assignee Reference Release
1 Snapshot: make it possible for users to specify "full copy clones" or "copy-on-write clones" In order to speed up the rollout the concept requires to 'clone a template' , where a template is a snapshot of a master volume and clone resolves into a snapshot (manila create --snapshot) A NetApp Newton
2 Snapshot: make it possible for users decouple the "copy-on-write clones" from it's source snapshot Shares based on Snapshots are bound to the source pool. Over the lifetime of a project the need may arise to migrate the shares to other backends. The first step towards this is to break the dependency from the source i.e. break the "copy-on-write-clones" C  ? Implementation of #'s 1, 5, & 6 may obviate this.
3 Manila-share active-active HA Manila service manila-share should be active-active HA. This means a backend should be managed by at least 2 services. A  ? https://specs.openstack.org/openstack/cinder-specs/specs/mitaka/ha-aa-tooz-locks.html
4 Migrate: a share within the same share server / share network With growing projects capacity as well as performance may require to move a share within the same share server / share network to a different pool. Migration should support this preferably as function within the backend specific driver to keep overhead to a minimum A NetApp Newton
5 Migrate: a share to a different share server In case the share servers capacity is at it'S limits, or the share network need to be changed (moving from a QA to a production network) it is required to allow the migration to a different share server/network. Optionally the scheduler may choose the target. If possible drivers can handle this migration B  ?
6 Migrate: a share to a different availability zone Move shares between Availability zones. Optionally the scheduler may choose the target. C  ?
7 Schedule: Use of virtual resources to schedule share creation Large enterprise applications do not only require capacity for shares but may also rely on other attributes such as I/O, network bandwidth, that define the limits for a certain resource-'pool'. Virtual resources could help to guide the scheduler to consume those virtual resources based on shared types and thus limit the creation of shares based on those limits. C  ?
8 Create --snapshot --schedule, create a clone via scheduler Creating a clone using a snapshot will allocate the share from the same pool/resource. Due to resource or other limitations this may require a later migration. Optimizing the creation process using the scheduler logic for selecting the target resource should combine all these steps within one, leaving - if possible - the hard work within the driver. C  ?
9 Specify NFS protocol Set active NFS protocol (for backend / share server) NFSV3 ,NFSV4.0, NFSV4.1 A NetApp Newton
10 MTU Size must be definable actual there is no way to define the MTU Size for the broadcast domain setup (NetApp driver) A SAP & NetApp https://bugs.launchpad.net/manila/+bug/1606190 Newton
11 Manila hierarchical port binding support Port binding with multi-segement support A SAP https://blueprints.launchpad.net/manila/+spec/manila-hpb-support Newton
12 allow more than one aggr with parameter "netapp_root_volume_aggregate" Current issue: In case of a node fail all SVM´s are affected and takeover/giveback will take long. B NetApp on-site -
13 Implement LS-Mirror for NFS-Versions lower than V4.1 In case NFS V4.1 is used, we do not need LS-mirror functionality but if we use a lower Version we have to have it and we have to take care about the changing configuration behavior within the driver scripts C NetApp on-site
14 NetApp: Extending the Cluster When extending a NetApp Cluster to add additional resources, already existing share servers should be able to consume these new resources. Meta-data should be extended B
15 API extension to list the extra specs Currently documentation is the only space to find available extra specs. API call listing all specs based on available / configured drivers would be a huge help for configuration B
16 Replication: between availability zones when using managed share servers Classical DR requirement C