Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Current »

Project Proposal Template

Project Name:

  • Proposed name for the project: Network Function Change Management
  • Proposed name for the repository: NFCM

Project description:

  • Network Functions (NFs) like any software have to be updated periodically (to support new features, fix bugs, security holes, etc). However, complex dependencies, upgrade mechanisms, SLAs etc require that the upgrades or changes are managed carefully. For example, NFs may by upgraded in-place or through a scale out and replace mechanism. The change may require draining, redirection, or load-balancing of traffic. It may also involve multiple NFs whose changes need to be coordinated for service continuity. It will also require capabilities like A/B testing, pre- and post- change testing, scheduling, etc. This project, Network Function Change management, provides the capability to design, schedule and manage configuration changes and software upgrades of network functions managed by ONAP. This project exposes the existing capabilities of ONAP components (like that of the service orchestrator and the controller) to users to help them stitch workflows that use these capabilities for managing NF changes or upgrades.

Scope:

  • This project provides users with the ability to design workflows based on a suite of existing capabilities exposed by other ONAP components. For example, a user can make calls to a controller to execute actions, to A&AI to get inventory status, and existing orchestration flows, and combine these calls to achieve a higher level orchestration function. We envision that this design capability will get integrated with the SD&C environment.
  • This project provides a capability to deploy (and undeploy) and upgrade the designed workflows to an execution environment (e.g., the service orchestrator). This assumes that the execution environment provides APIs to perform these functions.
  • This project provides runtime management (start, pause, resume, stop, rollback) and monitoring of the workflows.  This project provides a portal for a user to come in and manually control these workflows or monitor them or track the history of workflows that have been executed. Again we assume that the execution environment provides APIs to perform these functions. We also assume that other ONAP components (e.g., Policy) can trigger one of these workflows as part of a control loop action.
  • This project provides capabilities for scheduling workflows. The schedule could range across a subset of the instances of an NF, across instances of multiple NFs or combinations therein.
  • This project provides capabilities for selecting the type and instances of the NFs that need to be associated with the workflows (as well as for scheduling).
  • This project will document the best practices for End-to-End workflow design.


Architecture Alignment:

  • How does this project fit into the rest of the ONAP Architecture?
    • The figures below show sample E2E flows that will be executed as part of NF Change. 



    • What other ONAP projects does this project depend on?
  • SD&C
  • Portal
  • Service Orchestrator
  • Controllers
  • A&AI
  • Policy
  • DCAE
  • Optimization Framework



  • How does this align with external standards/specifications?
    • APIs/Interfaces
    • Information/data models
  • Are there dependencies with other open source projects?
    • APIs/Interfaces
    • Integration Testing
    • etc.

Resources:

  • Primary Contact Person
  • Names, gerrit IDs, and company affiliations of the committers
  • Names and affiliations of any other contributors
  • Project Roles (include RACI chart, if applicable)

Other Information:

  • link to seed code (if applicable)
    • There exists initial seed code, but not yet part of the seed code respository.
  • 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:
  • JIRA project prefix:

Repo name:
Lifecycle State:
Primary Contact:Emmanouil Mavrogiorgis (emaurog@research.att.com)
Project Lead: :Emmanouil Mavrogiorgis
mailing list tag [Should match Jira Project Prefix] 
Committers: Emmanouil Mavrogiorgis,Giri Rana, Ajay Mahimkar, Bo Han
foo@bar.com
baz@qux.com
*Link to TSC approval: 
Link to approval of additional submitters: 


  • No labels