modified docs
This commit is contained in:
Yulia Portnova
parent
9169fc311e
commit
894157512d
|
|
@ -8,5 +8,5 @@ from manila import utils
|
|||
|
||||
def setup(app):
|
||||
print "**Autodocumenting from %s" % os.path.abspath(os.curdir)
|
||||
rv = utils.execute('./doc/generate_autodoc_index.sh')
|
||||
rv = utils.execute('./generate_autodoc_index.sh')
|
||||
print rv[0]
|
||||
|
|
@ -6,7 +6,7 @@ if [ ! -d ${SOURCEDIR} ] ; then
|
|||
mkdir -p ${SOURCEDIR}
|
||||
fi
|
||||
|
||||
for x in `./doc/find_autodoc_modules.sh`;
|
||||
for x in `./find_autodoc_modules.sh`;
|
||||
do
|
||||
echo "Generating ${SOURCEDIR}/${x}.rst"
|
||||
echo "${SOURCEDIR}/${x}.rst" >> .autogenerated
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@
|
|||
Manila System Architecture
|
||||
========================
|
||||
|
||||
The Manila Block Storage Service is intended to be ran on one or more nodes.
|
||||
The Manila Shared Filesystem Management Service is intended to be ran on one or more nodes.
|
||||
|
||||
Manila uses a sql-based central database that is shared by all Manila services in the system. The amount and depth of the data fits into a sql database quite well. For small deployments this seems like an optimal solution. For larger deployments, and especially if security is a concern, manila will be moving towards multiple data stores with some kind of aggregation system.
|
||||
|
||||
|
|
@ -34,11 +34,11 @@ Below you will a brief explanation of the different components.
|
|||
| \- ( DB )
|
||||
|
|
||||
|
|
||||
manilaclient |
|
||||
/ \ |
|
||||
[ Web Dashboard ]- -[ api ] -- < AMQP > -- [ scheduler ] -- [ volume ] -- ( iSCSI )
|
||||
\ / |
|
||||
novaclient |
|
||||
|
||||
|
|
||||
[ Web Dashboard ]- manilaclient -[ api ] -- < AMQP > -- [ scheduler ] -- [ share ] -- ( shared filesystem )
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
@ -50,4 +50,4 @@ Below you will a brief explanation of the different components.
|
|||
* api: component that receives http requests, converts commands and communicates with other components via the queue or http
|
||||
* Auth Manager: component responsible for users/projects/and roles. Can backend to DB or LDAP. This is not a separate binary, but rather a python class that is used by most components in the system.
|
||||
* scheduler: decides which host gets each volume
|
||||
* volume: manages dynamically attachable block devices.
|
||||
* share: manages shared filesystems.
|
||||
|
|
|
|||
|
|
@ -64,7 +64,7 @@ Module Reference
|
|||
|
||||
services
|
||||
database
|
||||
volume
|
||||
share
|
||||
auth
|
||||
api
|
||||
scheduler
|
||||
|
|
|
|||
|
|
@ -97,8 +97,8 @@ The figure below shows the status of a RabbitMQ node after Manila components' bo
|
|||
2. compute
|
||||
3. network.phantom (phantom is hostname)
|
||||
4. network
|
||||
5. volume.phantom (phantom is hostname)
|
||||
6. volume
|
||||
5. share.phantom (phantom is hostname)
|
||||
6. share
|
||||
7. scheduler.phantom (phantom is hostname)
|
||||
8. scheduler
|
||||
|
||||
|
|
|
|||
|
|
@ -15,25 +15,25 @@
|
|||
License for the specific language governing permissions and limitations
|
||||
under the License.
|
||||
|
||||
Storage Volumes, Disks
|
||||
Shared Filesystems
|
||||
======================
|
||||
|
||||
.. todo:: rework after iSCSI merge (see 'Old Docs') (todd or vish)
|
||||
.. todo:: rework
|
||||
|
||||
|
||||
The :mod:`manila.volume.manager` Module
|
||||
The :mod:`manila.share.manager` Module
|
||||
-------------------------------------
|
||||
|
||||
.. automodule:: manila.volume.manager
|
||||
.. automodule:: manila.share.manager
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
The :mod:`manila.volume.driver` Module
|
||||
The :mod:`manila.share.driver` Module
|
||||
-------------------------------------
|
||||
|
||||
.. automodule:: manila.volume.driver
|
||||
.. automodule:: manila.share.driver
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
|
|
@ -43,22 +43,15 @@ The :mod:`manila.volume.driver` Module
|
|||
Tests
|
||||
-----
|
||||
|
||||
The :mod:`volume_unittest` Module
|
||||
The :mod:`share_unittest` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: manila.tests.volume_unittest
|
||||
.. automodule:: manila.tests.share_unittest
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
Old Docs
|
||||
--------
|
||||
|
||||
Manila uses iSCSI to export storage volumes from multiple storage nodes. These iSCSI exports are attached (using libvirt) directly to running instances.
|
||||
|
||||
Manila volumes are exported over the primary system VLAN (usually VLAN 1), and not over individual VLANs.
|
||||
|
||||
The underlying volumes by default are LVM logical volumes, created on demand within a single large volume group.
|
||||
|
||||
|
||||
|
||||
Loading…
Reference in New Issue