Differences

This shows you the differences between two versions of the page.

--- requirements_projects:failure_prediction [2014/12/10 07:05]
Hai Liu
+++ — (current)
@@ Line 1: / Line 1: @@
-==== OPNFV failure prediction: ====
-  * Proposed name for the project: ''failure prediction''
-  * Proposed name for the repository: ''opnfv-fp''
-  * Project Categories: ''(Requirements)''
-==== Project description: ====
-Failure prediction is an important feature of failure prevention, which could be used to help strengthening the NFV system in the real time environment.
-A maturity and robust mechanism of failure prediction will be the first step for failure prevention, and it shall be taken care of dedicatedly in the OPNFV study as part of fault management issue.
-Failure prediction has been studied in ETSI NFV ISG, and there also has developed some general requirements, which should be the initial input for this topic in OPNFV.
-For example, in NFV GS Draft ETSI GS NFV-REL 001 (v1.0.0, 2014-11), failure prediction has collected several requirements have been captured as below:
-.	The real-time resource usage such as the disk usage, CPU Load, memory usage, network IO and virtual IO usage and their loss rate, and available vCPUs, virtual memory, etc. shall be provided to VIM at configurable intervals by entities of infrastructure. It should also be possible to configure the thresholds or watermarks for the event notification instead of configuring the reporting interval.
-.	Each entity of infrastructure shall provide the open interfaces for communicating the performance and the consumption resource and for allowing polling of its working state and resource usage.
-.	The failure prediction framework should include the functionality of the false alarm filtering to avoid triggering unnecessary prevention procedure for anomaly alarming.
-.	The failure prediction framework should include trend identification, period or seasonal variations, and randomness analysis of the collected data on resource usage (e.g., memory, file descriptors, sockets, database connections) to predict the progression of the operated NFV system to an unhealthy state, e.g., resource exhausting.
-.	The failure prediction framework should be able to diagnose or verify which entity is suspected to be progressing towards a failure and which VNFs might be affected due to the predicted anomaly.
-.	The entities of VNF and its supported infrastructure should have their own self-diagnostic functionality in order to provide their health information to the VIM.
-.	The log report associated with a NFVI resource failure or an error detected by a hardware component, software module, hypervisor, VM, or the network should include the error severity.
-.	The log report should include an indication of the failure cause.
-While Fault Management topic shall also be one of the important issues in ETSI NFV Phase 2, so it is possible that such requirements for fault prediction would be updated or enriched during the period of this OPNFV project, if it happens, then the updated part will be captured as well in this project.
-While considering the upstream projects, there also have existed some projects in this area, e.g.
--	the Ceilometer project in OpenStack for system resource monitoring;
--	the “Monasca” project proposal in OpenStack for “Monitoring as a service”;
--	the new project proposal “Time Series Data Repository (TSDR)” in OpenDaylight for ODL system monitoring.
-However, those projects care for the upstream project system itself mainly, and will not consider the requirements specific for OPNFV environment. In addition, there would possibly be overlap between those upstream projects and the OPNFV failure prediction issue in general. That shall be investigated in the project, so that OPNFV could cooperate with those upstream projects.
-==== Scope: ====
-__Describe the problem being solved by project:__
-As a requirements category project, it plans to solve the problem as following:
--	Investigate the gap analysis between OPNFV failure prediction and ETSI NFV REL GS, OpenStack Ceilometer project, and possibly OpenStack Monasca project and OpenDaylight Time Series Data Repository project.
--	Develop an OPNFV failure prediction report, which could be used as the input for later stage, e.g. integration & testing, collaborative development and etc.
--	Design general software framework architecture for OPNFV failure prediction system, which could be used as the input for later stage, e.g. integration & testing, collaborative development and etc.
-__Specify any interface/API specification proposed:__
-Additional interface specifications:
--	VI-Ha
--	Vf-Vi
--	Vi-Vnfm
--	Or-Vi
--	Other interfaces potentially to be brought during the project
-__Specify testing and integration:__
-•	Debugging and Tracing
-•	Unit/Integration Test plans
-•	Client tools developed for status shows etc.
-__Identity a list of features and functionality will be developed:__
-o	Additional features of Ceilometer, Monasca and TSDR to support OPNFV failure prediction.
-o	An engine to collect online information and make failure prediction.
-__Identify what is in or out of scope. So during the development phase, it helps reduce discussion:__
-o	In scope:
-	Considering the ETSI NFV REL GS version 1.0.0 (2014-11) as one of the input. The conclusion for failure prediction in ETSI NFV REL phase 2.0 before the project’s deadline, will also be considered.
-	The ongoing discussion and conclusion of the upstream projects (i.e. Ceilometer, Monasca, TSDR), before this OPNFV failure prediction’s deadline, shall be considered as parts of the input.
-	General software design framework for OPNFV failure prediction system.
-o	Out of scope
-	The ongoing discussion for failure prediction after this OPNFV failure prediction deadline will not be captured in it, e.g. for the ETSI NFV REL phase 2.0, related upstream projects.
-	If the Monasca and TSDR are not approved by OpenStack and OpenDaylight before the deadline of this project, it will be excluded from this project.
-	Detail software design for it shall be in the later stage, e.g. in the Collaborative Development.
-•	Describe how the project is extensible in future
-o	The achievements of this project will be used as the input for next stage, e.g. Integration & Testing, and Collaborative Development.
-Testability: (optional, Project Categories: Integration & Testing)
-•	Specify testing and integration like interoperability, scalability, high availablity
-o	N/A (Integration with OPNFV is TBD based on development in upstream projects)
-•	What QA and test resources will be available?
-o	TBD
-Documentation: (optional, Project Categories: Documention)
-•	API Docs
-o	Fault Prediction API Specification in the interfaces, e.g. VI-Ha, Vf-Vi, Vi-Vnfm, Or-Vi and other potential impacted interfaces during the project.
-•	Functional block description
-o	TBD, possibly a function block for “OPNFV Failure Prediction”.
-Dependencies:
-•	Identify similar projects is underway or being proposed in OPNFV or upstream project
-o	The “Doctor (Fault Management and Maintenance)” project.
-o	The “High availability for OPNFV”.
-•	Identify any open source upstream projects and release timeline.
-o	Ceilometer project (https://wiki.openstack.org/wiki/Ceilometer ) is the upstream project of this project. It would be aligned with OpenStack release schedule and OPNFV Release 1 schedule.
-o	Monasca project (https://launchpad.net/monasca), is the upstream project of this project. It would be aligned with OpenStack release schedule and OPNFV Release 1 schedule.
-o	TSDR Project (https://wiki.opendaylight.org/view/Project_Proposals:Time_Series_Data_Repository ) is the upstream project of this project. It would be aligned with Opendaylight release schedule and OPNFV Release 1 schedule.
-•	Identify any specific development be staged with respect to the upstream project and releases.
-o	none
-•	Are there any external fora or standard development organization dependencies. If possible, list and informative and normative reference specifications.
-o	ETSI NFV draft REL GS (v1.0.0, 2014-11)
-•	If project is an integration and test, identify hardware dependency.
-o	N/A
-Committers and Contributors:
-•	Names and affiliations of the committers:
-o	Hai Liu,  hai.liu@huawei.com
-o	Yijun Yu, yuyijun@huawei.com
-o	Jun Li, matthew.lijun@huawei.com
-o	Yifei Xue, xueyifei@huawei.com
-o	Linghui Zeng, linghui.zeng@huawei.com
-o	Qiao Fu, fuqiao@chinamobile.com
-•	Any other contributors: TBD
-Planned deliverables
-•	Described the project release package as OPNFV or open source upstream projects.
-o	OPNFV failure prediction gap analysis (e.g. ETSI NFV draft NFV GS, Ceilometer, Monasca, TSDR);
-o	OPNFV failure prediction report;
-o	OPNFV failure prediction software framework architecture, together with API specification.
-•	If project deliverables have multiple dependencies across other project categories, described linkage of the deliverables.
-o	None
-Proposed Release Schedule:
-•	When is the first release planned?
-o	Gap analysis is planned to be finished in OPNFV 1st release, i.e. by March, 2015.
-o	OPNFV failure prediction report is planned to be finished by May, 2015.
-o	OPNFV failure prediction software framework architecture (including API specification) is planned to be finished by August, 2015.
-•	Will this align with the current release cadence
-o	Yes, the gap analysis will be part of OPNFV 1st release; others will be part of OPNFV 2nd release.

Wiki

User Tools

Site Tools

Differences

Page Tools