El-ALTO DISCUSSION ITEMS

Common Items

1. Secure communication  
   1. CBS
      1. Need AAF cert and deployment to be secure
      2. Consul interface will remain unsecure (dependent on OOM)
      3. CBS expose both secure/insecure to allow ServiceComponent transition
      4. SDK impact (client- java/python)
   2. DeploymentHandler->InventoryAPI
   3. Cloudify Interfaces  (Jack to assess impact)
   4. Non-root container
      1. Cloudify -  To be checked with DeWayne
      2. PolicyHandler, Deployment-Handler, CBS, Inventory
   5. Security Vulnerability (review Dublin exception list and close)
      1. Need to be assessed for all Service components  
2. CIA
   1. Cloudify - CentOS (post E release)
   2. Deployment-handler, CBS, Inventory, Policy-Handler
   3. Service components
      1. VES +   
3. S3P
   1. Documentation/Usability
   2. Performance test/bench-marking (such as response time, transaction/message rate, latency, footprint, etc. to be defined on per component)
   3. Application logging consistency (Manageability)
      1. Platform - InventoryAPI , rest may be complaint (to be verified)  
   4. API Standardization (Usability)
4. Jenkins job alignment (moving to common template)
   1. Moving toward global-jjb for all platform components
   2. Moving toward global-jjb for all service components
5. CSIT alignment
   1. Platform CSIT (add blueprint into inventory, kick-off deployment through DH)
6. Blueprint generator/Dmaap plugin integration (Topic standardization – pre-requisite)
   1. Enhance blueprint generator tool from Dublin to use Dmaap plugin and generated blueprint with associated properties by default
   2. Deploy components using new blueprint and validate dynamic topic/feed provisioning and configuration into services
      1. Depends on role (or identify setup in AAF - will need pre-configuration)
7. AAF integration
   1. Dynamic certificate generation
      1. Dependent on Dublin AAF work; to be checked with Jonathan  
8. SDK library integration (Except PRH/HV-VES)
   1. For service components
9. Policy Integration for dynamic components
   1. For service components to go through policy model/SDC onboarding
10. CBS Look up change (remove consul dependency in lookup)
    1. Library update required (python and java)
    2. Non SDK utilized components to be updated (VESCollector/RESTConf)
    3. Platform components to be verified  
11. Docker build and tagging consistency
12. DCAE plugin (k8splugin) compatibility in nexus
    1. Helm plugin in CCSDK address fixed this in R4.
13. Helm chart migration (Dashboard)
14. Python 3.x support (Cloudify, plugins + other dcae platform component; relates to DOC-419)
    1. Convert our code to be compatible with Python 3.x. (For example, using “import future” and making certain that loops work on iterators instead of lists when the API calls return iterators in 3.x.)
    2. Set up our plugin tox tests so that they are executed with both Python 2.7 AND Python 3.x.
       1. Upgrade all plugins (k8splugin/dmaap/policyplugin/relationship/postgres/helm) to support both 2.x and 3.x
       2. Verfiy all other platform components (CBS, PH, SNMP trap, Heartbeat)
15. Upgrade to new Cloudify version expected in June (compatible to 5.0)
    1. Migrate if single base image   if multiple containers - will be assessed later.
16. DCAE SDK:
    
    1. Finish DMaaP client (stabilize API, add support for DR) DCAEGEN2-1421 - Getting issue details... STATUS
       
    2. Refactor current AAI client to reflect overall SDK "look&feel"
    3. Extract monitoring API from HV-VES (KPI monitoring in Prometheus format + healthchecks)
    4. Write HV-VES events consumer client
       
17. Migrate to Java 11 (or 12?). The main reason is that Java 9+ properly identifies available memory and CPU cores inside Docker. Prior to Java 9 additional JVM options shall be set. Another benefit is that developers would gain few more language features. Also sooner or later we will need to migrate to new Java and having ElAlto a "maintentance" release it may be the perfect time. The main obstacle may be Java modularity, but in the beginning we shall be able to use old classpath instead of modulepath when running our applications.

PM-Mapper

1. Control Loop flow onboarding/integration – SDC/CLAMP/Policy
2. VES Onboarding yaml registration binding with PM-Mapper configuration
3. VES o/p from PM-Mapper feeding into analytics services

BBS-EventProcessor

1. AAI interaction to use new DCAE SDK (1.1.5)
2. Control Loop flow onboarding/integration – SDC/CLAMP/Policy
3. PNF re-registration event handling should not involve BBS-ep (update of AAI service status) to be moved into SO
4. Move PRH -> BBS-EP notification structure to VES (This will not be required if #3 is accomplished)
5. Switch to AAF based topic
6. Stress testing with replicas
7. Support event filtering from generic topic (currently using cpe_authentication topic instead of statechange)
8. ci job change to use version.properties override

VES-Mapper

1. Tool translate/simplify smooks mapping from SDC model
2. Control Loop flow onboarding/integration – SDC/CLAMP/Policy
3. Consul update (via SDK library) to support periodic polling

SON-Handler

1. Support MS scaling
2. CBS SDK integration for periodic polling

Heartbeat Service

1. Control Loop flow onboarding/integration – SDC/CLAMP/Policy
2. Logging Standardization
3. AAF integration

RESTConf Collector

1. Control Loop flow onboarding/integration – SDC/CLAMP/Policy
2. Multiple controller/truststore - AAF integration
3. Scaling support to be worked (requires single interface to external controller) - k8s plugin enhancement required

VESCollector

1. Api Standardization
2. Backlogs Jira/bugs ( DCAEGEN2-517 - Getting issue details... STATUS )
3. Performance optimization and baselining

Dashboard

Improved error handling and support necessary validation

Helm Plugin

• Requires changing nodeport for tiller; since the deployment is done from bootstrap pod, clusterip/port must also be supportable
• Existing namespace cannot be used currently
• Deployment error not being logged