Manila/SAP enterprise team
< Manila
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" | A | ? | 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 |