Re: [onap-discuss] [Onap-usecasesub] Kickstart Change Management discussion for Casablanca

[Rajewski Łukasz - Korpo]

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

From: onap-usecasesub-boun...@lists.onap.org 
[mailto:onap-usecasesub-boun...@lists.onap.org] On Behalf Of Alla Goldner
Sent: Wednesday, March 21, 2018 10:16 AM
To: MAHIMKAR, AJAY (AJAY); onap-usecase...@lists.onap.org; 
onap-discuss@lists.onap.org
Cc: yuan@zte.com.cn
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:image004.png@01D3C10B.07452790]

From: 
onap-usecasesub-boun...@lists.onap.org
 [mailto:onap-usecasesub-boun...@lists.onap.org] On Behalf Of MAHIMKAR, AJAY 
(AJAY)
Sent: Wednesday, March 21, 2018 11:12 AM
To: onap-usecase...@lists.onap.org; 
onap-discuss@lists.onap.org
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
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] [Onap-usecasesub] Kickstart Change Management discussion for Casablanca

[Alla Goldner]

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:image001.png@01D3C106.06636C60]

From: onap-usecasesub-boun...@lists.onap.org 
[mailto:onap-usecasesub-boun...@lists.onap.org] On Behalf Of MAHIMKAR, AJAY 
(AJAY)
Sent: Wednesday, March 21, 2018 11:12 AM
To: onap-usecase...@lists.onap.org; onap-discuss@lists.onap.org
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
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss