Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

The Akraino Regional Controller provides a standardized way to install Akraino Blueprints on disparate, network connected, hardware.  It is designed to be agnostic about what is being installed, and only concerns itself with providing a standard framework for running workflows associated with Blueprints, in order to perform the lifecycle management functions of a particular Blueprint.  It does this via a REST-based API.

Child Pages

Project Technical Lead:  TBD

...

Please see Akraino Technical Community Document section 3.1.3 for more detailed information.




Committer

Committer

Company

Committer

Contact Info

 Committer BioCommitter Picture 

Self Nominate for PTL (Y/N)

 Mike HunterAT&T  mh2094@att.com

Mike is a Principal Systems Architect at AT&T who has worked on Cloud since 2011 and has worked on Akraino since its inception inside AT&T.

Along with working in Cloud, Mike has, engineered parts of SONET provisioning systems, been the lead engineer at a startup, engineered CDN solutions, designed cloud storage solutions up to exabyte scale, and designed more than a few portals for more than a few systems. He is also a self proclaimed "human factors" enthusiast.

 Image Removed

Robert EbyAT&Teby@research.att.comJohn CraigAT&TDavid PlunkettAT&Tdavid.plunkett@att.comDeepak KatariaAT&T 
 Andrew WilkinsonEricsson andrew.wilkinson@ericsson.com 



Use Case Details:


 Feature

Description

Companies Participating / Committers

Requested Release / Timeline

Informational

Akraino Regional Controller

The current Akraino Portal provides a user interface and a collection of workflows and services to execute the actions requested by the user.  This proposal is to separate the workflows and services from the portal user interface so that actions can be performed through the portal, direct REST calls from an external orchestration tool, or a

cli

CLI that could be developed as part of a different feature project.

  1. Define an
api
  1. API for the various actions that a user might request including user management, blueprint definition, blueprint deployment, monitoring, etc.
  2. Modify existing services and workflows to be initiated though the new
api
  1. API.
  2. Develop new services and workflows as needed to address common tasks required by blueprints.
  3. Coordinate with the Portal feature project to use the new
api.                                                                                                       
  1. API.
  2. Standardize the software definition of a "Blueprint" so that multiple software entities can interact with blueprints in a defined way.
  3. Standardize the software definition of a "hardware profile" to enforce some rigor in what types of hardware individual blueprints may use.                                                                                                      

AT&T

R1

Impacted Blueprint Family - Network Cloud and Radio Edge Cloud


See attachment for additional details


Presentation:

View file
nameAkraino Feature Project - Regional Controller.pptx
height250