AT&T ECOMP Vendor Event Listener library
0.1
|
This Quick-Start section describes how to:
The library is supplied as a source-code compressed-tar file. It is straightforward to install and build to integrate with an existing or new development project.
The file should unpacked into your development environment:
Note that all commands in this section are based on CentOS package management tools and you may need to substitute the appropriate tools/packages for your distribution, for example apt-get
for Ubuntu.
Ensure that GCC development tools are available.
Additionally, the library has a dependency on the cURL library, so you'll need the development tools for libCurl installed. (At runtime, only the runtime library is required, of course.)
If you wish to make the project documentation, then Doxygen and Graphviz are required. (Again, this is only in the development environment, not the runtime environment!)
Note that some distributions have quite old versions of Doxygen by default and it may be necessary to install a later version to use all the features.
If you want to build PDFs from the LaTeX you will need a texlive install.
Make sure that the library makes cleanly:
You should now be able to run the demo CLI application. Since it will want to dynamically link to the library that you've just made, you will need to set your LD_LIBRARY_PATH
appropriately first. Make sure that you specify your actual directory paths correctly in the following:
Assuming that all worked as expected, you are ready to start integrating with your application. It probably makes sense to make the LD_LIBRARY_PATH change above permanent by incorporating it into your .bash_profile
file.
The source comes with its own documentation included. The documentation can be built using the docs
target in the Makefile. By default this builds HTML and LaTeX documentation, the latter being used to prepare PDFs.
To make the documentation:
There is a make target that is intended to install the documentation on a "team server" - it will need adaptation for your team's environment - see the docs_install
target in the Makefile:
There are two key steps to the integration which have to be undertaken:
Additionally, it may be necessary to consider changes to the EVEL library's source code if assumptions made by the library are either not satisfied or inconvenient. In particular:
syslog
for event logging. If the project uses a different event logging process, then EVEL's event logging macros should be rewritten appropriately.These steps are considered in the Normal Use and EVEL Adaptation sections below.
The EVEL Library should be integrated with your project at a per-process level: each process is an independent client of the ECOMP Vendor Event Listener API.
The EVEL Library should be initialized before the process becomes multi-threaded. This constraint arises from the use of libcurl which imposes the constraint that initialization occurs before the system is multi-threaded. This is described in more detail in the libcurl documentation for the curl_global_init function.
Initialization stores configuration of the Vendor Event Listener API's details, such as the FQDN or IP address of the service, so the initializing process must have either extracted this information from its configuration or have this information "hard-wired" into the application, so that it is available at the point the evel_initialize()
function is called:
Once initialization has occurred successfully, the application may raise events and may also use the logging functions such as EVEL_INFO().
Initialization is entirely local (there is no interaction with the service) so it is very unlikely to fail, unless the application environment is seriously degraded.
Generating events is a two stage process:
In practice this looks like:
The EVEL Library supports the following types of events:
Faults
These represent the fault domain in the event schema.
Measurements
These represent the measurementsForVfScaling domain in the event schema.
Reports
This is an experimental type, designed to allow VNFs to report application-level statistics unencumbered with platform measurements. The formal AT&T schema has been updated to include this experimental type as measurementsForVfReporting.
Mobile Flow
These represent the mobileFlow domain in the event schema.
Other
These represent the other domain in the event schema.
Service Events
These represent the serviceEvents domain in the event schema.
Signaling
These represent the signaling domain in the event schema.
State Change
These represent the stateChange domain in the event schema.
Syslog
These represent the syslog domain in the event schema.
The EVEL library supports the following command types as defined in the JSON API:
commandType: throttlingSpecification
This is handled internally by the EVEL library, which stores the provided throttling specification internally and applies it to all subsequent events.
commandType: provideThrottlingState
This is handled internally by the EVEL library, which returns the current throttling specification for each domain.
commandType: measurementIntervalChange
This is handled by the EVEL library, which makes the latest measurement interval available via the evel_get_measurement_interval function. The application is responsible for checking and adhering to the latest provided interval.
Termination of the EVEL Library is swift and brutal! Events in the buffer at the time are "dropped on the floor" rather than waiting for the buffer to deplete first.
The EVEL Library is relatively simple and should be easy to adapt into other project environments.
There are two circumstances where initialization of libcurl may be required:
The EVEL Library uses syslog
for logging. If this is inappropriate then the log_debug() and log_initialize() functions should be rewritten accordingly.
Note: it would be a really bad idea to use the EVEL Library itself for this logging function. Turtles all the way down...