diff options
| author |   Ryota Mibu <r-mibu@cq.jp.nec.com> | 2017-01-19 05:35:58 +0000 |
|---|---|---|
| committer |   Gerrit Code Review <gerrit@opnfv.org> | 2017-01-19 05:35:58 +0000 |
| commit | bb2f2a536c1362db8a933379cd01363dfe5a3d74 (patch) | |
| tree | 67ad1f8c00a0243da82e7a6f514ebe1727806389 /docs | |
| parent | 34674578cdbdae2a753b1cccf88959d414a676e7 (diff) | |
| parent | a0f36f238f99874baaad0fd47d9ada59cdee1cb5 (diff) | |
Merge "Detail more on fencing mechanisms"
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/requirements/03-architecture.rst | 18 |
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. |