[doc] Fix formatting and directory structure
This commit is contained in:
@@ -1,8 +0,0 @@
|
|||||||
OPENSTACK CONFIG ANALYZER DATA MODEL
|
|
||||||
====================================
|
|
||||||
|
|
||||||
This document proposes data model which allows to describe any OpenStack
|
|
||||||
installation. The model includes data regarding physical infrastructure, logical
|
|
||||||
topology of services and mapping between the two.
|
|
||||||
|
|
||||||
|
|
||||||
@@ -1,6 +1,10 @@
|
|||||||
= Arhitecture Data Model
|
=======================
|
||||||
|
ARCHITECTURE DATA MODEL
|
||||||
|
=======================
|
||||||
|
|
||||||
== Overview
|
--------
|
||||||
|
Overview
|
||||||
|
--------
|
||||||
|
|
||||||
Architecture data model produced by Joker could be consumed by configuration
|
Architecture data model produced by Joker could be consumed by configuration
|
||||||
validator tool (Dark Knight), by architecture graph (Stencil) and others.
|
validator tool (Dark Knight), by architecture graph (Stencil) and others.
|
||||||
@@ -20,7 +24,9 @@ support contract pricing purposes.
|
|||||||
The model could be used to perform automated/guided hardening of OpenStack
|
The model could be used to perform automated/guided hardening of OpenStack
|
||||||
architecture and configuration.
|
architecture and configuration.
|
||||||
|
|
||||||
== Data Format
|
-----------
|
||||||
|
Data Format
|
||||||
|
-----------
|
||||||
|
|
||||||
This section proposes data model format which allows to describe any OpenStack
|
This section proposes data model format which allows to describe any OpenStack
|
||||||
installation. The model includes data regarding physical infrastructure, logical
|
installation. The model includes data regarding physical infrastructure, logical
|
||||||
|
|||||||
30
doc/images/src/mvp0_demo_preparation_plan.txt
Normal file
30
doc/images/src/mvp0_demo_preparation_plan.txt
Normal file
@@ -0,0 +1,30 @@
|
|||||||
|
@startuml
|
||||||
|
frame "Peter" {
|
||||||
|
[network emulation]
|
||||||
|
cloud {
|
||||||
|
[demo scenario]
|
||||||
|
}
|
||||||
|
}
|
||||||
|
frame "Sergey" {
|
||||||
|
[network emulation] --> [salt bootstrap]
|
||||||
|
[salt bootstrap] --> [nodes discovery]
|
||||||
|
}
|
||||||
|
|
||||||
|
frame "Max" {
|
||||||
|
[config files collector]
|
||||||
|
[config-inspector] -up-> [demo scenario]
|
||||||
|
}
|
||||||
|
frame "Ilya" {
|
||||||
|
[tripleo-image-elements] --> [os-collect-config]
|
||||||
|
[tripleo-heat-templates] --> [os-collect-config]
|
||||||
|
}
|
||||||
|
frame "Kirill" {
|
||||||
|
[rules editing engine] <-- [config-inspector]
|
||||||
|
[rules editing engine] --> [demo scenario]
|
||||||
|
}
|
||||||
|
[nodes discovery] --> nodelist
|
||||||
|
nodelist --> [config files collector]
|
||||||
|
[config files collector] --> JSON
|
||||||
|
JSON --> [config-inspector]
|
||||||
|
[os-collect-config] --> JSON
|
||||||
|
@enduml
|
||||||
@@ -1,6 +1,9 @@
|
|||||||
= VALIDATOR INTEGRATION WITH OPENSTACK
|
VALIDATOR INTEGRATION WITH OPENSTACK
|
||||||
|
====================================
|
||||||
|
|
||||||
== Overview
|
--------
|
||||||
|
Overview
|
||||||
|
--------
|
||||||
|
|
||||||
OpenStack cloud life cycle consists of 2 distinct phases:
|
OpenStack cloud life cycle consists of 2 distinct phases:
|
||||||
|
|
||||||
@@ -9,16 +12,24 @@ OpenStack cloud life cycle consists of 2 distinct phases:
|
|||||||
|
|
||||||
Success of the *initial deployment* stage means that upfront installation and
|
Success of the *initial deployment* stage means that upfront installation and
|
||||||
configuration of the OpenStack platform is successful. Multiple projects work in
|
configuration of the OpenStack platform is successful. Multiple projects work in
|
||||||
that area: TripleO+Tuskar, Fuel, Packstack, Devstack to name a few. Most of
|
that area: TripleO+Tuskar, Fuel, Packstack, Devstack to name a few.
|
||||||
these projects are pretty good in what they are doing, but once you installed
|
|
||||||
and kicked off the cloud, things begin to change.
|
|
||||||
|
|
||||||
On the other hand, *operation maintenance* phase is more or less abundant of
|
Most of these projects are pretty good in what they are doing, but once you
|
||||||
|
installed and kicked off the cloud, things begin to change. Cloud enters
|
||||||
|
*operation maintenance* phase of its life cycle.
|
||||||
|
|
||||||
|
Changes to configuration, architecture and environment itself could reduce
|
||||||
|
overall stability and performance of the platform. Eventually operators faces
|
||||||
|
the situation when something goes wrong and service gets disrupted.
|
||||||
|
|
||||||
|
That said, *operation maintenance* phase is more or less abundant of
|
||||||
community-driven projects aimed to increase reliablility of cloud and
|
community-driven projects aimed to increase reliablility of cloud and
|
||||||
resilience which allows to support the SLA at reasonably high level (think your
|
resilience which allows to support the SLA at reasonably high level (think your
|
||||||
favourite number of nines).
|
favourite number of nines).
|
||||||
|
|
||||||
== Proposal Summary
|
----------------
|
||||||
|
Proposal Summary
|
||||||
|
----------------
|
||||||
|
|
||||||
With this proposal we want to introduce a project aimed to enhance and simplify
|
With this proposal we want to introduce a project aimed to enhance and simplify
|
||||||
operatinal maintenance of OpenStack cloud. Project provides service which uses
|
operatinal maintenance of OpenStack cloud. Project provides service which uses
|
||||||
@@ -26,12 +37,18 @@ rule-based engine (```lettuce```) to inspect configurations of OpenStack
|
|||||||
platform and find all kinds of architecture- and configuration-level glitches
|
platform and find all kinds of architecture- and configuration-level glitches
|
||||||
and inconsistencies.
|
and inconsistencies.
|
||||||
|
|
||||||
This engine will be eventually used to provide hints and best practices to
|
This engine will provide hints and best practices to increase reliability and
|
||||||
increase reliability and operational resilience of the cloud.
|
operational resilience of the cloud.
|
||||||
|
|
||||||
== Integration Points
|
Rules engine
|
||||||
|
------------
|
||||||
|
|
||||||
=== TripleO integration points
|
------------------
|
||||||
|
Integration Points
|
||||||
|
------------------
|
||||||
|
|
||||||
|
TripleO integration points
|
||||||
|
--------------------------
|
||||||
|
|
||||||
.. image:: images/openstack_integration.png
|
.. image:: images/openstack_integration.png
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user