/
Testing with Functest

Anuket Project

Testing with Functest

May 19, 2017





OPNFV Release E (Euphrates)



 The intention of the Barometer test in the OPNFV E release is simply to extend the test suite that was developed in the D release with new tests for the following features:

 

Theme: OPNFV Platform Equivalence

Test Jira

Theme: OPNFV Platform Equivalence

Test Jira

RDT Support

BAROMETER-65 -Test collectd RDT Cache Plugin OPEN

Platform Legacy Support (IPMI)

BAROMETER-66 -Test collectd IPMI PluginOPEN

RAS Support

BAROMETER-67 -Test collectd RAS PluginOPEN

PMU Support

BAROMETER-68 -Test collectd PMU PluginOPEN

Libvirt Support

BAROMETER-69 -Test collectd Libvirt Plugin OPEN

vSwitch Health

BAROMETER-70 -Test collectd OVS PluginsOPEN

PCIe Error reporting

BAROMETER-71 -Test collectd PCIe PluginOPEN

SNMP write plugin

BAROMETER-72 -Test collectd SNMP Plugin OPEN

Aodh plugin

BAROMETER-73 -Test collectd Aodh PluginOPEN

Gnocchi Support

BAROMETER-74 -Test collectd Gnocchi Plugin OPEN

ETSI TST008 Alignment

BAROMETER-75 -Test TST008 AlignementOPEN

clock speed and power state (CPU + platform) 

BAROMETER-75 -Test TST008 AlignementOPEN

Plugin rename to barometer as part of Apex Support

 

Integration with Apex

Covered by all the other testing JIRAs

Euphrates Stretch Goals

collectd agent extensions

BAROMETER-76 -Test collectd agent extensions OPEN

Host Health Support

BAROM



Functest Test Case Extension Proposal


Project: Barometer (formerly known as SFQM – Software Fastpath Service Quality Metrics)
Authors/Contributors: Calin Gherghe (Intel Corp)
Test Case Name: BarometerCollectd
Test Type: External (i.e. test code will be kept in the project repository)
Test Tier: features
Test Constrains:

 

Scenario(s) (in order of priority):

 

  • os-nosdn-bar-noha

  • os-nosdn-bar-ha

  • os-nosdn-kvm_ovs_dpdk_bar-noha

  • os-nosdn-kvm_ovs_dpdk_bar-ha

 

Installer(s): Apex

 

Test Scope:

The test is intended to validate individually the collectd plugins which are part of the Barometer project, therefore is constituted as a test-suite.

The verifications are aimed to check the functionality according to the default (current) status and configuration of each plugin.

Testing is targeting the Compute Node(s) in the POD. No modifications are expected to be done on the target systems.

The tests’ key focus is to confirm the corresponding metrics (and/or events) are properly dispatched by the read-plugins, respectively properly sent by the output plugins.