From 30c7bab6a911162a3094fc0d801d27a387b85c38 Mon Sep 17 00:00:00 2001 From: Christian Berendt Date: Thu, 29 May 2014 21:42:02 +0200 Subject: [PATCH] Fixed typos found by RETF rules Rules are avaialble at https://en.wikipedia.org/wiki/Wikipedia:AutoWikiBrowser/Typos. Fixed some more typos found by Dina Belova. Change-Id: If6c83c112f1e5d193cf31481cbd11759c7213c7d --- specs/juno/dedicated-alarm-database.rst | 10 +++++----- specs/juno/gnocchi.rst | 8 ++++---- specs/template.rst | 4 ++-- 3 files changed, 11 insertions(+), 11 deletions(-) diff --git a/specs/juno/dedicated-alarm-database.rst b/specs/juno/dedicated-alarm-database.rst index 3db74f6..a818e27 100644 --- a/specs/juno/dedicated-alarm-database.rst +++ b/specs/juno/dedicated-alarm-database.rst @@ -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] diff --git a/specs/juno/gnocchi.rst b/specs/juno/gnocchi.rst index 0bebd9c..672aee5 100644 --- a/specs/juno/gnocchi.rst +++ b/specs/juno/gnocchi.rst @@ -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 ------------ diff --git a/specs/template.rst b/specs/template.rst index ed309e3..ce6c129 100644 --- a/specs/template.rst +++ b/specs/template.rst @@ -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