146 lines
4.0 KiB
ReStructuredText
146 lines
4.0 KiB
ReStructuredText
..
|
|
|
|
This work is licensed under a Creative Commons Attribution 3.0 Unported License.
|
|
http://creativecommons.org/licenses/by/3.0/legalcode
|
|
|
|
..
|
|
This template is intended to encourage a certain level of consistency
|
|
between different use cases. However strict adherence to the structure
|
|
of this template is not required.
|
|
|
|
This template should be in ReSTructured text. The filename in the git
|
|
repository should match the launchpad URL, for example a URL of
|
|
https://blueprints.launchpad.net/self-healing-sig/+spec/awesome-thing should be named
|
|
awesome-thing.rst . Please do not delete any of the sections in this
|
|
template. If you have nothing to say for a whole section, just write: None
|
|
For help with syntax, see http://sphinx-doc.org/rest.html
|
|
To test out your formatting, see http://www.tele3.cz/jbar/rest/rest.html
|
|
|
|
=======================================
|
|
The title of your self-healing use case
|
|
=======================================
|
|
|
|
..
|
|
Please fill in the blanks in this use case statement, or rephrase
|
|
as appropriate.
|
|
|
|
As a cloud operator, whenever one of my cloud's ________ has a _______
|
|
failure, I want to be notified of all affected _______. Moreover, I
|
|
want _______ in order that ________ will continue to function.
|
|
|
|
|
|
Problem description
|
|
===================
|
|
|
|
..
|
|
A more detailed description of the fault management scenario;
|
|
however it is not advised to duplicate details covered in the
|
|
sections below. If the problem is not too complex, it may be more
|
|
appropriate to simply delete this section and provide the details in
|
|
the sections below.
|
|
|
|
|
|
Fault class
|
|
===========
|
|
|
|
..
|
|
Please choose which of these classes are relevant and delete the
|
|
others. If you can think of a new class which should be listed
|
|
here, please update the template.
|
|
|
|
Hardware failure
|
|
Software error
|
|
Performance degradation
|
|
|
|
|
|
OpenStack projects used
|
|
=======================
|
|
|
|
..
|
|
Please provide a list of projects (OpenStack and otherwise) which
|
|
may be used in order to implement this use case. If no
|
|
implementation exists yet, suggestions are sufficient here.
|
|
|
|
* Zabbix
|
|
* Vitrage
|
|
* Mistral
|
|
|
|
|
|
Remediation class
|
|
=================
|
|
|
|
..
|
|
Please choose which of these classes are relevant and delete the
|
|
others. If you can think of a new class which should be listed
|
|
here, please update the template.
|
|
|
|
Proactive / preemptive
|
|
Predictive
|
|
Reactive
|
|
|
|
|
|
Fault detection
|
|
===============
|
|
|
|
..
|
|
Describe the exact nature of the fault, which components
|
|
will be needed to automatically detect it, and how they
|
|
should be configured or used for the detection.
|
|
|
|
This may include details about relevant log streams, alarms,
|
|
error codes etc.
|
|
|
|
|
|
Inputs and decision-making
|
|
==========================
|
|
|
|
..
|
|
Describe how decisions about the remediation action are taken. In
|
|
particular list any other components or inputs which may provide
|
|
additional context to help determine appropriate remediation of the
|
|
fault.
|
|
|
|
|
|
Remediation
|
|
===========
|
|
|
|
..
|
|
Describe how the fault may be remediated. If there may be different
|
|
approaches available, please list them all.
|
|
|
|
|
|
Existing implementation(s)
|
|
==========================
|
|
|
|
..
|
|
If there are one or more existing implementations of this use case,
|
|
please give as many details as possible, in order that operators can
|
|
re-implement the use case in their own clouds. However any
|
|
information is better than no information! Linking to external
|
|
documents is perfectly acceptable.
|
|
|
|
|
|
Future work
|
|
===========
|
|
|
|
..
|
|
Please link from here to any relevant specs. If a cross-project
|
|
spec is required, it can be placed under ../specs/ in this
|
|
repository.
|
|
|
|
Please also make sure that any linked specs contain back-links
|
|
to this use case for maximum discoverability.
|
|
|
|
|
|
Dependencies
|
|
============
|
|
|
|
..
|
|
- Include specific references to specs and/or blueprints in
|
|
self-healing-sig, or in other projects, that this one either depends
|
|
on or is related to.
|
|
|
|
- Does this feature require any new library dependencies or code
|
|
otherwise not included in OpenStack? Or does it depend on a specific
|
|
version of library?
|