[doc] Fix proposal document, add service architecture diag

doc/architecture_model.rst

@@ -1,50 +0,0 @@
-=======================
-ARCHITECTURE DATA MODEL
-=======================
-
-Overview
---------
-
-We want to introduce unified data structure which contains all information
-necessary to inspect, analyze, describe and visualize OpenStack architecture.
-
-This Architecture data model could be consumed and processed by configuration
-analysis and diagnostics tool (**Dark Knight**) and by architecture visualizer
-(**Stencil**). 
-
-Arhictecture data model must include all information necessary to deployment
-systems (e.g. **Fuel** or **TripleO**). We will implement simple conversion tools which
-will allow to configure these deployment systems and effectively support
-'portable' clouds.
-
-This model could be reused by Rally project to compare benchmarking results for
-different architectures.
-
-The model can be used to inspect existing clouds for subsequent upgrade.
-
-The model suits as base for questionaire to assess existing installations for
-support contract pricing purposes.
-
-The model could be used to perform automated/guided hardening of OpenStack
-architecture and configuration.
-
-Data Format
------------
-
-This section proposes data model format which allows to describe an OpenStack
-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::
-
-    openstack
-        nodes
-            node1
-                -param1: value
-                -param2: value
-        services
-            nova
-                configuration
-                    -param1: value
-                    -param2: value

doc/configuration_validator.rst

@@ -5,7 +5,7 @@ Project Name
 ------------
 
 **Official:** OpenStack Diagnostics
-**Codename:** Dark Knight
+**Codename:** Rubick
 
 Overview
 --------
@@ -13,29 +13,35 @@ Overview
 OpenStack cloud operators usually rely on deploymnet tools to configure all the
 platform components correctly and efficiently upfront. However, after initial
 deployment platform configurations and operational conditions start to change.
-We propose a project that allows to analyze OpenStack architecture and diagnose
-existing and potential problems using flexible set of rules.
+These changes could break consistency and integration of cloud platform and its
+components.
 
 Mission
 ---------
 
-Diagnostics project mission is to **provide OpenStack cloud operators with
-flexible way to inspect, analyze and diagnose architecture of the cloud and
-configuration of components of the platform**.
+Diagnostics' mission is to **provide OpenStack cloud operators with tools which
+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 be able to automatically extract
+ - As a **cloud operator**, I want to make sure that my OpenStack architecture
+   and configuration is sane and consistent across all platform components and
+   services.
+ - As a **cloud architect**, I want to make sure that my OpenStack architecture
+   and configuration are compliant to best practices.
+ - As a **cloud architect**, I need a knowledge base of sanity checks and best
+   practices for troubleshooting my OpenStack cloud which I can reuse and update
+   with my own checks and rules.
+ - As a **cloud operator**, I want to be able to automatically extract
    configuration parameters from all OpenStack components to verify their
    correctness, consistency and integrity.
-As a **cloud architect**, I want to make sure that my OpenStack architecture and
-configuration are compliant to 'best practices'.
-As a **cloud operator**, I want automatic diagnostics tool which can tell me
-what problems does my OpenStack architecture and/or configuration have or might
-potentially have (e.g. at scale or if some component or node failed).
-As a **cloud operator**, I want to be able to define rules used to inspect and
-verify configuration of OpenStack components and store them to use for
+ - As a **cloud operator**, I want automatic diagnostics tool which can inspect
+   configuration of my OpenStack cloud and report if it is sane and/or compliant
+   toc community-defined best practices.
+ - As a **cloud operator**, I want to be able to define rules used to inspect
+   and verify configuration of OpenStack components and store them to use for
    verification of future configuration changes.
 
 Requirements

doc/images/src/service_architecture.txt

@@ -0,0 +1,34 @@
+@startuml
+
+frame "Rubick" {
+    [Rubick API]
+    [Rule engine]
+    [Config data\nextractor]
+    [Heat metadata\n plugin]
+    [Metadata\nplugin 1]
+    [...]
+    [Metadata\nplugin N]
+    [Config data\nstore]
+    () "env.json"
+}
+
+frame "Heat" {
+    [Heat API]
+    [Templated\nconfig data]
+}
+
+() HOT
+
+[Rubick API] -- env.json
+[Config data\nstore] -- env.json
+[Heat API] --> HOT
+HOT --> [Heat metadata\n plugin]
+[Config data\nextractor] -up- env.json
+[Rule engine] -- env.json
+[Templated\nconfig data] --> [Heat API]
+[Config data\nextractor] -- [Heat metadata\n plugin]
+[Config data\nextractor] -- [Metadata\nplugin 1]
+[Config data\nextractor] -- [...]
+[Config data\nextractor] -- [Metadata\nplugin N]
+
+@enduml

doc/openstack_integration.rst

@@ -27,16 +27,26 @@ community-driven projects aimed to increase reliablility of cloud and
 resilience which allows to support the SLA at reasonably high level (think your
 favourite number of nines).
 
+Maintenance stages
+
+Where the product is applicable?
+
 ----------------
 Proposal Summary
 ----------------
 
 With this proposal we want to introduce a project aimed to enhance and simplify
 operatinal maintenance of OpenStack cloud. Project provides service which uses
-rule-based engine (```lettuce```) to inspect configurations of OpenStack
+rule-based engine to inspect configurations of OpenStack
 platform and find all kinds of architecture- and configuration-level glitches
 and inconsistencies.
 
+*# describe motivation behind rules
+# describe rules reuse
+# desribe rule-based inspection
+# example rule
+# mandatory rules vs. best-practice rules*
+
 This engine will provide hints and best practices to increase reliability and
 operational resilience of the cloud.