Project Name:

  • Proposed name for the project: Common Controller Framework (ccfwk)
  • Proposed name for the repositor(y/ies): ccfwk

*This project provides building blocks for controllers, so we will renaming this project to Common Controller SDK.

  • Proposed name for the project: Common Controller SDK (ccsdk)
  • Proposed name for the repositor(y/ies): ccsdk

Project description:

This project provides a common set of reusable code that can be used across multiple controllers. The code could be used in other components but would not be an end solution for use cases by itself and would not be deployed on its own. 

    • For example, the SDN-C , APP-C, DCAE, ONAP Operations Manager and ONAP controller can reuse common pieces from this framework.

While controllers are encouraged to use the common controller SDK libraries, usage of this common code is optional.  Our goal is to provide code that is sufficiently flexible that there is no need for controllers to implement their own custom solutions, but we recognize that there are valid reasons why specific controllers might need to implement their own solutions and would not prevent them from doing so.

Challenges

Some challenges that need to be addressed for this project include:

  • Version control : multiple controllers might have different release schedules and hence might use different versions of common framework.
    • Backward compatibility will be critical
  • Common API
  • Code Reuse

Scope:

  • In scope: 
    • SDN-C core : core platform needed to execute directed graphs
    • SDN-C adaptors : set of adaptors used by directed graphs to talk to other ONAP components or external services, including other controllers
    • SDN-C northbound : northbound interfaces to SDN-C
    • SDN-C plugins : add-on functionality used by directed graphs
    • SDN-C oam : tools for operations, administration and maintenance of controller
    • Common microservice / VF lifecycle management capabilities
    • Common health checks
    • Common APIs
    • Common logging
    • Common model management (e.g. Yang, TOSCA)
    • Common resource management (e.g. IP management, DNS naming, keystore, containers)

Architecture Alignment:

  • How does this project fit into the rest of the ONAP Architecture?
    • Please Include architecture diagram if possible
    • What other ONAP projects does this project depend on?
      • May have a close relationship with OAM (ONAP Administration and Management)
  • How does this align with external standards/specifications?
    • N/A
  • Are there dependencies with other open source projects?
    • Aria/Cloudify
    • Consul
    • OpenDaylight

Resources:

  • John Murray (AT&T)
  • Dan Timoney (AT&T)
  • Grace Lian (Intel)
  • Arun Yerra (Futurewei Technologies)
  • Margaret Chiosi (Futurewei Technologies)
  • Patrick Liu (Futurewei Technologies)
  • Cheng (Ian) Liu - Futurewei Technologies
  • Jing Wang - Futurewei Technologies
  • Marcus Williams (Intel)
  • Jie Feng(ZTE)
  • Liang Wu(ZTE)
  • Maopeng Zhang(ZTE)
  • Yan Yang(China Mobile,yangyanyj@chinamobile.com)
  • John Ng (AT&T, johnng@att.com)

  • Habib Torab (AT&T, ht1496@att.com)

  • Luke Parker (lparker@amdocs.com)
  • Rashmi Pujar (Bell Canada)
  • Alexis de Talhouet (Bell Canada)
  • Avi Chapnick (Amdocs)

  • Sridhar Ramaswamy (Brocade, srics.r@gmail.com)

  • Xinhui Li(Beijing, lxinhui@vmware.com

  • Hong Guan (AT&T)

  • Earle West (AT&T - ew8463@att.com)
  • Moshe Hoadley moshehoa@amdocs.com

Other Information:

  • link to seed code (if applicable) 
    • SDN-C parts based on sdnc project in gerrit.onap.org
    • AT&T Controller code
  • Vendor Neutral
    • if the proposal is coming from an existing proprietary codebase, have you ensured that all proprietary trademarks, logos, product names, etc., have been removed?
  • Meets Board policy (including IPR)

Use the above information to create a key project facts section on your project page

Key Project Facts

Project Name:

  • JIRA project name: common-controller-SDK
  • JIRA project prefix: ccsdk

Repo name: ccsdk
Lifecycle State: Incubation
Primary Contact: Chris Rath  (AT&T)
Project Lead: Dan Timoney (AT&T)
mailing list tag ccfwk
Committers (Name - Email - IRC):

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

  • No labels

10 Comments

  1. maopeng zhang

    what's the Common model management function (e.g. Yang, TOSCA)?  what's the realtionship between this function and the model project's model parser and tools?

    1. Dan Timoney

      There might be some overlap here that we'll have to resolve.  In this project, when we talk about common model management, I think of that as the tools/libraries that the various controllers will need in order to be able to consume models, such as TOSCA or Yang.   I'm not sure if that is what the modeling project had in mind with their reference to parsers, or if they were talking more about tools that model designers would use to create and validate their models prior to publication.

      1. Cang Chen

        XCore will no more used?  And what about SOMF?

  2. Christopher Rath

    There are a few comments on the Initial Project Proposal Feedback page I would like to address:


    1. Will this project provide source codes or binaries(libs) for controller projects?
      1. I believe this project will provide both source code and binaries, including links to external open source projects
    2. Could this project proposal clarify what exactly is "Common microservice/VF lifecycle management"
      1. This would include providing a common orchestration functions for deployment, update, undeployment, common health-check facilities, etc. for any component that can be deployed as part of or on the ONAP platform.
    3. Lack of link to seed code
      1. This is part of a new project we have been developing but was not included in the initial open source release, so the seed code is not visible yet.
    4. Should be part of common platform umbrella project
      1. I don't see anything in the proposal list that looks like a "Common Platform umbrella project".  This proposal is about creating an umbrella project for code related to controllers.

  3. Earle West

    The diagram needs to be updated to use the "ccsdk" as opposed to the former "ccfwk" language.

    Is there any reason this common automated distribution capability (using models) should't also be the vehicle by which VNFs are deployed by "Service Orchestrator?"   Isn't it helpful to think of the ONAP capability as just another app?


    • Support TOSCA models in native format as distributed by SDC
    • Perform lifecycle operations based on a declarative TOSCA model, including: 
      • Deployment
      • Undeployment
      • Scale (Out, In)
      • Heal
      • Software Upgrade (various forms)

    1. Avi Chapnick

      Currently APPC which is supposed to derive/use this SDK have the functionality of VNF LCM implementation using models (TOSCA). 

       are you guys considering to have TOSCA driven logic to be implemented in the common SDK layer? 

      what would be the interface exposed to the actual controllers in that case?

      in DCAE project proposal is mentioned that the cloudify manager will be part of the SDK project and I dont see it in this proposal ,  can anyone explain this discrepancy  

  4. Jason Hunt

    There are a couple parts of this proposal that I would like to see addressed to ensure that there is not duplicative functions:

    • "common microservices" is overlap with MSB.  Both seem to be providing reusable capabilities to other projects around microservices.  Can you please work with the MSB team to ensure that only one project is creating these capabilities?
    • are you in sync with the OOM and MSB teams on who is doing health checks?  I believe they both have it in their scope
    • If "VF lifecycle management" refers to the management of ONAP components, I believe that this needs to be centrally controlled by OOM.  If multiple components can spin up their own containers, there will be no central knowledge of what ONAP pieces are running.

    1. HuabingZhao

      +1

      These two lines don't make sense here, should we remove them from the proposal?

      • Common microservice / VF lifecycle management capabilities
      • Common health checks

    2. Christopher Rath

      Yes, we are having discussions about MSB and the Common Controller SDK.

      The Common Controller SDK is not a runtime component, so it will not actually be making the healthcheck calls.  It should be thought of as a reusable library of code and should include functions to allow controllers to do healthchecks on their components.

      I believe you have some comments in the DCAE page about central control of ONAP components as well.  As Lusheng has noted, we want the capability to control components hierarchically, as well as emphasize a distinction between the ONAP platform components and components related to services that are running on the platform.  I believe it is possible for OOM to have a high-level view of DCAE as an aggregate component, while delegating control of its subcomponents.  From an operations perspective, this delegation does not even have to be visible, (i.e. double-click on the DCAE component and now I am seeing the details of the DCAE components).

  5. Patrick Liu

    what can I find more information about SDNC-parent?