Merge "Fix a few typos in the docs"
This commit is contained in:
commit
b382cdaf45
@ -25,7 +25,7 @@ in the OpenStack Manuals Configuration Reference.
|
||||
HBase
|
||||
===================
|
||||
|
||||
This storage implementation uses Thrift HBase interface. The default Thrift's
|
||||
This storage implementation uses Thrift HBase interface. The default Thrift
|
||||
connection settings should be changed to support using ConnectionPool in HBase.
|
||||
To ensure proper configuration, please add the following lines to the
|
||||
`hbase-site.xml` configuration file::
|
||||
@ -36,7 +36,7 @@ To ensure proper configuration, please add the following lines to the
|
||||
</property>
|
||||
|
||||
For pure development purposes, you can use HBase from Apache_ or some other
|
||||
vendors like Cloudera or Hortonworks. To verify your installation, you can use
|
||||
vendor like Cloudera or Hortonworks. To verify your installation, you can use
|
||||
the `list` command in `HBase shell`, to list the tables in your
|
||||
HBase server, as follows::
|
||||
|
||||
@ -87,8 +87,7 @@ Pipelines
|
||||
=========
|
||||
|
||||
Pipelines describe a coupling between sources of samples and the
|
||||
corresponding sinks for transformation and publication of these
|
||||
data.
|
||||
corresponding sinks for transformation and publication of the samples.
|
||||
|
||||
A source is a producer of samples, in effect a set of pollsters and/or
|
||||
notification handlers emitting samples for a set of matching meters.
|
||||
|
@ -263,11 +263,11 @@ a screwball date into ISO format, or the like. They are initialized with the
|
||||
parameters from the trait definition, if any, which can customize their
|
||||
behavior for a given trait. They are called with a list of all matching fields
|
||||
from the notification, so they can derive a value from multiple fields. The
|
||||
plugin will be called even if there is no fields found matching the field
|
||||
plugin will be called even if there are no fields found matching the field
|
||||
path(s), this lets a plugin set a default value, if needed. A plugin can also
|
||||
reject a value by returning *None*, which will cause the trait not to be
|
||||
added. If the plugin returns anything other than *None*, the trait's value
|
||||
will be set from whatever the plugin returned (coerced to the appropriate type
|
||||
will be set to whatever the plugin returned (coerced to the appropriate type
|
||||
for the trait).
|
||||
|
||||
Building Notifications
|
||||
|
@ -45,7 +45,7 @@ Units
|
||||
should be expressed in bits ('b') or bytes ('B').
|
||||
2. For a given meter, the units should NEVER, EVER be changed.
|
||||
3. When the measurement does not represent a volume, the unit
|
||||
description should always described WHAT is measured (ie: apples,
|
||||
description should always describe WHAT is measured (ie: apples,
|
||||
disk, routers, floating IPs, etc.).
|
||||
4. When creating a new meter, if another meter exists measuring
|
||||
something similar, the same units and precision should be used.
|
||||
|
@ -188,8 +188,8 @@ against the database models. See :ref:`api-queries` for how to query the API.
|
||||
{"not": {"metadata.nonexistent_field" : "some value"}} filter is used in a query
|
||||
the Mongo DB will return every Sample object as *not* operator evaluated true
|
||||
for every Sample where the given field does not exists. See more in the Mongod DB doc.
|
||||
In the other hand SQL based DB engine will return empty result as the join operation
|
||||
on the metadata table will return zero row as the on clause of the join which
|
||||
On the other hand SQL based DB engine will return empty result as the join operation
|
||||
on the metadata table will return zero rows as the on clause of the join which
|
||||
tries to match on the metadata field name is never fulfilled.
|
||||
|
||||
Complex Query supports defining the list of orderby expressions in the form
|
||||
|
Loading…
Reference in New Issue
Block a user