Split storage actions, computing and networking
This page describes changes to concept of share provisioning, interfaces changes and required implementations.
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.
(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"
- 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://docs.google.com/drawings/d/1qUCBzIBnxDSJElWHydLlMIQAZznJttrYjr0thP1O-N4/edit?usp=sharing
Create "ShareManagerV2" in parallel to "ShareManager", then remove usage of "ShareManager", then remove "ShareManager" at all and rename "ShareManagerV2" to "ShareManager".
Interfaces: Will be the same, except following: "setup_server" and "teardown_server" will be changed to use compute helpers
a) get_share_server(self, context, share_network_id) -- share server either will be created or reused existed one based on share network. -- security services will be taken from DB using "share_network_id" if some exist -- should return id of share server either explicitly or as exception object attribute
b) delete_share_server(self, context, share_server) -- delete share server and release all allocated resources
Share Servers will be used by share manager and share drivers.
Share Network Model should be extended with following new options:
1) --nova-network-id will be used for getting all required info from nova-network. It is mutually exclusive with following options and existing neutron options.
2) --flat-network-ip-pool it will expect CIDR , list of CIDRs , list of IPS, list of CIDRs and IPs as values to be used for IP provisioning. It is mutually exclusive with following and above options and existing neutron options.
3) --dhcp-endpoint it wil be used to get IP address from. It is mutually exclusive with above options and existing neutron options.
Network helper will have defined three plugins for each of modes, here is description how it takes decision what should be used:
flat_network: --dhcp-endpoint --flat-network-ip-pool
neutron_network: --neutron-net-id --neutron-subnet-id
It should not be allowed to set up contradictive options to share-network.
a) allocate_network(self, context, share_server, share_network, amount_of_ports, **kwargs) will get network data from share network, then will allocate required net resources for share server.
b) deallocate_network(self, context, share_server) will read all allocated network data for share server and release it.
Modules will be stored as following:
- manila/share/drivers/generic.py - manila/share/drivers/netapp/cluster_mode.py - manila/share/drivers/emc/driver.py - manila/share/drivers/ibm/gpfs.py - manila/share/drivers/glusterfs.py
- manila/share/compute_helpers/nova.py - manila/share/compute_helpers/ironic.py - manila/share/compute_helpers/netapp.py - manila/share/compute_helpers/emc.py
- manila/share/network_helpers/flat_network.py - manila/share/network_helpers/nova_network.py - manila/share/network_helpers/neutron.py