Project Name:

  • Proposed name for the project: APPC
  • Proposed name for the repository: appc

Project description:

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.

Scope

      • 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:

        • Scale VNF

        • Terminate VNF

        • Query VNF

        • Operate VNF

        • 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.

Proposed Architecture:

Architecture Alignment:

  • 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)

Resources:

Other Information:

  • link to seed code (if applicable)
    https://gerrit.onap.org/r/#/admin/projects/appc
  • 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

Project Name:

Repo name:appc
Lifecycle State:Seed
Primary Contact: Reuben Klein
Project Lead:
mailing list tag [Should match Jira Project Prefix] 
Committers:
Piyush Garg - Piyush.Garg1@amdocs.com

Marcus Williams - marcus.williams@intel.com 

Patrick Brady - pb071s@att.com

Skip Wonnell - kw5258@att.com

Randa Maher - rx196w@att.com


*Link to TSC approval: 
Link to approval of additional submitters: 


  • No labels

18 Comments

  1. Xiaojun XIE

    Thanks for the proposal. Based on the TOSCA model, how do APPC cooperate with SO?

    1. Avi Chapnick

      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)

      1. Xiaojun XIE

        Thanks for the clarification. SO parses and executes NSD, and APPC parses and execute VNFD which is transferred to a DG. Am I right?

        1. Avi Chapnick

          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.

          1. Xiaojun XIE

            Thanks for the response. Let me know more about APPC.

  2. maopeng zhang

    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?

  3. Avi Chapnick

    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.


    1. maopeng zhang

      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.

      Thank you

      1. Avi Chapnick

        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. 


  4. Catherine Lefevre

    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

  5. Catherine Lefevre

    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

  6. Byung-Woo Jun

    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?

    1. Catherine Lefevre

      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)

      1. DeWayne Filppi

        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?

  7. Byung-Woo Jun

    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.

  8. DeWayne Filppi

    The diagram shows DMaaP as an API endpoint (Northbound) for the SO.  Yet the MSB project claims it's role is message routing.  Confused.

  9. Catherine Lefevre

    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

  10. Kishore Thota

    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?