Great discussion. Fred,
Following up with Srini’s questions, could you also lay out your thoughts on service upgrade? Lets say I have NS with 3 VNFs with ver 1.0 and there is ver 1.1 available for all 3 VNFs. Does this “service upgrade” takes the path of successive “vnf upgrades” as listed below ? And next obvious question would be services composed of other services, which are chained with external connection points… BR, Viswa From: <[email protected]> on behalf of "FERNANDO OLIVEIRA via Lists.Onap.Org" <[email protected]> Reply-To: "[email protected]" <[email protected]>, "Oliveira, Fernando (Fred)" <[email protected]> Date: Monday, February 11, 2019 at 9:44 AM To: "Addepalli, Srinivasa R" <[email protected]>, "BULLARD, GIL" <[email protected]> Cc: "[email protected]" <[email protected]> Subject: Re: [onap-discuss] [E] VNF release management Hi Srini, In our current environment we have several approaches, but I will try to coalesce that into a single FMO ONAP model. Comments inline. Regards, Fred From: "Addepalli, Srinivasa R" <[email protected]> Date: Sunday, February 10, 2019 at 12:54 PM To: Fernando Oliveira <[email protected]>, "BULLARD, GIL" <[email protected]> Cc: "[email protected]" <[email protected]> Subject: [E] VNF release management Hi Fred and Gil, When VNF vendors make new VNF release, what is the process in which this new release is instantiated replacing the old instantiation? [FO] This should be a “change management” operation in SDC/SO. I guess new VNF release instantiation replacing the old one should consider following: * No impact to exiting traffic flows. * New traffic flows shall not use old VNF workload. * Old instantiation to get terminated only after existing traffic flows disappear. * Since new release may need more memory, cores, accelerators, I guess new release instantiation has to take advantage of placement path again. * Configuration upgrade (new image might only understand new configuration schema and hence sometimes it is required to run configuration upgrade tool provided by vendor) to transform the existing configuration. * Traffic flow management [FO] Certainly all of these need to be considered. I expect that most deployments would have geographic redundancy (GR) in N+K (legacy 1x1) config without much extra capacity available. A rolling upgrade would replace a single instance of the xNF and test before moving on to the next instance. This implies that the old and new version must be able to coexist and handle intermixed traffic flows. Also that the configuration must backwards compatible in case of fallback to the old version. At the VNF level, traffic flow management can be taken care typically using service mesh technologies (such as ISTIO for L7 and above traffic flows and NSM for L2/L3/L4 traffic flows), but these service mesh technologies need to be configured with right traffic rules upon instantiating new VNF releases). [FO] While a service mesh is likely in future xNF, it is unlikely that a single service mesh would cover the GR deployment. I would expect that other xNFs would need to be (re)configured to interact with the newly upgraded/deployed xNF. What needs to be taken care at the ONAP level? [FO] Great question!! * How do one onboard new release of VNFs? [FO] I would expect that the VNF package is onboarded the same as the previous version of the VNF package, ie SDC onboarding and cataloging. * How does user indicate that new VNFD is a new release of old VNFD? [FO] The SDC catalog should be able to associate the multiple versions of a VNF along with an indication of which have been incorporated into a Service design. * Is there any TOSCA representation? [FO] The ETSI SOL004 CSAR has version and change information. The SOL001 VNFD also has version information. How about existing SDC VNFD based on HEAT? [FO] If packaged in a SOL004 CSAR with SOL001 VNFD it would have same information. * If old release of VNF is already instantiated (once or multiple times), there are manual options of upgrade and auto upgrade? [FO] Hopefully manual modes would not be used. If it is auto upgrade, which component of ONAP shall initiate new upgrade mechanism. I guess it is SO. [FO] I expect that a “Change Service Management” would be designed in SDC that would be used by SO to change the Service that is using an existing VNF instance(s) with upgraded VNF instance(s). * Traffic flow management configuration – Since there are various technologies used in different clouds, I guess this belongs in Multi-Cloud plugins. [FO] Many possible approaches here. I expect that SDN-C, APP-C/GNF-C and Multi-Cloud could all be involved. * Since both old and new release would be there for some time together, are there any changes required in virtual inventory of A&AI? [FO] My understanding is that in A&AI the VNF versions would be understood as separate VNF instances so hopefully no changes required. * Which component is responsible to upgrade configuration? I guess this should happen before new VNF instantiation starts. [FO] I expect that SO and SDN-C/APP-C/GNF-C would be involved in the configuration. Is this a problem that is important for operators? [FO] Yes!! How is this software upgrade problem being solved in ETSI NFV MANO specifications? [FO] My understanding of the SOL005 interface supports upgrade of a VNF in a SOL001 NSD. Currently SOL003 doesn’t yet handle in-place upgrade of an existing VNF but that is under consideration. It would be great if this is considered in orchestration scenarios. [FO] Agreed. I will try to create a couple of scenarios to try to address some of these cases over the next few weeks. Thanks Srini -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15467): https://lists.onap.org/g/onap-discuss/message/15467 Mute This Topic: https://lists.onap.org/mt/29735849/21656 Group Owner: [email protected] Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
