AAI R3 Architecture Review

Owned by James Forsyth
Last updated: Aug 14, 2018
2 min read

Delta from R2

AAI will follow very similar architecture to R2, and its position in the larger ONAP architecture remains consistent.  Some additional microservices will be added, and we will make schema / edge rule changes in support of the various R3 use cases and functional requirements.  

AAI-1353: Support CCVPN use case in AAIClosed

AAI-1350: Cloud-agnostic Placement/Networking & Homing Policies (Phase 1 - Casablanca MVP, Phase 2 - Stretch Goal)Closed

AAI-1419: Schema Ingest LibraryClosed - the schema ingest library allows for a streamlined approach to using the AAI schema.  Also allows for multiple OXM files so users can insert their own types at run-time.

AAI-1478: Scale Out Use Case Support in AAI - R3Closed



Other updates:

AAI will use AAF for RBAC - currently planning on using Basic auth, since we haven't had success integrating with AAF to prove out a 2-way x509 cert exchange with AAF.  We believe that this close to API freeze, forcing all clients to 2-way TLS is too steep a climb.  We believe there also may be potential for integration with the proposed Pluggable Security Microservice, proposed by @Andrew Baxter

AAI-32: Integrate with AAFClosed

New microservices:



enricher

Enables complementing AT&T data with federated data from additional sources. Exsiting seed code contributed from ECOMP

AAI-1331: AAI EnricherClosed

cacher

The Response Caching Microservice (Cacher) is built to deliver multiple mechanisms of making API calls and populating the responses into a JSON datastore. Existing seed code from ECOMP

AAI-1337: AAI CacherClosed

validation

Microservice used to invoke validation mechanism. Used by POMBA, exsiting seed code from ECOMP

AAI-1348: POMBA: add "aai/validation" repo/jenkins/docker-merge/sonar/nexus/nexus3 LF infrastructureClosed



S3P Updates

AAI R3 Platform Maturity

  1. Security

    1. AAI core:

    2. AAI UI:

    3. AAI used 1-way TLS on APIs in Beijing and will continue in Casablanca.  

    4. AAI → Cassandra w/ TLS
      SONAR code coverage.  Plan is to maintain >50% on all repos.

    5. Nexus IQ scans: Plan is to reach target of 0 severe or critical exceptions 

  2. Scalability and Resiliency

    1. Relying on kubernetes to manage AAI resiliency, multiple instances of each stateless application server

    2. Single-site failover

  3. Performance and stability

    1. Focus to this point has been security and scalability/resiliency.  We will participate in the integration team's performance testing

    2. Seeking to meet 72 stability soak test

  4. Manageablility

    1. Logging/EELF - Will adopt the ONAP logging specification to the best of our ability.  We are currently very close, may not get the custom headers for this release.

    2. AAI services can be instantiated in < 1hr

  5. Usability

    1. Follow the new guidelines for providing API documentation

    2. User guide for the AAI UI

Information/Data Model Alignment

AAI's schema/edge rules will not change for the Casablanca release to align with the modelling subcommittee's proposed information/data/runtime service and instance models.  AAI is participating in the discussions and will map existing data objects to the approved clean versions when they are approved, targeting Dublin for potential changes. 

MODELING-61: A&AI IM and DMClosed