From 08612d7524dad75c651d25b6945abd8f6b607817 Mon Sep 17 00:00:00 2001 From: vponomaryov Date: Fri, 6 Jun 2014 19:30:04 +0300 Subject: [PATCH] Update manila's docs After manila's fork from cinder, its docs were not updated well. This info is used by doc-builder, see doc/README.rst Partially implements: blueprint manila-documentation Change-Id: Ic97584db291b60505d5d310a517c2866fc6fcf5f --- doc/ext/manila_autodoc.py | 8 +- doc/source/_theme/layout.html | 2 +- doc/source/devref/addmethod.openstackapi.rst | 10 +- doc/source/devref/api.rst | 129 ++-------- doc/source/devref/architecture.rst | 18 +- doc/source/devref/auth.rst | 220 ++---------------- doc/source/devref/database.rst | 8 +- doc/source/devref/development.environment.rst | 21 +- doc/source/devref/fakes.rst | 41 ++-- doc/source/devref/index.rst | 4 +- doc/source/devref/manila.rst | 144 +----------- doc/source/devref/rpc.rst | 4 +- doc/source/devref/scheduler.rst | 10 +- doc/source/devref/services.rst | 4 +- doc/source/devref/share.rst | 8 +- doc/source/index.rst | 4 +- doc/source/man/manila-manage.rst | 218 +++-------------- test-requirements.txt | 2 +- 18 files changed, 148 insertions(+), 707 deletions(-) diff --git a/doc/ext/manila_autodoc.py b/doc/ext/manila_autodoc.py index 9cec3ea5..d67f021d 100644 --- a/doc/ext/manila_autodoc.py +++ b/doc/ext/manila_autodoc.py @@ -1,3 +1,5 @@ +from __future__ import print_function + import gettext import os @@ -7,6 +9,6 @@ from manila import utils def setup(app): - print "**Autodocumenting from %s" % os.path.abspath(os.curdir) - rv = utils.execute('./generate_autodoc_index.sh') - print rv[0] + print("**Autodocumenting from %s" % os.path.abspath(os.curdir)) + rv = utils.execute('./doc/generate_autodoc_index.sh') + print(rv[0]) diff --git a/doc/source/_theme/layout.html b/doc/source/_theme/layout.html index f5b388c8..e7c5fe2f 100644 --- a/doc/source/_theme/layout.html +++ b/doc/source/_theme/layout.html @@ -73,7 +73,7 @@

- Psst... hey. You're reading the latest content, but it's for the Block Storage project only. You can read all OpenStack docs too. + Psst... hey. You're reading the latest content, but it's for the Shared Filesystems project only. You can read all OpenStack docs too.

{%- endif %} diff --git a/doc/source/devref/addmethod.openstackapi.rst b/doc/source/devref/addmethod.openstackapi.rst index bef0e56f..fa47f56f 100644 --- a/doc/source/devref/addmethod.openstackapi.rst +++ b/doc/source/devref/addmethod.openstackapi.rst @@ -24,7 +24,7 @@ Routing To map URLs to controllers+actions, OpenStack uses the Routes package, a clone of Rails routes for Python implementations. See http://routes.groovie.org/ for more information. -URLs are mapped to "action" methods on "controller" classes in ``manila/api/openstack/__init__/ApiRouter.__init__`` . +URLs are mapped to "action" methods on "controller" classes in ``manila/api/v1/router.py``. See http://routes.groovie.org/manual.html for all syntax, but you'll probably just need these two: - mapper.connect() lets you map a single URL to a single action on a controller. @@ -33,9 +33,9 @@ See http://routes.groovie.org/manual.html for all syntax, but you'll probably ju Controllers and actions ----------------------- -Controllers live in ``manila/api/openstack``, and inherit from manila.wsgi.Controller. +Controllers live in ``manila/api/v1`` and ``manila/api/contrib``. -See ``manila/api/openstack/servers.py`` for an example. +See ``manila/api/v1/shares.py`` for an example. Action methods take parameters that are sucked out of the URL by mapper.connect() or .resource(). The first two parameters are self and the WebOb request, from which you can get the req.environ, req.body, req.headers, etc. @@ -44,9 +44,9 @@ Serialization Actions return a dictionary, and wsgi.Controller serializes that to JSON or XML based on the request's content-type. -If you define a new controller, you'll need to define a ``_serialization_metadata`` attribute on the class, to tell wsgi.Controller how to convert your dictionary to XML. It needs to know the singular form of any list tag (e.g. ```` list contains ```` tags) and which dictionary keys are to be XML attributes as opposed to subtags (e.g. ```` instead of ``4``). +If you define a new controller, you'll need to define a ``_serialization_metadata`` attribute on the class, to tell wsgi.Controller how to convert your dictionary to XML. It needs to know the singular form of any list tag (e.g. ```` list contains ```` tags) and which dictionary keys are to be XML attributes as opposed to subtags (e.g. ```` instead of ``4``). -See `manila/api/openstack/servers.py` for an example. +See `manila/api/v1/shares.py` for an example. Faults ------ diff --git a/doc/source/devref/api.rst b/doc/source/devref/api.rst index c8f84155..d51b6450 100644 --- a/doc/source/devref/api.rst +++ b/doc/source/devref/api.rst @@ -19,148 +19,57 @@ API Endpoint ============ Manila has a system for managing multiple APIs on different subdomains. -Currently there is support for the OpenStack API, as well as the Amazon EC2 -API. +Currently there is support for the OpenStack API. Common Components ----------------- The :mod:`manila.api` Module -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .. automodule:: manila.api :noindex: :members: :undoc-members: :show-inheritance: -The :mod:`manila.api.cloud` Module -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -.. automodule:: manila.api.cloud +The :mod:`manila.api.v1` Module +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +.. automodule:: manila.api :noindex: :members: :undoc-members: :show-inheritance: + +The :mod:`manila.api.contrib` Module +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +.. automodule:: manila.api + :noindex: + :members: + :undoc-members: + :show-inheritance: + + OpenStack API ------------- The :mod:`openstack` Module -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~~~~~ .. automodule:: manila.api.openstack :noindex: :members: :undoc-members: :show-inheritance: -The :mod:`auth` Module -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -.. automodule:: manila.api.openstack.auth - :noindex: - :members: - :undoc-members: - :show-inheritance: - -EC2 API -------- - -The :mod:`manila.api.ec2` Module -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -.. automodule:: manila.api.ec2 - :noindex: - :members: - :undoc-members: - :show-inheritance: - -The :mod:`cloud` Module -~~~~~~~~~~~~~~~~~~~~~~~ - -.. automodule:: manila.api.ec2.cloud - :noindex: - :members: - :undoc-members: - :show-inheritance: - -The :mod:`metadatarequesthandler` Module -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -.. automodule:: manila.api.ec2.metadatarequesthandler - :noindex: - :members: - :undoc-members: - :show-inheritance: Tests ----- -The :mod:`api_unittest` Module -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +The :mod:`api` Module +~~~~~~~~~~~~~~~~~~~~~ -.. automodule:: manila.tests.api_unittest - :noindex: - :members: - :undoc-members: - :show-inheritance: - -The :mod:`api_integration` Module -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -.. automodule:: manila.tests.api_integration - :noindex: - :members: - :undoc-members: - :show-inheritance: - -The :mod:`cloud_unittest` Module -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -.. automodule:: manila.tests.cloud_unittest - :noindex: - :members: - :undoc-members: - :show-inheritance: - -The :mod:`api.fakes` Module -~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -.. automodule:: manila.tests.api.fakes - :noindex: - :members: - :undoc-members: - :show-inheritance: - -The :mod:`api.test_wsgi` Module -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -.. automodule:: manila.tests.api.test_wsgi - :noindex: - :members: - :undoc-members: - :show-inheritance: - -The :mod:`test_api` Module -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -.. automodule:: manila.tests.api.openstack.test_api - :noindex: - :members: - :undoc-members: - :show-inheritance: - -The :mod:`test_auth` Module -~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -.. automodule:: manila.tests.api.openstack.test_auth - :noindex: - :members: - :undoc-members: - :show-inheritance: - -The :mod:`test_faults` Module -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -.. automodule:: manila.tests.api.openstack.test_faults +.. automodule:: manila.tests.api :noindex: :members: :undoc-members: diff --git a/doc/source/devref/architecture.rst b/doc/source/devref/architecture.rst index d7f50618..4f8be287 100644 --- a/doc/source/devref/architecture.rst +++ b/doc/source/devref/architecture.rst @@ -1,6 +1,7 @@ .. Copyright 2010-2011 United States Government as represented by the Administrator of the National Aeronautics and Space Administration. + Copyright 2014 Mirantis, Inc. All Rights Reserved. Licensed under the Apache License, Version 2.0 (the "License"); you may @@ -16,11 +17,11 @@ under the License. Manila System Architecture -======================== +========================== 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. +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. Components ---------- @@ -46,8 +47,17 @@ Below you will a brief explanation of the different components. * DB: sql database for data storage. Used by all components (LINKS NOT SHOWN) -* Web Dashboard: potential external component that talks to the api +* Web Dashboard: external component that talks to the api. Beta extended Horizon available here: https://github.com/NetApp/horizon/tree/manila * 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 +* scheduler: decides which host will handle create share request. * share: manages shared filesystems. + +Further Challenges +------------------ + +* More efficient share/snapshot size calculation +* Integration with Nova for share automounts +* Non-vlan multitenancy +* Gateway mediated networking model with NFS-Ganesha +* Add support for bigger amount of backends diff --git a/doc/source/devref/auth.rst b/doc/source/devref/auth.rst index 2317a183..3432ff98 100644 --- a/doc/source/devref/auth.rst +++ b/doc/source/devref/auth.rst @@ -1,6 +1,7 @@ .. Copyright 2010-2011 United States Government as represented by the Administrator of the National Aeronautics and Space Administration. + Copyright 2014 Mirantis, Inc. All Rights Reserved. Licensed under the Apache License, Version 2.0 (the "License"); you may @@ -21,7 +22,7 @@ Authentication and Authorization ================================ The :mod:`manila.quota` Module ----------------------------- +------------------------------ .. automodule:: manila.quota :noindex: @@ -29,24 +30,10 @@ The :mod:`manila.quota` Module :undoc-members: :show-inheritance: +The :mod:`manila.policy` Module +------------------------------ -The :mod:`manila.auth.signer` Module -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -.. automodule:: manila.auth.signer - :noindex: - :members: - :undoc-members: - :show-inheritance: - - -Auth Manager ------------- - -The :mod:`manila.auth.manager` Module -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -.. automodule:: manila.auth.manager +.. automodule:: manila.policy :noindex: :members: :undoc-members: @@ -56,182 +43,23 @@ The :mod:`manila.auth.manager` Module Tests ----- - -The :mod:`auth_unittest` Module -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -.. automodule:: manila.tests.auth_unittest - :noindex: - :members: - :undoc-members: - :show-inheritance: - - -The :mod:`access_unittest` Module -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -.. automodule:: manila.tests.access_unittest - :noindex: - :members: - :undoc-members: - :show-inheritance: - - -The :mod:`quota_unittest` Module +The :mod:`test_quota` Module ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -.. automodule:: manila.tests.quota_unittest +.. automodule:: manila.tests.test_quota :noindex: :members: :undoc-members: :show-inheritance: +The :mod:`test_policy` Module +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Legacy Docs ------------ - -Manila provides RBAC (Role-based access control) of the AWS-type APIs. We define the following roles: - -Roles-Based Access Control of AWS-style APIs using SAML Assertions -“Achieving FIPS 199 Moderate certification of a hybrid cloud environment using CloudAudit and declarative C.I.A. classifications” - - -Introduction ------------- - -We will investigate one method for integrating an AWS-style API with US eAuthentication-compatible federated authentication systems, to achieve access controls and limits based on traditional operational roles. -Additionally, we will look at how combining this approach, with an implementation of the CloudAudit APIs, will allow us to achieve a certification under FIPS 199 Moderate classification for a hybrid cloud environment. - - -Relationship of US eAuth to RBAC --------------------------------- - -Typical implementations of US eAuth authentication systems are structured as follows:: - - [ MS Active Directory or other federated LDAP user store ] - --> backends to… - [ SUN Identity Manager or other SAML Policy Controller ] - --> maps URLs to groups… - [ Apache Policy Agent in front of eAuth-secured Web Application ] - -In more ideal implementations, the remainder of the application-specific account information is stored either in extended schema on the LDAP server itself, via the use of a translucent LDAP proxy, or in an independent datastore keyed off of the UID provided via SAML assertion. - -.. _auth_roles: - - -Roles ------ - -AWS API calls are traditionally secured via Access and Secret Keys, which are used to sign API calls, along with traditional timestamps to prevent replay attacks. The APIs can be logically grouped into sets that align with five typical roles: - -* Base User -* System Administrator/Developer (currently have the same permissions) -* Network Administrator -* Project Manager -* Cloud Administrator/IT-Security (currently have the same permissions) - -There is an additional, conceptual end-user that may or may not have API access: - -* (EXTERNAL) End-user / Third-party User - -Basic operations are available to any : - -* Describe Instances -* Describe Images -* Describe Volumes -* Describe Keypairs -* Create Keypair -* Delete Keypair -* Create, Upload, Delete: Buckets and Keys (Object Store) - -System Administrators/Developers/Project Manager: - -* Create, Attach, Delete Volume (Block Store) -* Launch, Reboot, Terminate Instance -* Register/Unregister Machine Image (project-wide) -* Request / Review CloudAudit Scans - -Project Manager: - -* Add and remove other users (currently no api) -* Set roles (currently no api) - -Network Administrator: - -* Change Machine Image properties (public / private) -* Change Firewall Rules, define Security Groups -* Allocate, Associate, Deassociate Public IP addresses - -Cloud Administrator/IT-Security: - -* All permissions - - -Enhancements ------------- - -* SAML Token passing -* REST interfaces -* SOAP interfaces - -Wrapping the SAML token into the API calls. -Then store the UID (fetched via backchannel) into the instance metadata, providing end-to-end auditability of ownership and responsibility, without PII. - - -CloudAudit APIs ---------------- - -* Request formats -* Response formats -* Stateless asynchronous queries - -CloudAudit queries may spawn long-running processes (similar to launching instances, etc.) They need to return a ReservationId in the same fashion, which can be returned in further queries for updates. -RBAC of CloudAudit API calls is critical, since detailed system information is a system vulnerability. - - -Type declarations ------------------ -* Data declarations – Volumes and Objects -* System declarations – Instances - -Existing API calls to launch instances specific a single, combined “type” flag. We propose to extend this with three additional type declarations, mapping to the “Confidentiality, Integrity, Availability” classifications of FIPS 199. An example API call would look like:: - - RunInstances type=m1.large number=1 secgroup=default key=mykey confidentiality=low integrity=low availability=low - -These additional parameters would also apply to creation of block storage volumes (along with the existing parameter of ‘size’), and creation of object storage ‘buckets’. (C.I.A. classifications on a bucket would be inherited by the keys within this bucket.) - - -Request Brokering ------------------ - -* Cloud Interop -* IMF Registration / PubSub -* Digital C&A - -Establishing declarative semantics for individual API calls will allow the cloud environment to seamlessly proxy these API calls to external, third-party vendors – when the requested CIA levels match. - -See related work within the Infrastructure 2.0 working group for more information on how the IMF Metadata specification could be utilized to manage registration of these vendors and their C&A credentials. - - -Dirty Cloud – Hybrid Data Centers ---------------------------------- - -* CloudAudit bridge interfaces -* Anything in the ARP table - -A hybrid cloud environment provides dedicated, potentially co-located physical hardware with a network interconnect to the project or users’ cloud virtual network. - -This interconnect is typically a bridged VPN connection. Any machines that can be bridged into a hybrid environment in this fashion (at Layer 2) must implement a minimum version of the CloudAudit spec, such that they can be queried to provide a complete picture of the IT-sec runtime environment. - -Network discovery protocols (ARP, CDP) can be applied in this case, and existing protocols (SNMP location data, DNS LOC records) overloaded to provide CloudAudit information. - - -The Details ------------ - -* Preliminary Roles Definitions -* Categorization of available API calls -* SAML assertion vocabulary +.. automodule:: manila.tests.test_policy + :noindex: + :members: + :undoc-members: + :show-inheritance: System limits @@ -239,19 +67,7 @@ System limits The following limits need to be defined and enforced: -* Total number of instances allowed (user / project) -* Total number of instances, per instance type (user / project) -* Total number of volumes (user / project) -* Maximum size of volume -* Cumulative size of all volumes -* Total use of object storage (GB) -* Total number of Public IPs - - -Further Challenges ------------------- - -* Prioritization of users / jobs in shared computing environments -* Incident response planning -* Limit launch of instances to specific security groups based on AMI -* Store AMIs in LDAP for added property control +* Maximum cumulative size of shares and snapshots (GB) +* Total number of shares +* Total number of snapshots +* Total number of share networks diff --git a/doc/source/devref/database.rst b/doc/source/devref/database.rst index dc2aa24a..c871d19e 100644 --- a/doc/source/devref/database.rst +++ b/doc/source/devref/database.rst @@ -19,7 +19,7 @@ The Database Layer ================== The :mod:`manila.db.api` Module ------------------------------ +------------------------------- .. automodule:: manila.db.api :noindex: @@ -32,13 +32,13 @@ The Sqlalchemy Driver --------------------- The :mod:`manila.db.sqlalchemy.api` Module -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .. automodule:: manila.db.sqlalchemy.api :noindex: The :mod:`manila.db.sqlalchemy.models` Module -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .. automodule:: manila.db.sqlalchemy.models :noindex: @@ -47,7 +47,7 @@ The :mod:`manila.db.sqlalchemy.models` Module :show-inheritance: The :mod:`manila.db.sqlalchemy.session` Module -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .. automodule:: manila.db.sqlalchemy.session :noindex: diff --git a/doc/source/devref/development.environment.rst b/doc/source/devref/development.environment.rst index 6632c2f3..0862ae75 100644 --- a/doc/source/devref/development.environment.rst +++ b/doc/source/devref/development.environment.rst @@ -19,21 +19,18 @@ Setting Up a Development Environment ==================================== This page describes how to setup a working Python development -environment that can be used in developing manila on Ubuntu, Fedora or +environment that can be used in developing Manila on Ubuntu, Fedora or Mac OS X. These instructions assume you're already familiar with git. Refer to GettingTheCode_ for additional information. .. _GettingTheCode: http://wiki.openstack.org/GettingTheCode -Following these instructions will allow you to run the manila unit -tests. If you want to be able to run manila (i.e., launch VM instances), -you will also need to install libvirt and at least one of the -`supported hypervisors`_. Running manila is currently only supported on -Linux, although you can run the unit tests on Mac OS X. See -:doc:`../quickstart` for how to get a working version of OpenStack -Compute running as quickly as possible. +Following these instructions will allow you to run the Manila unit +tests. If you want to be able to run Manila (i.e., create NFS/CIFS shares), +you will also need to install dependent projects: Nova, Neutron, Cinder and Glance. +For this purpose 'devstack' project can be used (A documented shell script to build complete OpenStack development environments). -.. _supported hypervisors: http://wiki.openstack.org/HypervisorSupportMatrix +.. _DeployOpenstack: http://devstack.org/ Virtual environments -------------------- @@ -41,7 +38,7 @@ Virtual environments Manila development uses `virtualenv `__ to track and manage Python dependencies while in development and testing. This allows you to install all of the Python package dependencies in a virtual -environment or "virtualenv" (a special subdirectory of your manila +environment or "virtualenv" (a special subdirectory of your Manila directory), instead of installing the packages at the system level. .. note:: @@ -85,14 +82,14 @@ MacPorts package for OpenSSL, you will see an error when running ``manila.tests.auth_unittest.AuthTestCase.test_209_can_generate_x509``. The stock version of OpenSSL that ships with Mac OS X 10.6 (OpenSSL 0.9.8l) -or Mac OS X 10.7 (OpenSSL 0.9.8r) works fine with manila. +or Mac OS X 10.7 (OpenSSL 0.9.8r) works fine with Manila. Getting the code ---------------- Grab the code from GitHub:: - git clone https://github.com/openstack/manila.git + git clone https://github.com/stackforge/manila.git cd manila diff --git a/doc/source/devref/fakes.rst b/doc/source/devref/fakes.rst index 706b9c61..5eb42789 100644 --- a/doc/source/devref/fakes.rst +++ b/doc/source/devref/fakes.rst @@ -24,62 +24,51 @@ When the real thing isn't available and you have some development to do these fake implementations of various drivers let you get on with your day. -The :mod:`manila.virt.fake` Module --------------------------------- +The :mod:`fake_compute` Module +------------------------------ -.. automodule:: manila.virt.fake +.. automodule:: manila.tests.fake_compute :noindex: :members: :undoc-members: :show-inheritance: -The :mod:`manila.auth.fakeldap` Module ------------------------------------- +The :mod:`fake_driver` Module +----------------------------- -.. automodule:: manila.auth.fakeldap +.. automodule:: manila.tests.fake_driver :noindex: :members: :undoc-members: :show-inheritance: -The :mod:`manila.testing.fake.rabbit` Module ------------------------------------------- +The :mod:`fake_network` Module +------------------------------ -.. automodule:: manila.testing.fake.rabbit +.. automodule:: manila.tests.fake_service_instance :noindex: :members: :undoc-members: :show-inheritance: -The :class:`manila.volume.driver.FakeAOEDriver` Class ---------------------------------------------------- +The :mod:`fake_utils` Module +---------------------------- -.. autoclass:: manila.volume.driver.FakeAOEDriver +.. automodule:: manila.tests.fake_utils :noindex: :members: :undoc-members: :show-inheritance: -The :class:`manila.tests.service_unittest.FakeManager` Class ----------------------------------------------------------- +The :mod:`fake_volume` Module +------------------------------ -.. autoclass:: manila.tests.service_unittest.FakeManager +.. automodule:: manila.tests.fake_volume :noindex: :members: :undoc-members: :show-inheritance: - - -The :mod:`manila.tests.api.openstack.fakes` Module ------------------------------------------------- - -.. automodule:: manila.tests.api.openstack.fakes - :noindex: - :members: - :undoc-members: - :show-inheritance: - diff --git a/doc/source/devref/index.rst b/doc/source/devref/index.rst index 265af191..8dd9480e 100644 --- a/doc/source/devref/index.rst +++ b/doc/source/devref/index.rst @@ -32,7 +32,7 @@ Programming HowTos and Tutorials Background Concepts for Manila ----------------------------- +------------------------------ .. toctree:: :maxdepth: 3 @@ -55,7 +55,7 @@ API Reference .. toctree:: :maxdepth: 3 - ../api/autoindex + api Module Reference ---------------- diff --git a/doc/source/devref/manila.rst b/doc/source/devref/manila.rst index 941b0bb4..c83ea514 100644 --- a/doc/source/devref/manila.rst +++ b/doc/source/devref/manila.rst @@ -22,18 +22,8 @@ Libraries common throughout Manila or just ones that haven't been categorized very well yet. -The :mod:`manila.adminclient` Module ----------------------------------- - -.. automodule:: manila.adminclient - :noindex: - :members: - :undoc-members: - :show-inheritance: - - The :mod:`manila.context` Module ------------------------------- +-------------------------------- .. automodule:: manila.context :noindex: @@ -43,7 +33,7 @@ The :mod:`manila.context` Module The :mod:`manila.exception` Module --------------------------------- +---------------------------------- .. automodule:: manila.exception :noindex: @@ -52,48 +42,8 @@ The :mod:`manila.exception` Module :show-inheritance: -The :mod:`manila.flags` Module ----------------------------- - -.. automodule:: manila.flags - :noindex: - :members: - :undoc-members: - :show-inheritance: - - -The :mod:`manila.process` Module ------------------------------- - -.. automodule:: manila.process - :noindex: - :members: - :undoc-members: - :show-inheritance: - - -The :mod:`manila.rpc` Module --------------------------- - -.. automodule:: manila.rpc - :noindex: - :members: - :undoc-members: - :show-inheritance: - - -The :mod:`manila.server` Module ------------------------------ - -.. automodule:: manila.server - :noindex: - :members: - :undoc-members: - :show-inheritance: - - The :mod:`manila.test` Module ---------------------------- +----------------------------- .. automodule:: manila.test :noindex: @@ -103,7 +53,7 @@ The :mod:`manila.test` Module The :mod:`manila.utils` Module ----------------------------- +------------------------------ .. automodule:: manila.utils :noindex: @@ -112,18 +62,8 @@ The :mod:`manila.utils` Module :show-inheritance: -The :mod:`manila.validate` Module -------------------------------- - -.. automodule:: manila.validate - :noindex: - :members: - :undoc-members: - :show-inheritance: - - The :mod:`manila.wsgi` Module ---------------------------- +----------------------------- .. automodule:: manila.wsgi :noindex: @@ -135,80 +75,10 @@ The :mod:`manila.wsgi` Module Tests ----- -The :mod:`declare_conf` Module -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -.. automodule:: manila.tests.declare_conf - :noindex: - :members: - :undoc-members: - :show-inheritance: - - -The :mod:`conf_fixture` Module -~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -.. automodule:: manila.tests.conf_fixture - :noindex: - :members: - :undoc-members: - :show-inheritance: - - -The :mod:`flags_unittest` Module +The :mod:`test_exception` Module ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -.. automodule:: manila.tests.flags_unittest - :noindex: - :members: - :undoc-members: - :show-inheritance: - - -The :mod:`process_unittest` Module -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -.. automodule:: manila.tests.process_unittest - :noindex: - :members: - :undoc-members: - :show-inheritance: - - -The :mod:`real_flags` Module -~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -.. automodule:: manila.tests.real_flags - :noindex: - :members: - :undoc-members: - :show-inheritance: - - -The :mod:`rpc_unittest` Module -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -.. automodule:: manila.tests.rpc_unittest - :noindex: - :members: - :undoc-members: - :show-inheritance: - - -The :mod:`runtime_conf` Module -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -.. automodule:: manila.tests.runtime_conf - :noindex: - :members: - :undoc-members: - :show-inheritance: - - -The :mod:`validator_unittest` Module -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -.. automodule:: manila.tests.validator_unittest +.. automodule:: manila.tests.test_exception :noindex: :members: :undoc-members: diff --git a/doc/source/devref/rpc.rst b/doc/source/devref/rpc.rst index bf8d09b2..0ebb69b3 100644 --- a/doc/source/devref/rpc.rst +++ b/doc/source/devref/rpc.rst @@ -15,7 +15,7 @@ under the License. AMQP and Manila -============= +=============== AMQP is the messaging technology chosen by the OpenStack cloud. The AMQP broker, either RabbitMQ or Qpid, sits between any two Manila components and allows them to communicate in a loosely coupled fashion. More precisely, Manila components (the compute fabric of OpenStack) use Remote Procedure Calls (RPC hereinafter) to communicate to one another; however such a paradigm is built atop the publish/subscribe paradigm so that the following benefits can be achieved: @@ -33,7 +33,7 @@ Manila uses direct, fanout, and topic-based exchanges. The architecture looks li Manila implements RPC (both request+response, and one-way, respectively nicknamed 'rpc.call' and 'rpc.cast') over AMQP by providing an adapter class which take cares of marshaling and unmarshaling of messages into function calls. Each Manila service (for example Compute, Volume, etc.) create two queues at the initialization time, one which accepts messages with routing keys 'NODE-TYPE.NODE-ID' (for example compute.hostname) and another, which accepts messages with routing keys as generic 'NODE-TYPE' (for example compute). The former is used specifically when Manila-API needs to redirect commands to a specific node like 'euca-terminate instance'. In this case, only the compute node whose host's hypervisor is running the virtual machine can kill the instance. The API acts as a consumer when RPC calls are request/response, otherwise is acts as publisher only. Manila RPC Mappings ------------------ +------------------- The figure below shows the internals of a message broker node (referred to as a RabbitMQ node in the diagrams) when a single instance is deployed and shared in an OpenStack cloud. Every Manila component connects to the message broker and, depending on its personality (for example a compute node or a network node), may use the queue either as an Invoker (such as API or Scheduler) or a Worker (such as Compute, Volume or Network). Invokers and Workers do not actually exist in the Manila object model, but we are going to use them as an abstraction for sake of clarity. An Invoker is a component that sends messages in the queuing system via two operations: 1) rpc.call and ii) rpc.cast; a Worker is a component that receives messages from the queuing system and reply accordingly to rcp.call operations. diff --git a/doc/source/devref/scheduler.rst b/doc/source/devref/scheduler.rst index e269f65c..8298eade 100644 --- a/doc/source/devref/scheduler.rst +++ b/doc/source/devref/scheduler.rst @@ -19,7 +19,7 @@ Scheduler ========= The :mod:`manila.scheduler.manager` Module ----------------------------------------- +------------------------------------------ .. automodule:: manila.scheduler.manager :noindex: @@ -29,7 +29,7 @@ The :mod:`manila.scheduler.manager` Module The :mod:`manila.scheduler.driver` Module ---------------------------------------- +----------------------------------------- .. automodule:: manila.scheduler.driver :noindex: @@ -39,7 +39,7 @@ The :mod:`manila.scheduler.driver` Module The :mod:`manila.scheduler.simple` Driver ---------------------------------------- +----------------------------------------- .. automodule:: manila.scheduler.simple :noindex: @@ -51,10 +51,10 @@ The :mod:`manila.scheduler.simple` Driver Tests ----- -The :mod:`scheduler_unittest` Module +The :mod:`scheduler` Module ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -.. automodule:: manila.tests.scheduler_unittest +.. automodule:: manila.tests.scheduler :noindex: :members: :undoc-members: diff --git a/doc/source/devref/services.rst b/doc/source/devref/services.rst index da31cc11..5bb546e8 100644 --- a/doc/source/devref/services.rst +++ b/doc/source/devref/services.rst @@ -26,7 +26,7 @@ Currently, Managers and Drivers are specified by flags and loaded using utils.lo The :mod:`manila.service` Module ------------------------------- +-------------------------------- .. automodule:: manila.service :noindex: @@ -36,7 +36,7 @@ The :mod:`manila.service` Module The :mod:`manila.manager` Module ------------------------------- +-------------------------------- .. automodule:: manila.manager :noindex: diff --git a/doc/source/devref/share.rst b/doc/source/devref/share.rst index 43f85ab3..b0c3ba99 100644 --- a/doc/source/devref/share.rst +++ b/doc/source/devref/share.rst @@ -16,13 +16,13 @@ under the License. Shared Filesystems -====================== +================== .. todo:: rework The :mod:`manila.share.manager` Module -------------------------------------- +-------------------------------------- .. automodule:: manila.share.manager :noindex: @@ -43,10 +43,10 @@ The :mod:`manila.share.driver` Module Tests ----- -The :mod:`share_unittest` Module +The :mod:`test_share` Module ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -.. automodule:: manila.tests.share_unittest +.. automodule:: manila.tests.test_share :noindex: :members: :undoc-members: diff --git a/doc/source/index.rst b/doc/source/index.rst index 466e3ef4..16cb59ba 100644 --- a/doc/source/index.rst +++ b/doc/source/index.rst @@ -16,9 +16,9 @@ under the License. Welcome to Manila's developer documentation! -========================================== +============================================ -Manila is an OpenStack project to provide "block storage as a service". +Manila is an OpenStack project to provide "Shared Filesystems as a service". * **Component based architecture**: Quickly add new behaviors * **Highly available**: Scale to very serious workloads diff --git a/doc/source/man/manila-manage.rst b/doc/source/man/manila-manage.rst index cea722aa..4e00f7f1 100644 --- a/doc/source/man/manila-manage.rst +++ b/doc/source/man/manila-manage.rst @@ -1,17 +1,17 @@ -=========== +============= manila-manage -=========== +============= ------------------------------------------------------- -control and manage cloud computer instances and images ------------------------------------------------------- +------------------------------------- +control and manage shared filesystems +------------------------------------- :Author: openstack@lists.launchpad.net -:Date: 2012-04-05 +:Date: 2014-06-11 :Copyright: OpenStack LLC -:Version: 2012.1 +:Version: 2014.2 :Manual section: 1 -:Manual group: cloud computing +:Manual group: shared filesystems SYNOPSIS ======== @@ -21,7 +21,8 @@ SYNOPSIS DESCRIPTION =========== -manila-manage controls cloud computing instances by managing manila users, manila projects, manila roles, shell selection, vpn connections, and floating IP address configuration. More information about OpenStack Manila is at http://manila.openstack.org. +manila-manage controls shared filesystems service. +More information about OpenStack Manila is at https://wiki.openstack.org/wiki/Manila OPTIONS ======= @@ -29,21 +30,18 @@ OPTIONS The standard pattern for executing a manila-manage command is: ``manila-manage []`` -For example, to obtain a list of all projects: -``manila-manage project list`` +For example, to obtain a list of all hosts: +``manila-manage host list`` Run without arguments to see a list of available command categories: ``manila-manage`` -Categories are user, project, role, shell, vpn, and floating. Detailed descriptions are below. - -You can also run with a category argument such as user to see a list of all commands in that category: -``manila-manage user`` +Categories are shell, logs, service, db, host, version and config. Detailed descriptions are below. These sections describe the available categories and arguments for manila-manage. Manila Db -~~~~~~~ +~~~~~~~~~ ``manila-manage db version`` @@ -53,83 +51,8 @@ Manila Db Sync the database up to the most recent version. This is the standard way to create the db as well. -Manila User -~~~~~~~~~ - -``manila-manage user admin `` - - Create an admin user with the name . - -``manila-manage user create `` - - Create a normal user with the name . - -``manila-manage user delete `` - - Delete the user with the name . - -``manila-manage user exports `` - - Outputs a list of access key and secret keys for user to the screen - -``manila-manage user list`` - - Outputs a list of all the user names to the screen. - -``manila-manage user modify `` - - Updates the indicated user keys, indicating with T or F if the user is an admin user. Leave any argument blank if you do not want to update it. - -Manila Project -~~~~~~~~~~~~ - -``manila-manage project add `` - - Add a manila project with the name to the database. - -``manila-manage project create `` - - Create a new manila project with the name (you still need to do manila-manage project add to add it to the database). - -``manila-manage project delete `` - - Delete a manila project with the name . - -``manila-manage project environment `` - - Exports environment variables for the named project to a file named manilarc. - -``manila-manage project list`` - - Outputs a list of all the projects to the screen. - -``manila-manage project quota `` - - Outputs the size and specs of the project's instances including gigabytes, instances, floating IPs, volumes, and cores. - -``manila-manage project remove `` - - Deletes the project with the name . - -``manila-manage project zipfile`` - - Compresses all related files for a created project into a zip file manila.zip. - -Manila Role -~~~~~~~~~ - -``manila-manage role add <(optional) projectname>`` - - Add a user to either a global or project-based role with the indicated assigned to the named user. Role names can be one of the following five roles: cloudadmin, itsec, sysadmin, netadmin, developer. If you add the project name as the last argument then the role is assigned just for that project, otherwise the user is assigned the named role for all projects. - -``manila-manage role has `` - Checks the user or project and responds with True if the user has a global role with a particular project. - -``manila-manage role remove `` - Remove the indicated role from the user. - Manila Logs -~~~~~~~~~ +~~~~~~~~~~~ ``manila-manage logs errors`` @@ -140,7 +63,7 @@ Manila Logs Displays manila alerts from syslog. Manila Shell -~~~~~~~~~~ +~~~~~~~~~~~~ ``manila-manage shell bpython`` @@ -162,119 +85,44 @@ Manila Shell Runs the named script from the specified path with flags set. -Manila VPN -~~~~~~~~ - -``manila-manage vpn list`` - - Displays a list of projects, their IP prot numbers, and what state they're in. - -``manila-manage vpn run `` - - Starts the VPN for the named project. - -``manila-manage vpn spawn`` - - Runs all VPNs. - -Manila Floating IPs -~~~~~~~~~~~~~~~~~ - -``manila-manage floating create [--pool ] [--interface ]`` - - Creates floating IP addresses for the given range, optionally specifying - a floating pool and a network interface. - -``manila-manage floating delete `` - - Deletes floating IP addresses in the range given. - -``manila-manage floating list`` - - Displays a list of all floating IP addresses. - -Manila Flavor +Manila Host ~~~~~~~~~~~ -``manila-manage flavor list`` +``manila-manage host list`` - Outputs a list of all active flavors to the screen. + Returns list of running manila hosts. -``manila-manage flavor list --all`` +Manila Config +~~~~~~~~~~~~~ - Outputs a list of all flavors (active and inactive) to the screen. +``manila-manage config list`` -``manila-manage flavor create <(optional) swap> <(optional) RXTX Quota> <(optional) RXTX Cap>`` + Returns list of currently set config options and its values. - creates a flavor with the following positional arguments: - * memory (expressed in megabytes) - * vcpu(s) (integer) - * local storage (expressed in gigabytes) - * flavorid (unique integer) - * swap space (expressed in megabytes, defaults to zero, optional) - * RXTX quotas (expressed in gigabytes, defaults to zero, optional) - * RXTX cap (expressed in gigabytes, defaults to zero, optional) -``manila-manage flavor delete `` +Manila Service +~~~~~~~~~~~~~~ - Delete the flavor with the name . This marks the flavor as inactive and cannot be launched. However, the record stays in the database for archival and billing purposes. +``manila-manage service list`` -``manila-manage flavor delete --purge`` + Returns list of manila services. - Purges the flavor with the name . This removes this flavor from the database. +Manila Version +~~~~~~~~~~~~~~ -Manila Instance_type -~~~~~~~~~~~~~~~~~~ - -The instance_type command is provided as an alias for the flavor command. All the same subcommands and arguments from manila-manage flavor can be used. - -Manila Images -~~~~~~~~~~~ - -``manila-manage image image_register `` - - Registers an image with the image service. - -``manila-manage image kernel_register `` - - Registers a kernel with the image service. - -``manila-manage image ramdisk_register `` - - Registers a ramdisk with the image service. - -``manila-manage image all_register `` - - Registers an image kernel and ramdisk with the image service. - -``manila-manage image convert `` - - Converts all images in directory from the old (Bexar) format to the new format. - -Manila VM -~~~~~~~~~~~ - -``manila-manage vm list [host]`` - Show a list of all instances. Accepts optional hostname (to show only instances on specific host). - -``manila-manage live-migration `` - Live migrate instance from current host to destination host. Requires instance id (which comes from euca-describe-instance) and destination host name (which can be found from manila-manage service list). +``manila-manage version list`` + Returns list of versions. FILES -======== +===== The manila-manage.conf file contains configuration information in the form of python-gflags. -SEE ALSO -======== - -* `OpenStack Manila `__ - BUGS ==== -* Manila is sourced in Launchpad so you can view current bugs at `OpenStack Manila `__ +* Manila is sourced in Launchpad so you can view current bugs at `OpenStack Manila `__ diff --git a/test-requirements.txt b/test-requirements.txt index 25832ada..04003e95 100644 --- a/test-requirements.txt +++ b/test-requirements.txt @@ -8,5 +8,5 @@ nosehtmloutput>=0.0.3 nosexcover openstack.nose_plugin>=0.7 psycopg2 -sphinx>=1.1.2,<1.2 +sphinx>=1.2.1,<1.3 testtools>=0.9.32,<0.9.35