Cleanup tox doc8 errors and other format cleanups
Fix doc8 erros in monitor-api.rst and fix up formatting issue in new devrefs Change-Id: Ia39795cec6606c6f4a87b4a05554737f40f24435
This commit is contained in:
Sridhar Ramaswamy
parent
4bcca3e8bc
commit
7651179031
@ -4,11 +4,11 @@ Tacker Monitoring Framework
|
||||
This section will introduce tacker monitoring framework and describes the
|
||||
various actions that a user can take when a specific event occurs.
|
||||
|
||||
- Introduction
|
||||
- How to write a new monitor driver
|
||||
- Events
|
||||
- Actions
|
||||
- How to write TOSCA template to monitor VNF entities
|
||||
* Introduction
|
||||
* How to write a new monitor driver
|
||||
* Events
|
||||
* Actions
|
||||
* How to write TOSCA template to monitor VNF entities
|
||||
|
||||
Introduction
|
||||
-------------
|
||||
@ -20,15 +20,18 @@ VNF entities it deploys and manages.
|
||||
How to write a new monitor driver
|
||||
----------------------------------
|
||||
|
||||
A monitor driver for tacker is a python module which contains a class that inherits
|
||||
from "tacker.vm.monitor_drivers.abstract_driver.VNFMonitorAbstractDriver".
|
||||
If the driver depends/imports more than one module, then create a new python
|
||||
package under tacker/vm/monitor_drivers folder. After this we have to mention
|
||||
our driver path in setup.cfg file in root directory.
|
||||
A monitor driver for tacker is a python module which contains a class that
|
||||
inherits from
|
||||
"tacker.vm.monitor_drivers.abstract_driver.VNFMonitorAbstractDriver". If the
|
||||
driver depends/imports more than one module, then create a new python package
|
||||
under tacker/vm/monitor_drivers folder. After this we have to mention our
|
||||
driver path in setup.cfg file in root directory.
|
||||
|
||||
For example:
|
||||
tacker.servicevm.monitor_drivers =
|
||||
ping = tacker.vm.monitor_drivers.ping.ping:VNFMonitorPing
|
||||
::
|
||||
|
||||
tacker.servicevm.monitor_drivers =
|
||||
ping = tacker.vm.monitor_drivers.ping.ping:VNFMonitorPing
|
||||
|
||||
The methods that need to override in driver are:
|
||||
1)def get_type(self)
|
||||
@ -48,8 +51,8 @@ This method must return the url of device to monitor
|
||||
|
||||
6)def monitor_call(self, device, kwargs)
|
||||
This method must either return boolean value True if VNF is healthy or return
|
||||
a event string like 'failure' or 'calls-capacity-reached' for specific VNF health
|
||||
condition.
|
||||
a event string like 'failure' or 'calls-capacity-reached' for specific VNF
|
||||
health condition.
|
||||
|
||||
Custom events
|
||||
--------------
|
||||
@ -58,13 +61,17 @@ return value of monitor_call is other than boolean value True, then we have to
|
||||
map those event to the corresponding action as described below.
|
||||
|
||||
For example:
|
||||
vdu1:
|
||||
monitoring_policy:
|
||||
ping:
|
||||
actions:
|
||||
failure: respawn
|
||||
In this example we have an event called 'failure'. So whenever monitor_call returns
|
||||
'failure' tacker will respawn the VNF.
|
||||
|
||||
::
|
||||
|
||||
vdu1:
|
||||
monitoring_policy:
|
||||
ping:
|
||||
actions:
|
||||
failure: respawn
|
||||
|
||||
In this example we have an event called 'failure'. So whenever monitor_call
|
||||
returns 'failure' tacker will respawn the VNF.
|
||||
|
||||
|
||||
Actions
|
||||
@ -72,9 +79,9 @@ Actions
|
||||
The available actions that a monitor driver can call when a particular event
|
||||
occurs
|
||||
|
||||
1)respawn
|
||||
2)log_and_kill
|
||||
3)log
|
||||
1. respawn
|
||||
2. log_and_kill
|
||||
3. log
|
||||
|
||||
How to write TOSCA template to monitor VNF entities
|
||||
----------------------------------------------------
|
||||
@ -83,36 +90,39 @@ In the vdus section, under vdu you can specify the monitors details with
|
||||
corresponding actions and parameters.The syntax for writing monitor policy
|
||||
is as follows:
|
||||
|
||||
vduN:
|
||||
monitoring_policy:
|
||||
<monitoring-driver-name>:
|
||||
monitoring_params:
|
||||
<param-name>: <param-value>
|
||||
...
|
||||
actions:
|
||||
<event>: <action-name>
|
||||
...
|
||||
...
|
||||
::
|
||||
|
||||
vduN:
|
||||
monitoring_policy:
|
||||
<monitoring-driver-name>:
|
||||
monitoring_params:
|
||||
<param-name>: <param-value>
|
||||
...
|
||||
actions:
|
||||
<event>: <action-name>
|
||||
...
|
||||
...
|
||||
|
||||
|
||||
Example Template
|
||||
----------------
|
||||
|
||||
::
|
||||
|
||||
vdu1:
|
||||
monitoring_policy:
|
||||
ping:
|
||||
actions:
|
||||
failure: respawn
|
||||
vdu1:
|
||||
monitoring_policy:
|
||||
ping:
|
||||
actions:
|
||||
failure: respawn
|
||||
|
||||
vdu2:
|
||||
monitoring_policy:
|
||||
http-ping:
|
||||
monitoring_params:
|
||||
port: 8080
|
||||
url: ping.cgi
|
||||
actions:
|
||||
failure: respawn
|
||||
vdu2:
|
||||
monitoring_policy:
|
||||
http-ping:
|
||||
monitoring_params:
|
||||
port: 8080
|
||||
url: ping.cgi
|
||||
actions:
|
||||
failure: respawn
|
||||
|
||||
acme_scaling_driver:
|
||||
monitoring_params:
|
||||
|
||||
@ -1,6 +1,8 @@
|
||||
===========================================
|
||||
**VNFD Template Parameterization Overview**
|
||||
===========================================
|
||||
VNFD Template Parameterization
|
||||
==============================
|
||||
|
||||
Overview
|
||||
--------
|
||||
|
||||
Parameterization allows for the ability to use a single VNFD to be deployed
|
||||
multiple times with different values for the VDU parameters provided at
|
||||
@ -11,9 +13,8 @@ non-parameterized template that has fixed IP addresses specified for network
|
||||
interface a second time without deleting the first instance of VNF would lead
|
||||
to an error.
|
||||
|
||||
==============================================
|
||||
**Non-parameterized VNFD template**
|
||||
==============================================
|
||||
Non-parameterized VNFD template
|
||||
-------------------------------
|
||||
|
||||
Find below an example of a non-parameterized VNFD where the text italicized
|
||||
are the VDU parameters and text in bold are the values for those VDU
|
||||
@ -87,9 +88,8 @@ vdus:
|
||||
|
||||
*param1*: **key1**
|
||||
|
||||
==============================================
|
||||
**Parameterized VNFD template**
|
||||
==============================================
|
||||
Parameterized VNFD template
|
||||
---------------------------
|
||||
This section will walk through parameterizing the template in above section
|
||||
for re-use and allow for deploying multiple VNFs with the same template.
|
||||
(Note: All the parameters italicized in the above template could be
|
||||
@ -172,9 +172,9 @@ vdus:
|
||||
|
||||
*param1*: **key1**
|
||||
|
||||
==============================================
|
||||
**Parameter values file at VNF deploy**
|
||||
==============================================
|
||||
|
||||
Parameter values file at VNF deploy
|
||||
-----------------------------------
|
||||
The below illustrates the parameters value file to be supplied containing the
|
||||
values to be substituted for the above parameterized template above during
|
||||
VNF deploy. Note that the structure of the parameters file follows closely
|
||||
@ -200,9 +200,8 @@ vdus:
|
||||
echo "my hostname is `hostname`" > /tmp/hostname
|
||||
df -h > /home/cirros/diskinfo
|
||||
|
||||
==============================================
|
||||
**Key Summary**
|
||||
==============================================
|
||||
Key Summary
|
||||
-----------
|
||||
- Parameterize your VNFD if you want to re-use for multiple VNF deployments.
|
||||
- Identify parameters that would need to be provided values at deploy time
|
||||
and substitute value in VNFD template with {get_input: <param_value_name>},
|
||||
@ -222,4 +221,5 @@ vdus:
|
||||
- Specifying a parameter values file during VNF creation is also supported in
|
||||
Horizon UI.
|
||||
- Sample VNFD parameterized templates and parameter values files can be found
|
||||
at https://github.com/openstack/tacker/tree/master/devstack/samples
|
||||
at https://github.com/openstack/tacker/tree/master/devstack/samples
|
||||
|
||||
|
||||
@ -18,8 +18,10 @@
|
||||
Welcome to Tacker's Developer Documentation!
|
||||
============================================
|
||||
|
||||
Tacker is an OpenStack project which offers container orchestration engines
|
||||
for deploying and managing containers as first class resources in OpenStack.
|
||||
Tacker is OpenStack project building an Open NFV Orchestrator with in-built
|
||||
general purpose VNF Manager to deploy and operate Virtual Network Functions
|
||||
(VNFs) on an NFV Platform. It is based on ETSI MANO Architectural Framework
|
||||
and provides full functional stack to Orchestrate VNFs end-to-end.
|
||||
|
||||
* **Free software:** under the `Apache license <http://www.apache.org/licenses/LICENSE-2.0>`_
|
||||
* **Source:** http://git.openstack.org/cgit/openstack/tacker
|
||||
@ -39,8 +41,9 @@ Feature Documentation
|
||||
=====================
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
:maxdepth: 1
|
||||
|
||||
devref/monitor-api.rst
|
||||
devref/vnfd_template_parameterization.rst
|
||||
|
||||
API Documentation
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user