There are three processes that make up the Manila service:
manila-apiis a WSGI application that accepts and validates REST (JSON) requests from clients and routes them to other Manila processes as appropriate over AMQP.manila-schedulerdetermines 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-shareaccepts 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-manilaclientCLI utility).The
manila-apiandmanila-schedulerprocesses perform the following tasks:manila-apiprocess validates request, user credentials; once validated, puts message onto AMQP queue for processing.manila-shareprocess takes message off of queue, sends message to manila-scheduler to determine which pool and backend to provision share into.manila-schedulerprocess 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-shareprocess reads response message frommanila-schedulerfrom 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-schedulercalls 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-shareprocess creates share metadata and posts response message to AMQP queue.manila-apiprocess 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-manilaclientCLI utility).The
manila-apiandmanila-schedulerprocesses perform the following tasks:manila-apiprocess validates request, user credentials; once validated, puts message onto AMQP queue for processing.manila-shareprocess takes message off of queue, sends message to manila-scheduler to determine which pool and backend to provision share into.manila-schedulerprocess 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-shareprocess reads response message frommanila-schedulerfrom 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-shareprocess creates share metadata and posts response message to AMQP queue.manila-apiprocess 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-manilaclientCLI utility), specifying the type of access (eitherIPoruser) and the value (either IP address or IP network address in CIDR notation or user name in standard Windows notation). manila-apiprocess validates request, user credentials; once validated, posts message to share manager over AMQP.manila-sharereads 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-shareprocess posts response information tomanila-apiprocess via AMQP queue.manila-apiprocess reads response message frommanila-sharefrom queue; passes connection information in RESTful response to caller.
