This shows all VF-C components, each component is a standalone microservice, these microservice including:
-* nslcm is the core components, mainly responsible for network service management.
+* nslcm is the core component, mainly responsible for network service management.
* catalog is used to package management, including NS/VNF/PNF package management.
* Resource Manager is used to manage the instance created by VF-C and also responsible for resource granting.
-* SVNFM Driver, now VF-C has three vendor's Specific VNFM driver, including nokia/huawei/zte driver, each driver is a microservice.
-* GVNFM Driver, now have two generic VNFM driver, including gvnfm driver and juju driver.
-* SFC Driver, it migrate from Open-O seed code and now haven't been used in any usecase in ONAP.
-* Wfengine-mgrservice, it provides the workflow management service, now it has been integrated with activiti workflow and provide the unified interface to external components.
+* SVNFM Driver, now VF-C has three specific vendor VNFM drivers, including nokia/huawei/zte driver, each driver is a microservice.
+* GVNFM Driver, now has two generic VNFM driver, including gvnfm driver and juju driver.
+* SFC Driver, it migrates from Open-O seed code and now hasn't been used in any use case in ONAP.
+* Wfengine-mgrservice provides the workflow management service. Now it has been integrated with activiti workflow and provides the unified interface to external components.
* Wfengine-activiti, it is as the activiti work flow microservice.
-* Multivim-proxy,provide the multivim indirect mode proxy which can forward virtual resource requests to multivim and do some resource checking.
-* EMS Driver, used for VNF performance and alarm data collection and report to DCAE VES collector.
-* GVNFM, it includes three micorservice: vnflcm, vnfmgr and vnfres and the core is vnflcm which is responsible for VNF life cycle management.
-* DB, provide database services for each VF-C component.
+* Multivim-proxy provides the multivim indirect mode proxy which can forward virtual resource requests to multivim and does some resource checking.
+* EMS Driver is used for VNF performance and alarm data collection and reports to DCAE VES collector.
+* GVNFM includes three micorservices: vnflcm, vnfmgr and vnfres and the core is vnflcm which is responsible for VNF life cycle management.
+* DB, provides database services for each VF-C component.
Note:
- a. SFC Driver migrated from Open-O seed code and now haven't been used in any usecase in ONAP.
- b. Resource Management is used to do the resource granting, but now VF-C has been integrated with OOF, this component will be deprecated in the future release.
- c. DB provides the stand-alone database microservice in casablanca release, but now VF-C leverages OOM shared MariaDB-Gelera cluster. This repo still has redis to be used by VF-C component.
+ a. SFC Driver migrated from Open-O seed code and now hasn't been used in any usecase in ONAP. This component is deprecated from Guilin Release.
+ b. Resource Management is used to do the resource granting, but now VF-C has been integrated with OOF, this component is deprecated from Guilin Release.
+ c. DB provides the stand-alone database microservice in casablanca release, but now VF-C leverages OOM shared MariaDB-Gelera cluster. This repo still has redis to be used by VF-C component.
+ d. Catalog has been migrated to Modeling project since Frankfurt Release.
+ e. Wfengine-mgrservice & Wfengine-activiti are deprecated from Guilin Release since VF-C uses build-in workflow process.
+ f. Multivim-proxy & EMS Driver & nokia driver & juju driver are deprecated from Guilin Release since they are no longer used or maintained.
VF-C External Dependency
:width: 6.97047in
:height: 4.63208in
-As you can see in this picture, VF-C has many dependencies with other projects, such as SO, Policy, A&AI, SDC, DCAE, Multi-cloud and so on.
+As you can see in this picture, VF-C has many dependencies with other projects, such as SO, Policy, A&AI, DCAE, Multi-cloud and so on.
* NFVO provides north bound interface to SO to take part in fulfilling the orchestration and operation of end2end service and provides standard south bound interface to VNFMs.
VF-C Usecase and Workflow
-------------------------
-VF-C support VoLTE use case, vCPE use case in last three release and will support CCVPN use case in Dublin release.
+VF-C support VoLTE use case, vCPE use case in the first three releases and support CCVPN use case in Dublin release.
- VoLTE usecase information can be found : https://wiki.onap.org/pages/viewpage.action?pageId=6593603
- vCPE usecase information can be found : https://wiki.onap.org/pages/viewpage.action?pageId=3246168
Logging & Diagnostic Information
--------------------------------
-In Amsterdam release, VF-C logs are kept inside the docker containers.
+VF-C logs are kept inside the docker containers: /var/log/onap/vfc/nslcm/runtime_nslcm.log
You can get the log when the dockers start.
Where to Access Information
+++++++++++++++++++++++++++
-Use docker logs command to get the log.
+Use kubectl commands to get the log.
::
- docker logs ${docker-name}
-
+ # get the vfc-nslcm pod name
+ kubectl -n onap get pod | grep -i vfc
+ kubectl -n onap logs dev-vfc-nslcm-6dd99f94f4-vxdkc -c vfc-nslcm
+
+Or:
+::
+
+ kubectl -n onap exec -it dev-vfc-nslcm-6dd99f94f4-vxdkc -c vfc-nslcm -- bash
+ cd /var/log/onap/vfc/nslcm/
+ tail -f runtime_nslcm.log
+
Code Review / vfc / nfvo / lcm.git / commitdiff
