diff options
Diffstat (limited to 'doc/03-Functional_Requirements.rst')
| -rw-r--r-- | doc/03-Functional_Requirements.rst | 148 |
1 files changed, 82 insertions, 66 deletions
diff --git a/doc/03-Functional_Requirements.rst b/doc/03-Functional_Requirements.rst index a380180..c0695bb 100644 --- a/doc/03-Functional_Requirements.rst +++ b/doc/03-Functional_Requirements.rst @@ -42,43 +42,46 @@ service outage. It may include the following work: - The upgrade campaign should indicate any point in the upgrade when coordination with the users (VNFs) is required. -==[hujie]Depends on the attributes of the object being upgraded, the -upgrade plan may be slitted into step(s) and/or sub-plan(s), and even -more small sub-plans in design phase. The plan(s) or sub-plan(s) my -include step(s) or sub-plan(s).== +.. <hujie> Depends on the attributes of the object being upgraded, the + upgrade plan may be slitted into step(s) and/or sub-plan(s), and even + more small sub-plans in design phase. The plan(s) or sub-plan(s) my + include step(s) or sub-plan(s). Validation the upgrade plan / Checking the pre-requisites of System( offline / online) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -| The upgrade plan should be validated before the execution by testing - it in a test environment which is similar to the product environment. -| ==[MT]However it could also mean that we can identify some properties +The upgrade plan should be validated before the execution by testing +it in a test environment which is similar to the product environment. + +.. <MT> However it could also mean that we can identify some properties that it should satisfy e.g. what operations can or cannot be executed simultaneously like never take out two VMs of the same VNF. -| Another question is if it requires that the system is in a particular + +.. <MT> Another question is if it requires that the system is in a particular state when the upgrade is applied. I.e. if there's certain amount of redundancy in the system, migration is enabled for VMs, when the NFVI is upgraded the VIM is healthy, when the VIM is upgraded the NFVI is healthy, etc. -| I'm not sure what online validation means: Is it the validation of the + +.. <MT> I'm not sure what online validation means: Is it the validation of the upgrade plan/campaign or the validation of the system that it is in a state that the upgrade can be performed without too much risk?== -| Before the upgrade plan being executed, the system heathly of the - online product environment should be checked and confirmed to satisfy - the requirements which were described in the upgrade plan. The - sysinfo, e.g. which included system alarms, performance statistics and - diagnostic logs, will be collected and analyized. It is required to - resolve all of the system faults or exclud the unhealthy part before - executing the upgrade plan. -| ==[hujie] Text merged.== +Before the upgrade plan being executed, the system healthy of the +online product environment should be checked and confirmed to satisfy +the requirements which were described in the upgrade plan. The +sysinfo, e.g. which included system alarms, performance statistics and +diagnostic logs, will be collected and analogized. It is required to +resolve all of the system faults or exclude the unhealthy part before +executing the upgrade plan. + Backup/Snapshot (online) ^^^^^^^^^^^^^^^^^^^^^^^^ For avoid loss of data when a unsuccessful upgrade was encountered, the -data should be backuped and the system state snapshot should be taken -before the excution of upgrade plan. This would be considered in the +data should be back-upped and the system state snapshot should be taken +before the execution of upgrade plan. This would be considered in the upgrade plan. Several backups/Snapshots may be generated and stored before the single @@ -88,40 +91,43 @@ considered: 1. running version files for each node. 2. system components' configuration file and database. 3. image and storage, if it is necessary. - ==[MT] Does 3 imply VNF image and storage? I.e. VNF state and data?== -| ==[hujie] The following text is derived from previous "4. Negotiate - with the VNF if it's ready for the upgrade"== +.. <MT> Does 3 imply VNF image and storage? I.e. VNF state and data?== + +.. <hujie> The following text is derived from previous "4. Negotiate + with the VNF if it's ready for the upgrade" -| Although the upper layer, which include VNFs and VNFMs, is out of the - scope of Escalator, but it is still recommended to let it ready for a - smooth system upgrade. The escalator could not guarantee the safe of - VNFs. The upper layer should have some safe guard mechanism in design, - and ready for avoiding failure in system upgrade. +Although the upper layer, which include VNFs and VNFMs, is out of the +scope of Escalator, but it is still recommended to let it ready for a +smooth system upgrade. The escalator could not guarantee the safe of +VNFs. The upper layer should have some safe guard mechanism in design, +and ready for avoiding failure in system upgrade. Execution (online) ^^^^^^^^^^^^^^^^^^ -| The execution of upgrade plan should be a dynamical procedure which is +The execution of upgrade plan should be a dynamical procedure which is controlled by Escalator. -| ==[hujie] Revised text to be general.== + +.. <hujie> Revised text to be general.== 1. It is required to supporting execution ether in sequence or in parallel. -2. It is required to checke the result of the execution and take the +2. It is required to check the result of the execution and take the action according the situation and the policies in the upgrade plan. 3. It is required to execute properly on various configurations of system object. I.e. stand-alone, HA, etc. -4. It is required to excecute on the designated different parts of the +4. It is required to execute on the designated different parts of the system. I.e. physical server, virtualized server, rack, chassis, cluster, even different geographical places. Testing (online) ^^^^^^^^^^^^^^^^ -| The testing after upgrade the whole system or parts of system to make - sure the upgraded system(object) is working normally. -| ==[hujie] Revised text to be general.== +The testing after upgrade the whole system or parts of system to make +sure the upgraded system(object) is working normally. + +.. <hujie> Revised text to be general. 1. It is recommended to run the prepared test cases to see if the functionalities are available without any problem. @@ -132,9 +138,10 @@ Testing (online) Restore/Roll-back (online) ^^^^^^^^^^^^^^^^^^^^^^^^^^ -| When upgrade is failure unfortunately, a quick system restore or system - roll-back should be taken to recovery the system and the services. -| ==[hujie] Revised text to be general.== +When upgrade is failure unfortunately, a quick system restore or system +roll-back should be taken to recovery the system and the services. + +.. <hujie> Revised text to be general. 1. It is recommend to support system restore from backup when upgrade was failed. @@ -144,25 +151,29 @@ Restore/Roll-back (online) Monitoring (online) ^^^^^^^^^^^^^^^^^^^ -| Escalator should continually monitor the process of upgrade. It is - keeping update status of each module, each node, each cluster into a - status table during upgrade. -| ==[hujie] Revised text to be general.== +Escalator should continually monitor the process of upgrade. It is +keeping update status of each module, each node, each cluster into a +status table during upgrade. + +.. <hujie> Revised text to be general. 1. It is required to collect the status of every objects being upgraded - and sending abnormal alerms during the upgrade. + and sending abnormal alarms during the upgrade. 2. It is recommend to reuse the existing monitoring system, like alarm. 3. It is recommend to support pro-actively query. 4. It is recommend to support passively wait for notification. -| **Two possible ways for monitoring:** -| **Pro-Actively Query** requires NFVI/VIM provides proper API or CLI - interface. If Escalator serves as a service, it should pass on these - interfaces. -| **Passively Wait for Notification** requires Escalator provides - callback interface, which could be used by NFVI/VIM systems or upgrade - agent to send back notification. -| [hujie] I am not sure why not to subscribe the notification. +**Two possible ways for monitoring:** + +**Pro-Actively Query** requires NFVI/VIM provides proper API or CLI +interface. If Escalator serves as a service, it should pass on these +interfaces. + +**Passively Wait for Notification** requires Escalator provides +callback interface, which could be used by NFVI/VIM systems or upgrade +agent to send back notification. + +.. <hujie> I am not sure why not to subscribe the notification. Logging (online) ^^^^^^^^^^^^^^^^ @@ -188,13 +199,14 @@ escalator's actions for avoiding unauthorized operations. Requirements on Object being upgraded ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -| ==We can develop BPs in future from requirements of this section and - gap analysis for upper stream projects== -| Escalator focus on smooth upgrade. In practical implementation, it - might be combined with installer/deplorer, or act as an independent - tool/service. In either way, it requires targeting systems(NFVI and - VIM) are developed/deployed in a way that Escalator could perform - upgrade on them. +.. <hujie> We can develop BPs in future from requirements of this section and + gap analysis for upper stream projects + +Escalator focus on smooth upgrade. In practical implementation, it +might be combined with installer/deplorer, or act as an independent +tool/service. In either way, it requires targeting systems(NFVI and +VIM) are developed/deployed in a way that Escalator could perform +upgrade on them. On NFVI system, live-migration is likely used to maintain availability because OPNFV would like to make HA transparent from end user. This @@ -202,23 +214,27 @@ requires VIM system being able to put compute node into maintenance mode and then isolated from normal service. Otherwise, new NFVI instances might risk at being schedule into the upgrading node. -| On VIM system, availability is likely achieved by redundancy. This - impose less requirements on system/services being upgrade (see PVA - comments in early version). However, there should be a way to put the - target system into standby mode. Because starting upgrade on the - master node in a cluster is likely a bad idea. -| ==[hujie] Revised text to be general.== +On VIM system, availability is likely achieved by redundancy. This +impose less requirements on system/services being upgrade (see PVA +comments in early version). However, there should be a way to put the +target system into standby mode. Because starting upgrade on the +master node in a cluster is likely a bad idea. + +.. <hujie>Revised text to be general. 1. It is required for NFVI/VIM to support **service handover** mechanism that minimize interruption to 0.001%(i.e. 99.999% service availability). Possible implementations are live-migration, redundant deployment, etc, (Note: for VIM, interruption could be less restrictive) + 2. It is required for NFVI/VIM to restore the early version in a efficient way, such as **snapshot**. + 3. It is required for NFVI/VIM to **migration data** efficiently between base and upgraded system. - ==[hujie] What is exact meaning of "base" here?== + 4. It is recommend for NFV/VIM's interface to support upgrade - orchestration, e.g. reading/setting system state - ==[hujie] I am not sure if it reflect the previous text.== + orchestration, e.g. reading/setting system state. + + |