Table of Contents |
---|
Common Items
- Secure communication
- CBS
- Need AAF cert and deployment to be secure
- Consul interface will remain unsecure (dependent on OOM)
- CBS expose both secure/insecure to allow ServiceComponent transition
- SDK impact (client- java/python)
- DeploymentHandler->InventoryAPI
- Cloudify Interfaces
(Jack to assess impact
- CBS
- SEC-COM Open items
- Secure communication
- Topic/feed
- CBS (dependency on Consul)
- Non-root container
- Cloudify -
To be checked with DeWayne
- PolicyHandler,
Deployment-Handler, CBS, Inventory
- Cloudify -
- Security Vulnerability (review Dublin exception list and close)
- Need to be assessed for all Service components
- Need to be assessed for all Service components
- CIA
- Cloudify - CentOS (post E release)
- Deployment-handler, CBS, Inventory, Policy-Handler
- Service components
- VES +
- VES +
- S3P
- Documentation/Usability
- Performance test/bench-marking (such as response time, transaction/message rate, latency, footprint, etc. to be defined on per component)
- Application logging consistency (Manageability)
- Platform - InventoryAPI , rest may be complaint (to be verified)
- API Standardization (Usability)
- Jenkins job alignment (moving to common template) across all services
- CSIT alignment across all services
- CSIT improvement
- Moving toward global-jjb for all platform components
- Moving toward global-jjb for all service components
- CSIT alignment
- Platform CSIT (add blueprint into inventory, kick-off deployment through DH
- )
- Blueprint generator/Dmaap plugin integration (Topic standardization – pre-requisite)
- Enhance blueprint generator tool from Dublin to use Dmaap plugin and generated blueprint with associated properties by default
- Deploy components using new blueprint and validate dynamic topic/feed provisioning and configuration into services
- Depends on role (or identify setup in AAF - will need pre-configuration)
- AAF integration
- Dynamic certificate generation
- Dependent on Dublin AAF work; to be checked with Jonathan
- Dependent on Dublin AAF work; to be checked with Jonathan
- Dynamic certificate generation
- SDK library integration (Except PRH/HV-VES)
- For service components
- Policy Integration for dynamic components
- For service components to go through policy model/SDC onboarding
- CBS Look up change CBS library (remove consul dependency in lookup)
- Library update required (python and java)
- Non SDK utilized components to be updated (VESCollector/RESTConf)
- Platform components to be verified
- Docker build and tagging consistency
- dcae plugin DCAE plugin (k8splugin) compatibility in nexus
- Helm plugin in CCSDK address fixed this in R4.
- Helm chart migration (platform componentsDashboard)
- Python 3.x support (Cloudify, plugins + other dcae platform component; relates to DOC-419)
- 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.)
- Set up our plugin tox tests so that they are executed with both Python 2.7 AND Python 3.x.
- Upgrade all plugins (k8splugin/dmaap/policyplugin/relationship/postgres/helm) to support both 2.x and 3.x
- Verfiy all other platform components (CBS, PH, SNMP trap, Heartbeat)
- Upgrade to new Cloudify version expected in June (compatible Cloudify upgrade to 5.0)
- Migrate if single base image
if multiple containers - will be assessed later.
- Migrate if single base image
PM-Mapper
- Control Loop flow onboarding/integration – SDC/CLAMP/Policy
- VES Onboarding yaml registration binding with PM-Mapper configuration
- VES o/p from PM-Mapper feeding into analytics services
...