Page Comparison

Project Name:

• Proposed name for the project: ONAP Extensibility
• Proposed name for the project repository: extensibility

Project description:

The project will outline the requirements, use cases, guidelines, architecture and tools for extending the ONAP components. This proposed architecture will enable any network operator that is using ONAP to easily develop and extend it to their own specific business needs. The proposed architecture will not create a downstream version of ONAP, but will provide a way to extend it without the need to customize the ONAP code.Extensibility is a software engineering and systems design principle where the implementation takes future growth into consideration (From Wikipedia, the free encyclopedia). In regards to ONAP, we would like to build tools, frameworks, APIs and in some cases guidelines to ensure ONAP can be extended to specific use cases that will be developed by service providers.

This project will tackle all type of extensibility patterns:

1. Black box - the most desired type of extensibility, when the code should not be tempered, in order to achieve new functionality, or extension to existing functionality
2. White box - the most premise type of extensibility, one that is the most flexible, but also create a lot of overheads in rebasing, and merging code with the upstream
3. Grey box - a compromise between a pure white-box and a pure black-box approach, which does not rely fully on changing the source code. Programmers could be given the system’s specialization interface which lists all available abstractions for refinement and specifications on how extensions should be developed

Scope:

Many of the ONAP existing components already provide extension mechanisms, however there are gaps, inconsistencies and in general a lack of consistent approaches.  The project will provide a common set of reusable code and where code is not applicable a set of documented re-usable patterns that other components will (should) be adhere to. 

The scope will be governed by the following guideline requirements:

• ONAP components (where applicable) MUST provide a mechanism to replace the AuthN framework being used
• ONAP components (where applicable) MUST provide a mechanism to plug into an external user base (IdPs)
• ONAP components SHOULD provide where applicable a mechanism to replace other service provider interfaces e.g. AuthZ
• ONAP components MUST provide pluggable north bound interfaces
• ONAP components MUST provide pluggable south bound interfaces / adaptors
• ONAP components (where applicable) MUST provide pluggable and augmentable validation schemes
• ONAP components MUST provide a scheme for extensible and augmentable configuration
• ONAP components MUST provide an extensible and augmentable model scheme
• ONAP components with UIs where modelled entities are being shown SHOULD automatically adjust with model changes 
• ONAP components with UIs MUST ensure fields values are constrained by model entity constraints
• ONAP components with UIs MUST be rebrandable (fonts, colours, borders, dimensions, margins, padding, HTML field appearance and ICON alignment)
• ONAP components with UIs MUST be pluggable so extensions can be provided within the UIs panels 
• ONAP components MUST allow for new systems to be introduced for example Service Design & Creation distribution od model to a new component

The project will not define those exit points, but rather map it to an extension pattern, and provide a solution how to implement it.

Few examples:

• ASDC provides HEAT validation capability, a SP can decide to add new type of validation to include specific internal guidelines for its HEAT, like naming convention. This means that if there is no define architecture to extend the list of validators, adding it on top of ONAP will create a fork. 
• License model extension - every SP will want to generate different license model that is being sent to license system.

The project will define extension requirements, provide common patterns to extensions, and in some cases provide a platform that matches some of the patterns.

Project Architecture:

The architecture will focus but not be limited to:

Architecture Alignment:

 All components (where applicable) need to re-use or implement the defined patterns and any contribution will need to checked against this projects guidance.

Resources:

• Primary Contact Person: Liron Shtraichman liron.shtraichman@amdocs lironsh@amdocs.com
• Mark Pond mpond@amdocs.com
• Pamela Dragosh pdragosh@research.att.com AT&T

Key Project Facts

Project Name:

• JIRA project name: ONAP Extensibility
• JIRA project prefix: extensibility

Repo name: extensibility
Lifecycle State: Incubation
Primary Contact: TBD Yaron Olivcovitz YaronO@Amdocs.com
Project Lead: TBDYaron Olivcovitz YaronO@Amdocs.com
mailing list tag extensibility
Committers (Name - Email - IRC):TBD 

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