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 (#15455): https://lists.onap.org/g/onap-discuss/message/15455
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]]
-=-=-=-=-=-=-=-=-=-=-=-
