stackforge/rubick
Code Issues Proposed changes

[doc] Added description for rule creation

Browse Source
This commit is contained in:
Peter Lomakin 2013-10-21 17:05:31 +04:00
parent 6ff7430718
commit 38210d6ecb
1 changed files with 28 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

29
doc/source/rules_engine.rst
View File

@ -14,7 +14,8 @@ diagnosing the exact problem is always a challenge, given the number of
components and configuration options per component. components and configuration options per component.
You could think about troubleshooting OpenStack as going through some scenarios You could think about troubleshooting OpenStack as going through some scenarios
which can be expressed as sets of rules. Your configuration must comply to all those which can be expressed as sets of rules. Your configuration must comply to all
those
rules to be operational. On the other hand, if you know rules which your rules to be operational. On the other hand, if you know rules which your
configuration breaks, you can identify incorrect parameters reliably and easy. configuration breaks, you can identify incorrect parameters reliably and easy.
That is how production rules or diagnostic systems work. That is how production rules or diagnostic systems work.
@ -30,9 +31,35 @@ Example production rule for OpenStack system would be::
Rule-based inspection Rule-based inspection
--------------------- ---------------------
All rule-based inspections are using pre-defined actions written on python, for
now they defined in "steps.py" file in the directory:
ostack_validator/inspections/lettuce. As you can see they are based on lettuce
framework - bdd framework for python.
Store and reuse rules Store and reuse rules
--------------------- ---------------------
You can store your rules wherever you want and add it through the UI or simply
putting it in directory ostack_validator/inspections/lettuce with name like
this: *.feature. The main requirement is that all you actions in those files
must be written according to the rules in steps.py.
Also you can expand the rules definition by adding your own steps.py. As example:
#This decorator is for defining step for using them in the scenario.
@step(r'Nova has "(.+)" equal to "(.*)"')
def nova_has_property(step, name, value):
name = subst(name)
value = subst(value)
for nova in [c for c in world.openstack.components if
c.name.startswith('nova')]:
if not nova.config[name] == value:
stop()
New methods can use 2 classes from the inspections framework:
ostack_validator.model and ostack_validator.common. There are you can find many
adapters to the services configuration data and all additional information
collected from OpenStack nodes. After that you can use you brand new rule in
the scenarios as described above.
Sanity checks vs best practices Sanity checks vs best practices
------------------------------- -------------------------------