Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: added the overview

Overview

When performing Control Loop actions such as reboot, scale out, modify config, etc., the API's used by the controllers and orchestrators (eg. SO, VFC, APPC) vary in design, implementation and complexity. This creates the problem of significant software development for every API supported by the controller/orchestrator that needs to be invoked during Control Loop enforcement by the Policy Platform. In addition, any company that uses the ONAP Platform internally may have their own custom controllers/orchestrators as well as custom applications (eg. Email notification, ticketing system, Q-Chat) that the company wishes to be used during Control Loop event processing. Again, significant development will be required in the Policy Platform to support those custom API's.

The proposal is to design a simplified, extendable event-based notification messaging format that could be supported by all the applications involved in Control Loop event processing. Such a simplified messaging structure would also advance the ONAP platform towards performance gains for future Control Loops that require Control Loop Operations to perform in under X milliseconds. With a simplified messaging format, faster versions of the messaging platform could be plugged in as desired. Eg. a faster version of Dmaap, kafka, vert.x, etc. installed in an edge cloud location.

The development of the Common Notification messaging format would be simple, lightweight and can be shared by all the controllers, orchestrators, and custom application components. Since the controllers, orchestrators and applications already have to develop their API, all those components have to do is implement reception of the messages and either translate to their current API. Ideally, those components may be able to remove their API layers and simplify their codebase.