openstack/telemetry-specs
Code Issues Proposed changes

Fixed typos found by RETF rules

Browse Source 
Rules are avaialble at https://en.wikipedia.org/wiki/Wikipedia:AutoWikiBrowser/Typos.
Fixed some more typos found by Dina Belova.

Change-Id: If6c83c112f1e5d193cf31481cbd11759c7213c7d
This commit is contained in:
Christian Berendt 2014-05-29 21:42:02 +02:00
parent af48e205b8
commit 30c7bab6a9
3 changed files with 11 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
specs/juno/dedicated-alarm-database.rst
View File

@ -11,10 +11,10 @@ Dedicated database for the alarm definition and history of Ceilometer
https://blueprints.launchpad.net/ceilometer/+spec/dedicated-alarm-database
Currently if we use MongoDB for storing metering data, we are forced to use
mongodb for storing events and alarms. Because the API service can use only
MongoDB for storing events and alarms. Because the API service can use only
one database connection object.
Also metering and alarm are two completly different things, but the db code
Also metering and alarm are two completely different things, but the db code
are currently in the same place.
The blueprint proposes to allow to have a different database for alarms
@ -38,7 +38,7 @@ that can be set to metering or alarm.
This will allow to use a different namespace to load a driver that depends
of the purpose.
New entrypoints will be added to have a different set of driver for alarm
New entry points will be added to have a different set of driver for alarm
and metering.
Ceilometer API will use two connection objects, one for metering and one for
@ -54,7 +54,7 @@ Data model impact
None
In case of sqlalchemy, migration scripts will continue to be stored in a
In case of SQLAlchemy, migration scripts will continue to be stored in a
common place to ensure easy migration.
And if a dedicated database is used, we accepted having unused and empty
tables.
@ -87,7 +87,7 @@ None
Other deployer impact
---------------------
The deployer can now optionnaly define a dedicated database for the alarming
The deployer can now optionally define a dedicated database for the alarming
of ceilometer by adding::
[database]

8
specs/juno/gnocchi.rst
View File

@ -61,15 +61,15 @@ However, while the event collection of Ceilometer is pretty solid and ok
(but still needs to be working on), the metrics part suffers terrible design
and performance issues.
Having the so called free form metadata associated with each metric
Having the so-called free form metadata associated with each metric
generated by Ceilometer is the most problematic design we have. It stores a
lot of redundant information that it is hard to query in a efficient manner.
lot of redundant information that it is hard to query in an efficient manner.
On the other hand, systems like RRD have existed for a while, storing a
large amount of (aggregated) metrics without much problem. The metadata
associated to these metrics being another issue.
So that let us with 2 different problem to solve: store metrics and store
information (the so called metadata) about resources.
So that left us with 2 different problem to solve: store metrics and store
information (the so-called metadata) about resources.
Alternatives
------------

4
specs/template.rst
View File

@ -41,7 +41,7 @@ Some notes about using this template:
required. http://asciiflow.com/ is a very nice tool to assist with making
ascii diagrams. The reason for this is that the tool used to review specs is
based purely on plain text. Plain text will allow review to proceed without
having to look at additional files which can not be viewed in gerrit. It
having to look at additional files which can not be viewed in Gerrit. It
will also allow inline feedback on the diagram itself.
Problem description
@ -328,7 +328,7 @@ more tempest testcases would need to be included.
Is this untestable in the upstream gate given current limitations (specific
hardware / software configurations available)? If so, are there mitigation
plans (3rd party testing, gate enhancements, etc).
plans (3rd party testing, gate enhancements, etc.).
Documentation Impact