[doc] Added description for rule creation
This commit is contained in:
parent
6ff7430718
commit
38210d6ecb
@ -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
|
||||
-------------------------------
|
||||
|
Loading…
x
Reference in New Issue
Block a user