openstack/manila
Code Issues Proposed changes

modified docs

Browse Source
This commit is contained in:
Yulia Portnova 2013-09-17 12:21:17 +03:00
parent 9169fc311e
commit 894157512d
9 changed files with 21 additions and 28 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
doc/ext/cinder_autodoc.py → doc/ext/manila_autodoc.py
View File

@ -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]

0
doc/ext/cinder_todo.py → doc/ext/manila_todo.py
View File

2
doc/generate_autodoc_index.sh
View File

@ -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

14
doc/source/devref/architecture.rst
View File

@ -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.

2
doc/source/devref/index.rst
View File

@ -64,7 +64,7 @@ Module Reference
services
database
volume
share
auth
api
scheduler

0
doc/source/devref/cinder.rst → doc/source/devref/manila.rst
View File

4
doc/source/devref/rpc.rst
View File

@ -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

25
doc/source/devref/volume.rst → doc/source/devref/share.rst
View File

@ -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.

0
doc/source/man/cinder-manage.rst → doc/source/man/manila-manage.rst
View File