summaryrefslogtreecommitdiffstats
path: root/docs/requirements
diff options
context:
space:
mode:
authorRyota Mibu <r-mibu@cq.jp.nec.com>2017-01-19 05:35:58 +0000
committerGerrit Code Review <gerrit@opnfv.org>2017-01-19 05:35:58 +0000
commitbb2f2a536c1362db8a933379cd01363dfe5a3d74 (patch)
tree67ad1f8c00a0243da82e7a6f514ebe1727806389 /docs/requirements
parent34674578cdbdae2a753b1cccf88959d414a676e7 (diff)
parenta0f36f238f99874baaad0fd47d9ada59cdee1cb5 (diff)
Merge "Detail more on fencing mechanisms"
Diffstat (limited to 'docs/requirements')
-rw-r--r--docs/requirements/03-architecture.rst18
1 files changed, 11 insertions, 7 deletions
diff --git a/docs/requirements/03-architecture.rst b/docs/requirements/03-architecture.rst
index 9f620e68..2774df0e 100644
--- a/docs/requirements/03-architecture.rst
+++ b/docs/requirements/03-architecture.rst
@@ -191,11 +191,15 @@ fencing, but there has not been any progress. The general description is
available here:
https://wiki.openstack.org/wiki/Fencing_Instances_of_an_Unreachable_Host
-As OpenStack does not cover fencing it is in the responsibility of the Doctor
-project to make sure fencing is done by using tools like pacemaker and by
-calling OpenStack APIs. Only after fencing is done OpenStack resources can be
-marked as down. In case there are gaps in OpenStack projects to have all
-relevant resources marked as down, those gaps need to be identified and fixed.
+OpenStack provides some mechanisms that allow fencing of faulty resources. Some
+are automatically invoked by the platform itself (e.g. Nova disables the
+compute service when libvirtd stops running, preventing new VMs to be scheduled
+to that node), while other mechanisms are consumer trigger-based actions (e.g.
+Neutron port admin-state-up). For other fencing actions not supported by
+OpenStack, the Doctor project may suggest ways to address the gap (e.g. through
+means of resourcing to external tools and orchestration methods), or
+documenting or implementing them upstream.
+
The Doctor Inspector component will be responsible of marking resources down in
the OpenStack and back up if necessary.
@@ -206,11 +210,11 @@ In the basic :ref:`uc-fault1` use case, no automatic actions will be taken by
the VIM, but all recovery actions executed by the VIM and the NFVI will be
instructed and coordinated by the Consumer.
-In a more advanced use case, the VIM shall be able to recover the failed virtual
+In a more advanced use case, the VIM may be able to recover the failed virtual
resources according to a pre-defined behavior for that resource. In principle
this means that the owner of the resource (i.e., its consumer or administrator)
can define which recovery actions shall be taken by the VIM. Examples are a
-restart of the VM, migration/evacuation of the VM, or no action.
+restart of the VM or migration/evacuation of the VM.