summaryrefslogtreecommitdiffstats
path: root/doc/Escalator_Requirement.rst
diff options
context:
space:
mode:
authorJie Hu <hu.jie@zte.com.cn>2015-09-18 02:21:10 +0800
committerJie Hu <hu.jie@zte.com.cn>2015-09-18 01:30:11 +0000
commit2308ebcfe07451bf15e7722365e71c7b542c5f48 (patch)
treea58a8e50e9b1a2a8839bbad5b59e777e422f173c /doc/Escalator_Requirement.rst
parentcb53884d99c0f3479cbd6f12a29f5cdef8ec7334 (diff)
ESCALATOR-5: Fix syntax error of rst files in doc
Signed-off-by: Jie Hu <hu.jie@zte.com.cn> Change-Id: I908362cd0fc0104036f3d50a1f6a7a6c288d300d
Diffstat (limited to 'doc/Escalator_Requirement.rst')
-rw-r--r--doc/Escalator_Requirement.rst814
1 files changed, 0 insertions, 814 deletions
diff --git a/doc/Escalator_Requirement.rst b/doc/Escalator_Requirement.rst
deleted file mode 100644
index e80a11d..0000000
--- a/doc/Escalator_Requirement.rst
+++ /dev/null
@@ -1,814 +0,0 @@
-Draft Escalator Requirement v0.4
-================================
-
-Authors:
---------
-
-| Jie Hu (ZTE, hu.jie@zte.com.cn)
-| Qiao Fu (China Mobile, fuqiao@chinamobile.com)
-| Ulrich Kleber (Huawei, Ulrich.Kleber@huawei.com)
-| Maria Toeroe (Ericsson, maria.toeroe@ericsson.com)
-| Sama, Malla Reddy (DOCOMO, sama@docomolab-euro.com)
-| Zhong Chao (ZTE, chao.zhong@zte.com.cn)
-| Julien Zhang (ZTE, zhang.jun3g@zte.com.cn)
-| Yuri Yuan (ZTE, yuan.yue@zte.com.cn)
-| Zhipeng Huang (Huawei, huangzhipeng@huawei.com)
-| Jia Meng (ZTE, meng.jia@zte.com.cn)
-| Liyi Meng (Ericsson, liyi.meng@ericsson.com)
-| Pasi Vaananen (Stratus, pasi.vaananen@stratus.com)
-
-1. Scope
---------
-
-| This document describes the user requirements on the smooth upgrade
- function of the NFVI and VIM with respect to the upgrades of the OPNFV
- platform from one version to another. Smooth upgrade means that the
- upgrade results in no service outage for the end-users. This requires
- that the process of the upgrade is automatically carried out by a tool
- (code name: Escalator) with pre-configured data. The upgrade process
- includes preparation, validation, execution, monitoring and
- conclusion.
-| ==[MT] While it is good to have a tool for the entire upgrade process,
- but it is a challenging task, so maybe we shouldn't require automation
- for the entire process right away. Automation is essential at
- execution.==
-| ==[hujie] Maybe we can analysis information flows of the upgrade tool,
- abstract the basic / essential actions from the tool (or tools), and
- map them to a command set of NFVI / VIM's interfaces.==
-
-The requirements are defined in a stepwise approach, i.e. in the first
-phase focusing on the upgrade of the VIM then widening the scope to the
-NFVI.
-
-The requirements may apply to different NFV functions (NFVI, or VIM, or
-both of them) . They will be classified in the Appendix of this
-document.
-
-2. General Requirements Background and terminology
---------------------------------------------------
-
-==[MT] At the moment 2.1-2.3 seem to be more background sections than
-requirements. Should we rename this part?==
-
-2.1 Terminologies and definitions
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-- **NFVI** is abbreviation for Network Function Virtualization
- Infrastructure; sometimes it is also referred as data plane in this
- document.
-- **VIM** is abbreviation for Virtual Infrastructure Management;
- sometimes it is also referred as control plane in this document.
-- **Operators** are network service providers and Virtual Network
- Function (VNF) providers.
-- **End-Users** are subscribers of Operator's services.
-- **Network Service** is a service provided by an Operator to its
- End-users using a set of (virtualized) Network Functions
-- **Infrastructure Services** are those provided by the NFV
- Infrastructure and the Management & Orchestration functions to the
- VNFs. I.e. these are the virtual resources as perceived by the VNFs.
-- **Smooth Upgrade** means that the upgrade results in no service
- outage for the end-users.
-- **Rolling Upgrade** is an upgrade strategy that upgrades each node or
- a subset of nodes in a wave rolling style through the data centre. It
- is a popular upgrade strategy to maintains service availability.
-- **Parallel Universe** is an upgrade strategy that creates and deploys
- a new universe - a system with the new configuration - while the old
- system continues running. The state of the old system is transferred
- to the new system after sufficient testing of the later.
-- **Infrastructure Resource Model** ==(suggested by MT)== is identified
- as: physical resources, virtualization facility resources and virtual
- resources.
-- **Physical Resources** are the hardware of the infrastructure, may
- also includes the firmware that enable the hardware.
-- **Virtual Resources** are resources provided as services built on top
- of the physical resources via the virtualization facilities; in our
- case, they are the components that VNF entities are built on, e.g.
- the VMs, virtual switches, virtual routers, virtual disks etc
- ==[MT] I don't think the VNF is the virtual resource. Virtual
- resources are the VMs, virtual switches, virtual routers, virtual
- disks etc. The VNF uses them, but I don't think they are equal. The
- VIM doesn't manage the VNF, but it does manage virtual resources.==
-- **Visualization Facilities** are resources that enable the creation
- of virtual environments on top of the physical resources, e.g.
- hypervisor, OpenStack, etc.
-
-2.2 Upgrade Objects
-~~~~~~~~~~~~~~~~~~~
-
-2.2.1 Physical Resource
-^^^^^^^^^^^^^^^^^^^^^^^
-
-| Most of the cloud infrastructures support dynamic addition/removal of
- hardware. A hardware upgrade could be done by removing the old
- hardware node and adding the new one. This will not be in the scope of
- this project.
-| ==[MT] Does this mean that we are excluding firmware upgrades too?==
-
-2.2.2 Virtual Resources
-^^^^^^^^^^^^^^^^^^^^^^^
-
-| Virtual resource upgrade mainly done by users. OPNFV may facilitate
- the activity, but suggest to have it in long term roadmap instead of
- initiate release.
-| ==[MT] same comment here: I don't think the VNF is the virtual
- resource. Virtual resources are the VMs, virtual switches, virtual
- routers, virtual disks etc. The VNF uses them, but I don't think they
- are equal. For example if by some reason the hypervisor is changed and
- the current VMs cannot be migrated to the new hypervisor, they are
- incompatible, then the VMs need to be upgraded too. This is not
- something the NFVI user (i.e. VNFs ) would even know about.==
-
-2.2.3 Virtualization Facility Resources
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-| Based on the functionality they provide, virtualization facility
- resources could be divided into computing node, networking node,
- storage node and management node.
-| The possible upgrade objects in these nodes are addressed below:
- (Note: hardware based virtualization may considered as virtualization
- facility resource, but from escalator perspective, it is better
- considered it as part of hardware upgrade. )
-
-**Computing node**
-
-#. OS Kernel
-#. Hypvervisor and virtual switch
-#. Other kernel modules, like driver
-#. User space software packages, like nova-compute agents and other
- control plane programs
-
-| Updating 1 and 2 will cause the loss of virtualzation functionality of
- the compute node, which may lead to data plane services interruption
- if the virtual resource is not redudant.
-| Updating 3 might result the same.
-| Updating 4 might lead to control plane services interruption if not an
- HA deployment.
-
-**Networking node**
-
-#. OS kernel, optional, not all switch/router allow you to upgrade its
- OS since it is more like a firmware than a generic OS.
-#. User space software package, like neutron agents and other control
- plane programs
-
-| Updating 1 if allowed will cause a node reboot and therefore leads to
- data plane services interruption if the virtual resource is not
- redudant.
-| Updating 2 might lead to control plane services interruption if not an
- HA deployment.
-
-**Storage node**
-
-#. OS kernel, optional, not all storage node allow you to upgrade its OS
- since it is more like a firmware than a generic OS.
-#. Kernel modules
-#. User space software packages, control plane programs
-
-| Updating 1 if allowed will cause a node reboot and therefore leads to
- data plane services interruption if the virtual resource is not
- redudant.
-| Update 2 might result in the same.
-| Updating 3 might lead to control plane services interruption if not an
- HA deployment.
-
-**Management node**
-
-#. OS Kernel
-#. Kernel modules, like driver
-#. User space software packages, like database, message queue and
- control plane programs.
-
-| Updating 1 will cause a node reboot and therefore leads to control
- plane services interruption if not an HA deployment. Updating 2 might
- result in the same.
-| Updating 3 might lead to control plane services interruption if not an
- HA deployment.
-
-2.3 Upgrade Span
-~~~~~~~~~~~~~~~~
-
-| **Major Upgrade**
-| Upgrades between major releases may introducing significent changes in
- function, configuration and data, such as the upgrade of OPNFV from
- Arno to Brahmaputra.
-
-| **Minor Upgrade**
-| Upgrades inside one major releases which would not leads to changing
- the stucture of the platform and may not infect the schema of the
- system data.
-
-2.4 Upgrade Granularity
-~~~~~~~~~~~~~~~~~~~~~~~
-
-2.4.1 Physical/Hardware Dimension
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Support full / partial upgrade for data centre, cluster, zone. Because
-of the upgrade of a data centre or a zone, it may be divided into
-several batches. The upgrade of a cloud environment (cluster) may also
-be partial. For example, in one cloud environment running a number of
-VNFs, we may just try one of them to check the stability and
-performance, before we upgrade all of them.
-
-2.4.2 Software Dimension
-^^^^^^^^^^^^^^^^^^^^^^^^
-
-- The upgrade of host OS or kernel may need a 'hot migration'
-- The upgrade of OpenStack’s components
- i.the one-shot upgrade of all components
- ii.the partial upgrade (or bugfix patch) which only affects some
- components (e.g., computing, storage, network, database, message
- queue, etc.)
-
-| ==[MT] this section seems to overlap with 2.1.==
-| I can see the following dimensions for the software
-
-- different software packages
-- different funtions - Considering that the target versions of all
- software are compatible the upgrade needs to ensure that any
- dependencies between SW and therefore packages are taken into account
- in the upgrade plan, i.e. no version mismatch occurs during the
- upgrade therefore dependencies are not broken
-- same function - This is an upgrade specific question if different
- versions can coexist in the system when a SW is being upgraded from
- one version to another. This is particularly important for stateful
- functions e.g. storage, networking, control services. The upgrade
- method must consider the compatibility of the redundant entities.
-
-- different versions of the same software package
-- major version changes - they may introduce incompatibilities. Even
- when there are backward compatibility requirements changes may cause
- issues at graceful rollback
-- minor version changes - they must not introduce incompatibility
- between versions, these should be primarily bug fixes, so live
- patches should be possible
-
-- different installations of the same software package
-- using different installation options - they may reflect different
- users with different needs so redundancy issues are less likely
- between installations of different options; but they could be the
- reflection of the heterogeneous system in which case they may provide
- redundancy for higher availability, i.e. deeper inspection is needed
-- using the same installation options - they often reflect that the are
- used by redundant entities across space
-
-- different distribution possibilities in space - same or different
- availability zones, multi-site, geo-redundancy
-
-- different entities running from the same installation of a software
- package
-- using different startup options - they may reflect different users so
- redundancy may not be an issues between them
-- using same startup options - they often reflect redundant
- entities====
-
-3.5 Upgrade duration
-~~~~~~~~~~~~~~~~~~~~
-
-As the OPNFV end-users are primarily Telco operators, the network
-services provided by the VNFs deployed on the NFVI should meet the
-requirement of 'Carrier Grade'.
-
-In telecommunication, a "carrier grade" or"carrier class" refers to a
-system, or a hardware or software component that is extremely reliable,
-well tested and proven in its capabilities. Carrier grade systems are
-tested and engineered to meet or exceed "five nines" high availability
-standards, and provide very fast fault recovery through redundancy
-(normally less than 50 milliseconds). [from wikipedia.org]
-
-"five nines" means working all the time in ONE YEAR except 5'15".
-
-We have learnt that a well prepared upgrade of OpenStack needs 10
-minutes. The major time slot in the outage time is used spent on
-synchronizing the database. [from ' Ten minutes OpenStack Upgrade? Done!
-' by Symantec]
-
-This 10 minutes of downtime of OpenStack however did not impact the
-users, i.e. the VMs running on the compute nodes. This was the outage of
-the control plane only. On the other hand with respect to the
-preparations this was a manually tailored upgrade specific to the
-particular deployment and the versions of each OpenStack service.
-
-The project targets to achieve a more generic methodology, which however
-requires that the upgrade objects fulfill ceratin requirements. Since
-this is only possible on the long run we target first upgrades from
-version to version for the different VIM services.
-
-**Questions:**
-
-#. | Can we manage to upgrade OPNFV in only 5 minutes?
- | ==[MT] The first question is whether we have the same carrier grade
- requirement on the control plane as on the user plane. I.e. how
- much control plane outage we can/willing to tolerate?
- | In the above case probably if the database is only half of the size
- we can do the upgrade in 5 minutes, but is that good? It also means
- that if the database is twice as much then the outage is 20
- minutes.
- | For the user plane we should go for less as with two release yearly
- that means 10 minutes outage per year.==
- | ==[Malla] 10 minutes outage per year to the users? Plus, if we take
- control plane into the consideration, then total outage will be
- more than 10 minute in whole network, right?==
- | ==[MT] The control plane outage does not have to cause outage to
- the users, but it may of course depending on the size of the system
- as it's more likely that there's a failure that needs to be handled
- by the control plane.==
-
-#. | Is it acceptable for end users ? Such as a planed service
- interruption will lasting more than ten minutes for software
- upgrade.
- | ==[MT] For user plane, no it's not acceptable in case of
- carrier-grade. The 5' 15" downtime should include unplanned and
- planned downtimes.==
- | ==[Malla] I go agree with Maria, it is not acceptable.==
-
-#. | Will any VNFs still working well when VIM is down?
- | ==[MT] In case of OpenStack it seems yes. .:)==
-
-2.5.1 The maximum duration of an upgrade
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-| The duration of an upgrade is related to and proportional with the
- scale and the complexity of the OPNFV platform as well as the
- granularity (in function and in space) of the upgrade.
-| [Malla] Also, if is a partial upgrade like module upgrade, it depends
- also on the OPNFV modules and their tight connection entites as well.
-
-2.5.2 The maximum duration of a rollback when an upgrade is failed - this should be about rollback duration
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-| The duration of a rollback is short than the corresponding upgrade. It
- depends on the duration of restore the software and configue data from
- pre-upgrade backup / snapshot.
-| ==[MT] During the upgrade process two types of failure may happen:
-| In case we can recover from the failure by undoing the upgrade
- actions it is possible to roll back the already executed part of the
- upgrade in graceful manner introducing no more service outage than
- what was introduced during the upgrade. Such a graceful rollback
- requires typically the same amount of time as the executed portion of
- the upgrade and impose minimal state/data loss.==
-| ==[MT] Requirement: It should be possible to roll back gracefully the
- failed upgrade of stateful services of the control plane.
-| In case we cannot recover from the failure by just undoing the
- upgrade actions, we have to restore the upgraded entities from their
- backed up state. In other terms the system falls back to an earlier
- state, which is typically a faster recovery procedure than graceful
- rollback and depending on the statefulness of the entities involved it
- may result in significant state/data loss.==
-| **Two possible types of failures can happen during an upgrade**
-
-#. We can recover from the failure that occured in the upgrade process:
- In this case, a graceful rolling back of the executed part of the
- upgrade may be possible which would "undo" the executed part in a
- similar fashion. Thus, such a roll back introduces no more service
- outage during an upgrade than the executed part introduced. This
- process typically requires the same amount of time as the executed
- portion of the upgrade and impose minimal state/data loss.
-#. We cannot recover from the failure that occured in the upgrade
- process: In this case, the system needs to fall back to an earlier
- consistent state by reloading this backed-up state. This is typically
- a faster recovery procedure than the graceful rollback, but can cause
- state/data loss. The state/data loss usually depends on the
- statefulness of the entities whose state is restored from the backup.
-
-2.5.3 The maximum duration of a VNF interruption
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-| Since not the entire process of a smooth upgrade will affect the VNFs,
- the duration of the VNF interruption may be shorter than the duration
- of the upgrade. In some cases, the VNF running without the control
- from of the VIM is acceptable.
-| ==[MT] Should require explicitly that the NFVI should be able to
- provide its services to the VNFs independent of the control plane?==
-| ==[MT] Requirement: The upgrade of the control plane must not cause
- interruption of the NFVI services provided to the VNFs.==
-| ==[MT] With respect to carrier-grade the yearly service outage of the
- VNF should not exceed 5' 15" regardless whether it is planned or
- unplanned outage. Considering the HA requirements TL-9000 requires an
- ent-to-end service recovery time of 15 seconds based on which the ETSI
- GS NFV-REL 001 V1.1.1 (2015-01) document defines three service
- availability levels (SAL). The proposed example service recovery times
- for these levels are:
-| SAL1: 5-6 seconds
-| SAL2: 10-15 seconds
-| SAL3: 20-25 seconds==
-| ==[Pva] my comment was actually that the downtime metrics of the
- underlying elements, components and services are small fraction of the
- total E2E service availability time. No-one on the E2E service path
- will get the whole downtime allocation (in this context it includes
- upgrade process related outages for the services provided by VIM etc.
- elements that are subject to upgrade process).==
-| ==[MT] So what you are saying is that the upgrade of any entity
- (component, service) shouldn't cause even this much service
- interruption. This was the reason I brought these figures here as well
- that they are posing some kind of upper-upper boundary. Ideally the
- interruption is in the millisecond range i.e. no more than a
- switchover or a live migration.==
-| ==[MT] Requirement: Any interruption caused to the VNF by the upgrade
- of the NFVI should be in the sub-second range.==
-
-==[MT] In the future we also need to consider the upgrade of the NFVI,
-i.e. HW, firmware, hypervisors, host OS etc.==
-
-3. Functional Considerations
-----------------------------
-
-3.1 Requirement of Escalator's Basic Actions
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-This section describes the basic functions may required by Escalator.
-
-3.1.1 Preparation (offline)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-This is the design phase when the upgrade plan (or upgrade campaign) is
-being designed so that it can be executed automatically with minimal
-service outage. It may include the following work:
-
-#. Check the dependencies of the software modules and their impact,
- backward compatibilities to figure out the appropriate upgrade method
- and ordering.
-#. Find out if a rolling upgrade could be planned with several rolling
- steps to avoid any service outage due to the upgrade some
- parts/services at the same time.
-#. Collect the proper version files and check the integration for
- upgrading.
-#. The preparation step should produce an output (i.e. upgrade
- campaign/plan), which is executable automatically in an NFV Famawork
- and which can be validated before execution.
-
- - The upgrade campaign should not be referring to scalable entities
- directly, but allow for adaptation to the system configuration and
- state at any given moment.
- - The upgrade campaign should describe the ordering of the upgrade
- of different entities so that dependencies, redundancies can be
- maintained during the upgrade execution
- - The upgrade campaign should provide information about the
- applicable recovery procedures and their ordering.
- - The upgrade campaign should consider information about the
- verification/testing procedures to be performed during the upgrade
- so that upgrade failures can be detected as soon as possible and
- the appropriate recovery procedure can be identified and applied.
- - The upgrade campaign should provide information on the expected
- execution time so that hanging execution can be identified
- - 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).==
-
-3.1.2 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
- 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
- state when the upgrade is applied. I.e. if there's certain amount of
- redundacy 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
- 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.==
-
-3.1.3 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
-upgrade plan.
-
-Several backups/Snapshots may be generated and stored before the single
-steps of changes. The following data/files are required to be
-considered:
-
-#. running version files for each node.
-#. system components' configuration file and database.
-#. 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"==
-| 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 garanttee the safe of
- VNFs. The upper layer should have some safe guard mechanism in design,
- and ready for avoiding failure in system upgrade.
-
-3.1.4 Execution (online)
-^^^^^^^^^^^^^^^^^^^^^^^^
-
-| The execution of upgrade plan should be a dynamical procedure which is
- controlled by Escalator.
-| ==[hujie] Revised text to be general.==
-
-#. It is required to supporting execution ether in sequence or in
- parallel.
-#. It is required to checke the result of the execution and take the
- action according the situation and the policies in the upgrade plan.
-#. It is required to execute properly on various configurations of
- system object. I.e. stand-alone, HA, etc.
-#. It is required to excecute on the designated different parts of the
- system. I.e. physical server, virtualized server, rack, chassis,
- cluster, even different geographical places.
-
-3.1.5 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.==
-
-#. It is recommended to run the prepared test cases to see if the
- functionalities are availiable without any problem.
-#. It is recommended to check the sysinfo, e.g. system alarms,
- performance statistics and diagnostic logs to see if there are any
- abnormal.
-
-3.1.6 Restore/Rollback (online)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-| When upgrade is failure unfortunatly, a quick system restore or system
- rollback should be taken to recovery the system and the services.
-| ==[hujie] Revised text to be general.==
-
-#. It is recommend to support system restore from backup when upgrade
- was failed.
-#. It is recommend to support gracefull rollback with reverse order
- steps if possible.
-
-3.1.7 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.==
-
-#. It is required to collect the status of every objects being upgraded
- and sending abnormal alerms during the upgrade.
-#. It is recommend to reuse the existing monitoring system, like alarm.
-#. It is recommend to support pro-actively query.
-#. 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.
-
-3.1.8 Logging (online)
-^^^^^^^^^^^^^^^^^^^^^^
-
-Record the information generated by escalator into log files. The log
-file is used for manual diagnostic of exceptions.
-
-#. It is required to support logging.
-#. It is recommended to include time stamp, object id, action name,
- error code, etc.
-
-3.1.9 Administrative Control (online)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Administrative Control is used for control the privilege to start any
-escalator's actions for avoding unauthorized operations.
-
-#. It is required to support administrative control mechenism
-#. It is recommed to reuse the system's own secure system.
-#. It is required to avoid conflicts when the system's own secure system
- being upgraded.
-
-3.2 Requirements on system object being upgraded
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-| ==We can develope BPs in future from req of this section and GA for
- upper stream projects==
-| Escalator focus on smooth upgrade. In practical implementation, it
- might be combined with installer/deployer, 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
-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.==
-
-#. 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)
-#. It is required for NFVI/VIM to restore the early verion in a efficent
- way, such as **snapshot**.
-#. It is required for NFVI/VIM to **migration data** efficiently between
- base and upgraded system.
- ==[hujie] What is exact meaning of "base" here?==
-#. It is recomend 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.==
-
-4. Use Cases
-------------
-
-This section describes the use cases to verify the requirements of
-Escalator.
-
-4.1 Upgrade a system with minimal configuration
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-A minimal configuration system is normally depolyed for experimental or
-developement ussage, such as a OPNFV test bed. Althouth it dose not have
-large workload, but it is a typical system to be upgraded frequently.
-
-4.2 Upgrade a system with HA configuration
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-A HA configuration system is very popular in the operator's data centre.
-And it is a typical product environment. It always running 7 \* 24 a
-week with VNFs running on it to provide services to the end users.
-
-4.3 Upgrade a system with Multi-Site configuration
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Upgrade in one site may cause service interruption to other site, if
-both sites are depended and sharing the same modules/data base (e.g. a
-keystone for both sites).
-
-If a site failure during an upgrade, the rollback missing any minimal
-state/data loss can cause an affect/failure to the depended site.
-
-==Consider one site of ARNO release first. Then, multi-site in the
-future.==
-
-5. RA of Escalator
-------------------
-
-This section describes the reference architecture, the function blocks,
-the function entities of Escalator for the reader to well understand how
-the basic functions be organized.
-
-6. Information Flows
---------------------
-
-| This section describes the information flows among the function
- entities when Escalator is in actions.
-| We should consider a generic procedure / frameworks of upgrading. And
- may provide a plugin interface for specialized tasks
-
-7. Interfaces
--------------
-
-This section describes the required interfaces of Escalator.
-
-7.1 Manual Interface (CLI / GUI)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-7.2 RESTful API
-~~~~~~~~~~~~~~~
-
-To support 3.3 Negotiate with the VNF if it's ready for the upgrade
-
-7.3 Configuration File
-~~~~~~~~~~~~~~~~~~~~~~
-
-This section will suggest a format of the configuration files and how to
-deal with it.
-
-7.4 Log File
-------------
-
-This section will suggest a format of the log files and how to deal with
-it.
-
-8. Requirements from other OPNFV projects
------------------------------------------
-
-| We have created a questionnaire for collecting other projects
- requirments
- (https://docs.google.com/forms/d/11o1mt15zcq0WBtXYK0n6lKF8XuIzQTwvv8ePTjmcoF0/viewform?usp=send_form),
- please advertise it.
-| ==[hujie] Can we force other OPNFV projects to complete the survey by
- using JIRA dependence?==
-
-8.1 Doctor Project
-~~~~~~~~~~~~~~~~~~
-
-| ==Note: This scenario could be out of scope in Escalator project, but
- having the option to support this should be better to align with
- Doctor requirements.==
-| The scope of Doctor project also covers maintenance scenario in which
- 1) the VIM administorator requests host maintenance to VIM, 2) VIM
- will notifiy it to consumer such as VNFM to trigger application level
- migration or switching active-standby nodes, and 3) VIM waits responce
- from the consumer for a short while.
-
-- VIM should send out notification of VM migration to consumer (VNFM)
- as abstracted message like "maintenance".
-- VIM could wait VM migration until it receives "VM ready to
- maintenance" message from the owner (VNFM)
-
-8.2 HA Project
-~~~~~~~~~~~~~~
-
-8.3 Multi-site Project
-~~~~~~~~~~~~~~~~~~~~~~
-
-- Escalator upgrade one site should at least not lead to the other site
- API token validation failed.
-
-9. Reference
-------------
-
-| [1] ETSI GS NFV 002 (V1.1.1): “Architectural Framework”
-| [2] ETSI GS NFV 003 (V1.1.1): "Terminology for Main Concepts in NFV".
-| [3] ETSI GS NFV-SWA001:“Virtual Network Function Architecture”
-| [4] ETSI GS NFV-MAN001:“Management and Orchestration”
-| [5] ETSI GS NFV-REL001:"Resiliency Requirements"
-| [6] QuEST Forum TL-9000:"Quality Management System Requirement
- Handbook"
-| [7] Service Availabilty Forum AIS:"Software Management Framework"
-
-10. Useful Working Drafts of ETSI NFV
--------------------------------------
-
-| Access them with your own ETSI account, please DO NOT disclose the
- content.
-| [1] Migrate Virtualised Compute Resource operation @ 7.3.1.8
-| ftp://docbox.etsi.org/ISG/NFV/Open/Drafts/IFA005_Or-Vi_ref_point_Spec/NFV-IFA005v070.zip
-| [2] Reliability issues during NFV Software upgrade and improvement
- mechanisms @ 8
-| ftp://@docbox.etsi.org/ISG/NFV/Open/Drafts/REL003_E2E_reliability_models/NFV-REL003v030.zip
-
-Appendix
---------
-
-A.1 Impact Analysis
-~~~~~~~~~~~~~~~~~~~
-
-Upgrading the different software modules may cause different impact on
-the availability of the infrastracture resources and even on the service
-continuity of the vNFs.
-
-**Software modules in the computing nodes**
-
-#. Host OS patch
- ==[MT] As SW module, we should list the host OS and maybe ====its
- drivers as well. From upgrade persepctive do we limit host OS
- upgrades to patches only?==
-#. Hypervisor, such as KVM, QEMU, XEN, libvirt
-#. Openstack agent in computing nodes (like Nova agent, Ceilometer
- agent...)
-
-**Software modules in network nodes**
-
-#. Neutron L2/L3 agent
-#. OVS, SR-IOV Driver
-
-**Software modules storage nodes**
-
-#. Ceph
-
-The table below analyses such an impact - considering a single instance
-of each software module - from the following aspects:
-
-- the function which will be lost during upgrade,
-- the duration of the loss of this specific function,
-- if this causes the loss of the vNF function,
-- if it causes incompatibility in the different parts of the software,
-- what should be backed up before the upgrade,
-- the duration of restoration time if the upgrade fails
-
-| These values provided come from internal testing and based on some
- assumptions, they may vary depending on the deployment techniques.
- Please feel free to add if you find more efficient values during your
- testing.
-| https://wiki.opnfv.org/_media/upgrade_analysis_v0.5.xlsx
-| Note that no redundancy of the software modules is considered in the
- table.