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.
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
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.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
Project Lead: TBD
mailing list tag extensibility
Committers (Name - Email - IRC): TBD
*Link to TSC approval:
Link to approval of additional submitters: