DCAE Weekly Meeting 2019 02 14 Docker Tagging

DCAE Weekly Meeting 2019 -02 -14

Docker Tagging • ONAP community settled on the following versioning model for docker images https: //wiki. onap. org/display/DW/Independent+Versioning+and+Release+Process docker tag format to align across all the teams is the following: • x. y. z-KEYWORD-yyyymmdd. Thhmmss. Z X. Y. Z follows the Semantic Versionning KEYWORD: SNAPSHOT or STAGING Example 1. 1. 2 -SNAPSHOT-20181231 T 234559 Z • Please be aware that any snapshot or stage builds which are not compliant with this naming convention will soon begin to fail as a result. • A list of non-compliant repos can be found here: https: //nexus 3. onap. org/#browse/search=repository_name%3 Ddocker. snapshot%20 AND%20 versi on%3 D*. *. %3 F

Docker release process change Migration for docker images from Nexus 3 to Docker. Hub. • • LF is working on 2 new global-jjb templates for docker verify and docker merge. The merge job will post Snapshot and Staging images directly into Docker. Hub. Releases to Docker. Hub will be made on demand as PTLs wish. For now, only PTLs will be given these permissions, but extended permissions to committers will be considered as we go. The process to release will be done manually by PTLs similarly to how LF does it (docker pull image, docker tag using release tag #. #. #, docker push to Docker. Hub). We will work with tech teams to move to the new docker templates in global-jjb and eventually remove local templates. To avoid overhead, we will only be making Docker. Hub publications of Snapshots and Staging artifacts on new merge and not on a daily basis. LF will switch to the new global-jjb jobs once it is confirmed by tech teams that the correct images are being posted in Docker. Hub. This means that some teams might have both jobs pushing to Nexus 3 and Docker. Hub at the same time and will be able to disable Nexus 3 pushes once they are comfortable.

SECCOM directions Has the Release Security/Vulnerability table been updated in the protected Security Vulnerabilities wiki space? Security Have all project containers been designed to run as a non-root user? Table in in the protected Security PTL reviews the Nexus. IQ scans for Vulnerabilities wiki space their project repos and fills out the corresponding to the latest Nexus. IQ vulnerability review table scan https: //wiki. onap. org/display/DW/ Best+Practices • The Docker and Kubernetes engines may run as root until such time as the products support non-root execution. • Applications may run as root within a container. • The process ID of a container must not run as the root ID with the exception of containers supporting ONAP features that require the container to run as the root ID. • Containers may run with root privileges. • Project containers that run as the root ID must document this in the release notes along with the functionality that requires the container to run as the root ID.

DCAE Committer Support for Service Component COMPONENTS PRIMARY COMMITTER CONTACT PRH Piotr W HV-VES Piotr J VES Vijay Data. File. Collector (DR) Tony PM-Mapper Yang? /Tony VES-Mapper Xinhui SNMPTrap Tony Heartbeat Vijay/Lusheng TCAGen 2 Vijay RESTCONF Xinhui SON-Handler Yang? /Vijay SDK Piotr W/Piotr J DL Feeder/DL Admin Tony/Vijay

DCAE Repository consolidation • DCAE repository > 30 • For future release, looking at consolidation on the DCAE repositories. • Rather than introducing separate repository for each service component, I’m considering to have multiple MS share a common repository. • For e. g – dcaegen 2/services repo (currently empty) can be targeted to host multiple ms (under same technology) with below structure. dcaegen 2/services └── components ├── dl-handler │ ├── dl-admin │ └── dl-feeder ├── microservice 1 ├── microservice 2 └── microservice 3

DCAE Weekly meeting ØSecurity Report https: //wiki. onap. org/pages/viewpage. action? page. Id=51282478