[doc] Modify documents formatting

This commit is contained in:
Oleg Gelbukh
2013-10-22 08:17:46 +00:00
parent 3750f66ab1
commit a487f1568f
3 changed files with 21 additions and 19 deletions

View File

@@ -1,5 +1,6 @@
Architecture Data Model
=======================
Overview
--------
@@ -9,13 +10,13 @@ necessary to inspect, analyze, describe and visualize OpenStack architecture.
Architecture data model serves multiple actual and potential use cases.
Diagnostics
-----------
^^^^^^^^^^^
Architecture data model provides necessary data for the configuration analysis
and diagnostics tool ('''Rubick''').
and diagnostics tool (**Rubick**).
Deployment
----------
^^^^^^^^^^
Arhictecture data model must include all information necessary to deployment
systems (e.g. **Fuel** or **TripleO**). We will implement simple conversion
@@ -23,39 +24,39 @@ tools which will allow to configure these deployment systems and effectively
support 'portable' clouds.
Benchmarking
------------
^^^^^^^^^^^^
This model could be reused by '''Rally''' project to compare benchmarking
This model could be reused by **Rally** project to compare benchmarking
results for different architectures. Definitions of architectures must be
comparable and portable, which is exactly what architecture model aimed to
solve.
Upgrade
-------
^^^^^^^
Upgrade system could potentially utilize the model just in the way the
Deployment systems do. In addition, existing clouds could be inspected and
described for subsequent upgrade using this model.
Tech Support
------------
^^^^^^^^^^^^
The model suits as base for questionaire to assess existing installations for
support contract pricing purposes.
Hardening
---------
^^^^^^^^^
The model could be used to perform automated/guided hardening of OpenStack
architecture and configuration. This is achieved through use of 'best practice'
rulesets for the inspection of cloud.
Expert system
-------------
^^^^^^^^^^^^^
The model could be used as a part of production rules system capable of
automated reporting and handling of operational errors, based on combination of
'base' status of the cloud, logging messages and notifications.
The model could be used as a part of production/reactive rules system capable
of automated reporting and handling of operational errors, based on combination
of *base* status of the cloud, logging messages and notifications.
Data Format
-----------
@@ -65,7 +66,7 @@ installation. The model includes data regarding physical infrastructure, logical
topology of services and mapping between the two.
Architecture data model could be serialized as JSON or YaML document of the
following format:
following format::
openstack
nodes

View File

@@ -34,10 +34,11 @@ cause of such failures. To do so, he must check if his OpenStack configuration
is sane and consistent. These checks could be thought of as rules of diagnostic
system.
Currently OpenStack ecosystem lacks projects aimed to increase reliability and
resilience of the cloud. With this proposal we want to introduce a project which
will help operators to diagnose their OpenStack platform, reduce response time
to known and unknown failures and effectively support the desired SLA.
There are not many projects in OpenStack ecosystem aimed to increase reliability
and resilience of the cloud at the operation stage. With this proposal we want
to introduce a project which will help operators to diagnose their OpenStack
platform, reduce response time to known and unknown failures and effectively
support the desired SLA.
Mission
-------
@@ -47,7 +48,7 @@ minimize time and effort needed to identify and fix errors in operations
maintenance phase of cloud life cycle.**
User Stories
------------
-----------
- As a **cloud operator**, I want to make sure that my OpenStack architecture
and configuration is sane and consistent across all platform components and

View File

@@ -1,7 +1,7 @@
Production Rules Engine
=======================
This document describes rules engine used for inspection and diagnostics of
This document describes rule engine used for inspection and diagnostics of
OpenStack configuration.
Summary