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)
- Please Include architecture diagram if possible
- 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):
- Dan Timoney - AT&T ( dtimoney@att.com )
Jun Nicolas Hu - AT&T ( jh245g@att.com )
- Jack Lucas - AT&T ( jflucas@research.att.com )
- Arun Sarat Yerra - Futurewei Technologies ( arun.yerra@huawei.com )
- Cheng (Ian) Liu - Futurewei Technologies ( cheng.liu1@huawei.com )
- Jing Wang - Futurewei Technologies ( jing.wang5@huwei.com )
- Ritu Sood - Intel ( Ritu.Sood@intel.com )
- Marcus Williams - Intel ( marcus.williams@intel.com )
- Jie Feng - ZTE ( feng.jie2@zte.com.cn )
- Luke Parker ( lparker@amdocs.com )
- Liang Wu-ZTE ( wu.liang@zte.com.cn )
- maopeng zhang-ZTE( zhang.maopeng1@zte.com.cn )
- Linying Huan - ZTE (huan.linying@zte.com.cn)
- Hong Guan - AT&T (hg4105@att.com)
- Yan Yang(China Mobile,yangyanyj@chinamobile.com)
- Sujing Zhang-ZTE (zhang.sujing@zte.com.cn)
*Link to TSC approval:
Link to approval of additional submitters:
10 Comments
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?
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.
Cang Chen
XCore will no more used? And what about SOMF?
Christopher Rath
There are a few comments on the Initial Project Proposal Feedback page I would like to address:
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?
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
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:
user-9823d
+1
These two lines don't make sense here, should we remove them from the proposal?
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).
Patrick Liu
what can I find more information about SDNC-parent?