What is clear is that VNF change management or live upgrading/updating is very complex and in the same time it is very important. It is specific to each type of VNF, so different change strategies need to be applied for them - based on such criteria like:
* is it stateful/stateless, L1-L3 or L4-L7 * is there need to copy configuration or restore some kind of snapshot * is there need to migrate traffic * what are management interfaces available * what are dependencies to other VNFs * what is decomposition into VNFC - can singular VNFC be upgraded/updated - if yes, how? * etc. What is important in my opinion is that upgrade/update of VNF (or VNFC) will not stop services that are handled by this VNF and there will be a possibility to rollback upgrade/update after unsuccessful deployment. So there is a need to have generic mechanisms that will support different change scenarios and different workflows for that. Also there is a need to schedule change in order to avoid conflicts but when ONAP will be integrated with full CI/CD pipeline for VNFs will such scheduling be required or how it will be different? Rather there is no place for manual scheduling defined by end user then because the idea of CI/CD is to perform update/upgrade quickly. Another question is how migration of traffic and configuration should look because it is definitely required for some VNFs. Moreover, now we have some LCM APIs for change management defined in APP-C that will be realized by adequate Ansible/Chef scripts - defined for each VNF type. It looks for me that many of these LCM operations could be shared between different VNF types - now they will have to be defined for each one separately (or I miss something). Changing one procedure/script, having many VNF types, would be very tedious then. If we invest in ONAP mechanisms that will support CI/CD in the future we should not force ONAP's end-user to waste time on maintenance of CI/CD loop instead... Last questions - is that all enough and which points from this list are already realized in ONAP Beijing? Workflows for sure are not. Orchestration and scheduling of change also is not supported. LCM API in APP-C? What about SDN-C and VF-C? Will Chef/Ansible scripts be enough or there should be some ONAP native functions that will be available for selection on VNF change management workflow definition level. Regards, [Logo Orange] Łukasz Rajewski, R&D Expert Orange Labs Polska, Advancend Networking Systems Agency, Warsaw Mobile: +48 519 310 854 www.orange.pl<http://www.orange.pl/> From: [email protected] [mailto:[email protected]] On Behalf Of Alla Goldner Sent: Wednesday, March 21, 2018 10:16 AM To: MAHIMKAR, AJAY (AJAY); [email protected]; [email protected] Cc: [email protected] Subject: Re: [Onap-usecasesub] Kickstart Change Management discussion for Casablanca Yuan's comment on Change management extracted from his email: Change management: To me, it is a quite clear requirement of "live upgrading", change management is too general to be understood. Most of teleco legacy equipments have thier own live upgrading capability and correspondent approach based on thier own software and hardware architecture. From my own developing experience, live upgrading is the most complicated part in teleco software. Different data storage policy and synchronization mechanism need different preparation during live upgrading. I believe virtualized infrastructure might provide some possibility to reduce the complicity of live upgrading but it is still complex when we think about data of the software which is deeply coupled with VNF internal approach. Best regards, Alla Goldner Open Network Division Amdocs Technology [cid:[email protected]] From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of MAHIMKAR, AJAY (AJAY) Sent: Wednesday, March 21, 2018 11:12 AM To: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: [Onap-usecasesub] Kickstart Change Management discussion for Casablanca Hi all: Here is an email thread to kick-start discussion on Change Management for ONAP Casablanca. Thanks, - Ajay This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at https://www.amdocs.com/about/email-disclaimer
_______________________________________________ onap-discuss mailing list [email protected] https://lists.onap.org/mailman/listinfo/onap-discuss
