Join a tenant's network
Manila needs to have a way for tenants/users to provide the needed details to create a storage server that integrates with the tenant network and its security services.
Assumptions:
1) Tenants may have more than 1 security domain each
2) Each security domain is specific to one tenant -- there can be no sharing of filesystems across tenants unless the tenants share significant infrastructure between them
3) The server(s) providing the storage may have multiple network interfaces connected to multiple physical switch ports.
I propose that we add a new API called "setup-network" (name subject to change) which does the following:
Inputs:
* Network protocol (nfs, cifs, other)
* Security params relevant to the protocol
* NFS: DNS IP, Kerberos Server, LDAP Server, Kerberos domain, LDAP domain, Kerberos account, Kerberos password
* CIFS: DNS IP, AD Server, AD Domain, Admin account, Admin password
Outputs:
* UUID identifying the created network
Errors:
* Invalid network protocol
* Missing required security params
Description:
This API creates a row in a database table to store the details the tenant passed in. The row is assigned a new UUID which is returned to the caller. The row stores the tenant's ID as well as the inputs supplied. TBD: should we create the "virtual server" immediately so that we can check the validity of the supplied security parameters or just save them so we can create the virtual server just in time?
We would also change the share-create API to require that the client passes in the UUID of a previously created network, and the share would only be accessible to members of that tenant network from then on. Whether we create virtual servers immediately when the "network-setup" APIs is called or not, it's still possible that the share-create API would need to create an additional virtual server in situations where space runs out on all previously created virtual servers. This will add additional failure modes to the share-create API and increase the complexity of that API.
The process of actually creating a "virtual server" will need to involve the following steps:
1) The manila backend decides how many IPs it wants. This could be 1 for a simple virtual server or possibly 8 or more for a storage cluster.
2) Manila asks neutron to provide the IPs on the tenant network using the stored tenant ID.
3) Neutron returns the IPs, along with netmask, gateway IP, and VLAN number to manila.
4) The manila backend creates "virtual NICs" using the given IPs and returns the MAC addresses of the VLAN trunk interfaces.
5) Manila asks neutron to connect the trunk interfaces to the tenant network by supplying the MAC addresses.
6) The manila backend configures the server for the appropriate storage protocol using the stored security params. Any connectivity problems will be detected at this point.
Most of the above changes can be implemented inside the drivers themselves with a significant amount of shared code between the drives (basically everything that talks to neutron).
Blueprint information
- Status:
- Complete
- Approver:
- Ben Swartzlander
- Priority:
- Essential
- Drafter:
- Ben Swartzlander
- Direction:
- Approved
- Assignee:
- None
- Definition:
- Review
- Series goal:
- Accepted for icehouse
- Implementation:
-
Implemented
- Milestone target:
- None
- Started by
- Ben Swartzlander
- Completed by
- Ben Swartzlander
Related branches
Related bugs
Sprints
Whiteboard
- Caitlin Bestler -
Specification of the "Security Parameters" should include an option to allow these to be determine "normally" within the context of a Tenant network.
A lot of existing customer networks rely on multicast addressing to find the DHCP server, and the DHCP server tells the nodes it is assigning IP addresses to where most of the rest of the infrastructure can be found (router, DNS, etc.)
When a tenant wants to control these via neutron, that is fine, probably even preferable. But we shouldn't force them to change how they operate "their network"" just because it is a virtual network
within a larger physical network.
-------
Gerrit topic: https:/
Addressed by: https:/
Network allocation in ShareManager
Addressed by: https:/
Added Neutron API module
Addressed by: https:/
Adds db support for managing subnet adding
Gerrit topic: https:/
Addressed by: https:/
Add neutron network plug-in and DB support
-------
+Caitlin Betler
User authentication is confined to the security domain. Credentials are offered, validated and checked within the security domain. This makes things very simple for the client. it is why this model is challenging for the servers.
Clarifiation is needed as to whether neutron needs to create a tenant network for each security domain, or whether other mechanisms could divide client machines into specific security domains within a tenant's vlan (for example, explicitly telling the server which security domain each client was in).
We should also be explicit that Security Doman X UID 500 is a different user than Security Domain Y UID 500, and that the backend storage needs to keep the two separate for all purposes including quotas and reporting.
Addressed by: https:/
Add policy DB models and API.
Addressed by: https:/
Add Manila API for policies
Addressed by: https:/
Adds network and policy management to share manager
Addressed by: https:/
Security service API
Addressed by: https:/
Add share's networks API
