3. Component Description:

...

The Next level of the AAF functional architecture is below:

...

Link to read the docs

The AAF internal interfaces are:
...

AAF consists of the following containers:

aaf-cass – A Cassandra container that preloads itself with AAF data
base – an intermediate container that sets up jre-alpine, adds users, additional tools (e.g., openssl) to all AAF containers
core – an intermediate container containing all AAF java parts
aaf-config – a job-based container that sets up all AAF container volumes with certificate authority (CA) configurations, key pairs, certificates and configurations. It can be stand alone, but also is used as an initContainer
aaf-agent – a job-based container for clients that sets up a client volume with key pairs, certificates and configurations
Service based Containers – these all use the aaf-config setup
- aaf-service – core API Service
- aaf-locate – tracks all AAF Service internally and globally
- aaf-oauth – supports Oauth2 behaviors of “token” and “introspect”
- aaf-cm – Certificate Manager – Reference Certificate Authority – in ONAP Test, also functions as CA
- aaf-gui – Management GUI for Apps to add Permissions, roles, etc.
- aaf-fs – HTTP service, required primarily to service certificate revocation lists (CRL), but can also be loaded with AAF relevant files for download (e.g., root.intermediate certificates)
aaf-hello – example app used to showing client how to use AAF Agent containers, CADI J2EE filters, etc.

This release, AAF adds the following capabilities:

...

AAF Locator differentiates public fully qualified domain name (FQDN) from Kubernetes FQDN

Internal Kubernetes FQDN generated when client declares its container namespace
Public FQDN are accessible for both:
- GUIs/Management outside cluster
- Non-ONAP entities outside the cluster
- Other clusters

...

...

FFS