Correct contributor doc information

1. correct typos
2. update expire description according to latest code
3. correct sphinx wrong format

Change-Id: I898133bd90132c8d7bef49048da0f176f4758dfe
This commit is contained in:
Rui Yuan Dou 2017-08-18 16:38:09 +08:00
parent 20a33d7439
commit bb6248a3d3
2 changed files with 11 additions and 7 deletions

View File

@ -53,7 +53,7 @@ Conditional Update
Conditional Update is the mechanism we use in Cinder to prevent races when
updating the DB. In essence it is the SQL equivalent of an ``UPDATE ... FROM
... WHERE;`` clause
... WHERE;`` clause.
It is implemented as an abstraction layer on top of SQLAlchemy ORM engine in
our DB api layer and exposed for consumption in Cinder's Persistent Versioned
@ -65,7 +65,8 @@ Method signature is:
.. code:: python
def conditional_update(self, values, expected_values=None, filters=(),
save_all=False, session=None, reflect_changes=True):
save_all=False, session=None, reflect_changes=True,
order=None):
:values:
Dictionary of key-value pairs with changes that we want to make to the
@ -97,6 +98,9 @@ Method signature is:
reflect these changes, but we can prevent this instance update passing False
on this argument.
:order:
Specific order of fields in which to update the values.
:Return Value:
We'll return the number of changed rows. So we'll get a 0 value if the
conditional update has not been successful instead of an exception.
@ -364,8 +368,8 @@ The idea is simple, using ``Case`` class we can say which values to set in a
field based on conditions and also set a default value if none of the
conditions are True.
Conditions must be SQLAlchemy conditions, so we'll need to use fields from the
``model`` attribute.
Conditions must be SQLAlchemy conditions, so we'll need to use fields from
the ``model`` attribute.
For example setting the status to "maintenance" during migration if current
status is "available" and leaving it as it was if it's not can be done using

View File

@ -119,7 +119,7 @@ Capabilities reporting
----------------------
There are 2 new replication stats/capability keys that drivers supporting
relication v2.1 should be reporting: ``replication_enabled`` and
replication v2.1 should be reporting: ``replication_enabled`` and
``replication_targets``::
stats["replication_enabled"] = True|False
@ -345,7 +345,7 @@ the manager by default, but it won't create additional DB queries if it is
returned. It is however necessary to set it to ``FAILOVER_ERROR`` for those
volumes that had errors during the failover.
Driver's don't have to worry about snapshots or non replicated volumes, since
Drivers don't have to worry about snapshots or non replicated volumes, since
the manager will take care of those in the following manner:
- All non replicated volumes will have their current ``status`` field saved in
@ -377,7 +377,7 @@ Drivers are not required to support failback, but they are required to raise a
supported.
The way to request the failback is quite simple, the driver will receive the
argument ``secondary_id`` with the value of ``default``. That is why if was
argument ``secondary_id`` with the value of ``default``. That is why it was
forbidden to use the ``default`` on the target configuration in the cinder
configuration file.