- Proposed name for the project:
- Proposed name for the repository:
The Application Controller (APPC) performs functions to manage the lifecycle of VNFs and their components providing model driven configuration, abstracts cloud/VNF interfaces for repeatable actions, uses vendor agnostic mechanisms (NETCONF, Chef via Chef Server and Ansible) and enables automation.
- Model and policy driven application controller with intrinsic VNF management capabilities.
- Support of multi vendor system of VNFs with interdependence between them.
- Provide uploading capabilities of standard data model which describe the management, configuration and inter-dependencies of the VNF.
- APPC model will be based on ONAP TOSCA and Yang containing a dependency model, LCM recipes, configuration templates, policies etc.
- APPC provides multi-protocol southbound plugins, including support for NETCONF, Chef via a Chef Server, and Ansible and ability to operate through vendor specific VNFM/EMS via adaptation through a plugin.
- APPC provides a VNF configuration repository with the latest working configuration for each managed VNF instance it is responsible for.
Support for complex ONAP use cases including vVOLTE (with vEPC) and vCPE
Provide Generic VNF LCM commands for Northbound consumers (SO, Policy, CMO, DCAE, etc.)
The implementation of LCM commands will use an uploaded VNFD TOSCA model to infer an execution protocol and drive workflows
Design-time ability to attach recipes (specified by Directed Graphs, aka DGs) to specific VNF LCM commands, or "Actions" received via the Northbound APIs.
Provide a model driven configuration API composed from a Yang-based VNF configuration model and set of templates to map payloads to the VNF configuration protocol.
Provide configuration repository APIs getLatestConfig, configAudit etc.
Manage the VNF operational state including Blocking, Sequencing and Session Throttling
Provide conflict resolution for multiple LCM requests
Provide flexible deployment options such as HA, single node or geo-distributed deployment
Adaptation of additional NBI definitions established by ETSI-MANO using NFV-O to leverage existing APPC functions, including:
Modify VNF Information
Get Operation Status
Adaptation of NBI definition at the orchestration level by invoking existing orchestrator functions, including:
Create VNF Identifier
- Delete VNF Identifier
- Instantiate VNF
- Build additional DGs to implement new ETSI defined NB APIs not currently supported by APPC
- Scale VNF to Level
- Change VNF Flavour
- Heal VNF
- Support for GVNFM functionality through additional SB adapters to support:
- Bridging to a compliant S-VNFM when this functionality is provided by the VNF
- Utilize ETSI VNFD acquired from a VNF to define the configuration and management data model of the VNF.
- Support for GVNFM functionality through additional SB adapters to support:
- How does this project fit into the rest of the ONAP Architecture?
- Expansion of existing APPC ONAP component to support more complex use cases.
- Establish dependence on the Common Controller SDK to be used as the base platform for the controller.
- Depends on Service Designer for generating the model(s) and other artifacts necessary for specifying controller runtime behavior
- Depends on Multi VIM project for cloud infrastructure APIs
- How does this align with external standards/specifications?
- Inspired by ETSI NFV LCM signatures
- Use TOSCA and YANG for all model definitions.
- Use Netconf/Chef and Ansible for component southbound interface
- Are there dependencies with other open source projects?
- Opendaylight (part of ONAP controller framework)
- Primary Contact Person - Reuben Klein firstname.lastname@example.org - AT&T; Randa Maher email@example.com (AT&T)
- Avi Chapnick firstname.lastname@example.org - Amdocs
- Piyush Garg Piyush.Garg1@amdocs.com - Amdocs
- Hector Anapan email@example.com - AT&T
- Jamil Chawki firstname.lastname@example.org - Orange
- Vimal Begwani email@example.com - AT&T
- Paul Bartoli - AT&T
- Marcus Williams firstname.lastname@example.org - Intel
- Pat Velardo email@example.com - AT&T
Rahul Sharma Rahul.Sharma2@amdocs.com - Amdocs
- Joey Sullivan Joey.Sullivan@amdocs.com - Amdocs
James MacNider James.MacNider@amdocs.com - Amdocs
- Alexis de Talhouët firstname.lastname@example.org - Bell Canada
- Rashmi Pujar email@example.com - Bell Canada
- Bin Yang firstname.lastname@example.org - Wind River
- Paul Miller email@example.com - AT&T
- Alex Vul firstname.lastname@example.org - Intel
- Scott Seabolt email@example.com - AT&T
- Anand Chaturvedi firstname.lastname@example.org - A&T
- link to seed code (if applicable)
- Vendor Neutral
The current seed code has been already scanned and cleanup to remove all proprietary trademarks, logos, etc. except openecomp to be replaced by onap
Subsequent modification to the existing seed code should continue to follow the same scanning and clean up principles.
- Meets Board policy (including IPR)
Key Project Facts
- JIRA project name: Application Controller
- JIRA project prefix: APPC-
Primary Contact: Reuben Klein
mailing list tag [Should match Jira Project Prefix]
Piyush Garg - Piyush.Garg1@amdocs.com
Marcus Williams - email@example.com
Patrick Brady - firstname.lastname@example.org
Skip Wonnell - email@example.com
Randa Maher - firstname.lastname@example.org
*Link to TSC approval:
Link to approval of additional submitters:
Thanks for the proposal. Based on the TOSCA model, how do APPC cooperate with SO?
APPC expose NB LCM API SO consumes.
implementation of the LCM API uses TOSCA and DGs for the implementation.
The implementation is run using a DG which use TOSCA VNFD model for inferring the VNF inner dependencies and VNFC specific actions. similar to the role of BPEL has in open-O GVNFM (As I understand it)
Thanks for the clarification. SO parses and executes NSD, and APPC parses and execute VNFD which is transferred to a DG. Am I right?
Conceptually yes , The terms used in ECOMP are different as ETSI model which uses these terms (VNFD , NSD) is not fully adopted.
As for APPC, the VNFD is parsed and processed as part of the DG execution , so the first step in a generic DG execution will be to retrieve and parse the TOSCA , the next step is to calculate the execution order based on the dependencies , and then DG will run the specific component operations in the calculated sequences.
steps in the DG execution for a specific node type are also derived from the TOSCA and can result in netconf, restconf , Chef , Ansible or any other SB connector execution.
Thanks for the response. Let me know more about APPC.
What's the relationship between the TOSCA template and DG workflow in the App-C? Who deploy the VNF? Why is the VNF deployment and other LCM seperated?
In the comments above I explain what are the role of the TOSCA model vs the role of the DG in APPC. I would add that APPC also allows you to create specific DG for a specific VNF type which may or may not use the VNF TOSCA model.
in ECOMP APPC is not responsible for deploying the VNF, it is done by SO calling PO (Platform orchestrator ) .
There is nothing blocking from APPC handling the deployment of the VNF. in ECOMP HEAT is being used for instantiation and PO is the abstraction used for interacting with HEAT engine.
Hi Avi, thanks for your reply( I think you reply to my questions).
Firstly In the SO project, it also include the scale/heal/update base on declarative tosca model. I am very confused with the two projects scope.
Second could you explain how the DG use the TOSCA Model if it needed? In my mind, there is no TOSCA workflow engine in the App-C seed code.
As for SO , I assume it will be responsible for the heal in scope of a service.
APPC expose the heal in scope of a VNF within a service.
for instance , in a closed loop policy , the policy designer can choose to call APPC heal API in some conditions and SO heal API in other conditions. the SO heal can delegate the call to PPC heal if it require specific VNF healing.
APPC use TOSCA for inferring the VNF contained VNFC dependency and actions.
it use it to derive the generic flow , same as a TOSCA orchestrator will do .
I would use the explanation your peer from ZTE used on other thread
"the TOSCA Specification doesn't restrict the implementation of orchestrator as long as it can interpret a TOSCA service template or a TOSCA CSAR in order to instantiate and deploy the described application in a Cloud", no matter the workflow is implemented by Python(Aria is that case), BPMN or any other language"
same here . APPC is using DG for the TOSCA workflow implementation as there is not restriction to use TOSCA orchestrator.
I have added a comment regarding the Vendor Neutral section.
Suggested tools or anything else equivalent: FOSSology, Blackduck suite, Sonar, CheckMarx.
I have updated the JIRA project name/prefix to align with jira.onap.org
I also would like to consider the following JIRA story as part of this proposal:
APPC-3 - Getting issue details... STATUS if the following epic is approved COMMON-10 - Getting issue details... STATUS
According to MSO architecture comments, the connection between MSO and APP-C is not available since the App-C adapter in MSO is commented in MSO pom.xml.
The proposed scope and architecture "Provide Generic VNF LCM commands for Northbound consumers (SO, Policy, CMO, DCAE, etc.)" indicate there is a connection between SO and APP-C through the DMAAP event bus and API Handler. Where is the APP-C Adapter in this scenario? Who provides the APP-C adapter, from MSO or APP-C?
I agree that SO should define and implement an APP-C adaptor based on "Generic VNF LCM commands for Northbound consumers". I believe it has been captured by DeWayne Filppi in the Service Orchestrator (5/14/17) project proposal (see ONAP projects dependency section)
Yes, this is the intent, at least in the case of the pure TOSCA path (recall that SO can go pure BPM as well). I'm also curious about the Northbound interface in relation to TOSCA outputs. Will these be made available to facilitate service chaining?
Hi Catherine, Thanks. I saw the Service Orchestrator defined several dependencies including APP-C, which giving an impression that the APP-C Adaptor belongs to the APP-C project. As you said, SO should define and implement an APP-C adaptor.
The diagram shows DMaaP as an API endpoint (Northbound) for the SO. Yet the MSB project claims it's role is message routing. Confused.
I would recommend to look at the feedback from Ram, Brian, HuanBing regarding DMaaP and MSB
Microservices Bus Proposal(5/12/17)
Although it is not used today, the appc adapter is the target to be used for the MSO interaction
I could see VF-C also aligned to handle LCM functionalities of the VNF in ONAP architecture.
Can someone explain clearly how is APPC different from VF-C? Also clearly list out the responsibilities of APPC & VF-C in ONAP?