From 38210d6ecbb743cdf06b1c767f8d66e41881f9eb Mon Sep 17 00:00:00 2001 From: Peter Lomakin Date: Mon, 21 Oct 2013 17:05:31 +0400 Subject: [PATCH] [doc] Added description for rule creation --- doc/source/rules_engine.rst | 29 ++++++++++++++++++++++++++++- 1 file changed, 28 insertions(+), 1 deletion(-) diff --git a/doc/source/rules_engine.rst b/doc/source/rules_engine.rst index 6e5bf4c..06f06b0 100644 --- a/doc/source/rules_engine.rst +++ b/doc/source/rules_engine.rst @@ -14,7 +14,8 @@ diagnosing the exact problem is always a challenge, given the number of components and configuration options per component. 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 configuration breaks, you can identify incorrect parameters reliably and easy. That is how production rules or diagnostic systems work. @@ -30,9 +31,35 @@ Example production rule for OpenStack system would be:: 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 --------------------- +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 -------------------------------