There are three processes that make up the Manila service:
manila-api
is a WSGI application that accepts and validates REST (JSON) requests from clients and routes them to other Manila processes as appropriate over AMQP.manila-scheduler
determines which backend should serve as the destination for a share creation request. It maintains non-persistent state for pools and backends (e.g. available capacity, capabilities, and supported extra specs) that can be leveraged when making placement decisions. The algorithm utilized by the scheduler can be changed through Manila configuration.manila-share
accepts requests from other Manila processes and serves as the operational container for Manila drivers. This process is multi-threaded and typically has one thread of execution per Manila backend as defined in the Manila configuration file.
The following section walks through the steps that occur when a user requests the creation of a new share from Manila, and a backend is selected that uses share servers.
Client issues request to create share through invoking REST API (client may use
python-manilaclient
CLI utility).The
manila-api
andmanila-scheduler
processes perform the following tasks:manila-api
process validates request, user credentials; once validated, puts message onto AMQP queue for processing.manila-share
process takes message off of queue, sends message to manila-scheduler to determine which pool and backend to provision share into.manila-scheduler
process takes message off of queue, generates candidate list of resource pools based on current state and requested share criteria (size, availability zone, share type (including extra specs)).manila-share
process reads response message frommanila-scheduler
from queue; iterates through candidate list by invoking backend driver methods for corresponding pools until successful.
- The share manager associated with the backend selected by the
manila-scheduler
calls out to the network service associated with the backend (either the standalone plugin, Neutron, or Nova Network; defined through the appropriate stanza inmanila.conf
) to get the required information (including share IP address, network segmentation ID, etc.). - If selected by the scheduler, NetApp's Manila driver creates requested share (and, if necessary, a share server) through interactions with storage subsystem (dependent on configuration and protocol).
manila-share
process creates share metadata and posts response message to AMQP queue.manila-api
process reads response message from queue and responds to client with share ID information.- After a share is created and exported by the backend, client uses ID information to request updated share details and uses export information from response to mount share (using protocol-specific commands).
The following section walks through the steps that occur when a user requests the creation of a new share from Manila and a backend is selected that does not use share servers.
Client issues request to create share through invoking REST API (client may use
python-manilaclient
CLI utility).The
manila-api
andmanila-scheduler
processes perform the following tasks:manila-api
process validates request, user credentials; once validated, puts message onto AMQP queue for processing.manila-share
process takes message off of queue, sends message to manila-scheduler to determine which pool and backend to provision share into.manila-scheduler
process takes message off of queue, generates candidate list of resource pools based on current state and requested share criteria (size, availability zone, share type (including extra specs)).manila-share
process reads response message frommanila-scheduler
from queue; iterates through candidate list by invoking backend driver methods for corresponding pools until successful.
If selected by the scheduler, NetApp's Manila driver creates requested share through interactions with storage subsystem (dependent on configuration and protocol).
Without the existence of a share server, NetApp's Manila driver will export shares through the data LIFs that exist within the SVM that is scoped to the Manila backend.
manila-share
process creates share metadata and posts response message to AMQP queue.manila-api
process reads response message from queue and responds to client with share ID information.- After a share is created and exported by the backend, client uses ID information to request updated share details and uses export information from response to mount share (using protocol-specific commands).
The following section walks through the steps that are required in order for any client to access a shared filesystem.
- Client issues request to enable access to a share through invoking Manila REST API (client may use
python-manilaclient
CLI utility), specifying the type of access (eitherIP
oruser
) and the value (either IP address or IP network address in CIDR notation or user name in standard Windows notation). manila-api
process validates request, user credentials; once validated, posts message to share manager over AMQP.manila-share
reads message from queue, invokes Manila driver corresponding to share to be attached.- NetApp Manila driver creates appropriate export policies for the share and access type provided.
manila-share
process posts response information tomanila-api
process via AMQP queue.manila-api
process reads response message frommanila-share
from queue; passes connection information in RESTful response to caller.