Split storage actions, computing and networking
For the moment Manila has different share drivers that implement storage activities, computing and networking all in one module using only neutron network plugin in some cases.
We should split it to logical parts:
1) share driver (storage activities)
2) compute helper (share server supply)
3) networking helper (network related logic)
as interfaces that should be implemented.
Details:
(1) share driver will implement all main interfaces:
- create/delete share f/wo snapshot
- create/delete snapshot
- allow/deny access
For getting share server it will use one of provided "compute helpers".
(2) compute helper will implement interfaces of share server creation and deletion. It will use "networking helper"
Possible implementation:
- Nova and VMs
- Ironic and hardware hosts
- storage-based (vservers in NetApp cDOT, etc...)
(3) networking helper will handle all network-related stuff, like:
- no network creation, no share server creation, usage of predefined share server (analog of so called single-tenancy)
- no network creation, share server creation with address from predefined network (combination of single and multi tenancy)
- creation of network (using either neutron or no-network), creation of share server (analog of so called multi-tenancy)
See pic with share driver - compute helper cooperation:
https:/
For more details see following wiki page:
https:/
Blueprint information
- Status:
- Complete
- Approver:
- Ben Swartzlander
- Priority:
- Undefined
- Drafter:
- Valeriy Ponomaryov
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- Obsolete
- Series goal:
- Proposed for kilo
- Implementation:
-
Not started
- Milestone target:
- None
- Started by
- Completed by
- Valeriy Ponomaryov
Related branches
Related bugs
Sprints
Whiteboard
Wiki page: https:/
Draft of work items (vponomaryov):
Interfaces
1) Create interface of compute helper: TODO
2) Create interface of networking helper: TODO
Implementations
3) Implement Nova compute helper (part of existing "service_instance" module): TODO
4) Implement Ironic/hardware compute helper: TODO
5) Split cDOT computing to separate module as its additional "compute helper": TODO
Other TBD
6) use compute helpers within GlusterFS: TODO
...
!!!!!!!!!!!!!!!!!!
THIS BP won't be implemented, because main idea will duplicate functionality of Cinder and it is contrary to requirements for OpenStack projects.
So, if someone wants to use Nova VMs for share provisioning, he should use generic driver for it and enable appropriate driver in Cinder.
Ironic share servers can be developed separately as part of generic driver.
