1. Akraino R2 inputs, goals, & Planning
CI Subcommittee

2. April May June July Akraino Lab Timeline Lab Pod definition
Designate BP representative (PTL for most of the cases).
Work on topology requirements
Execution of Community Lab purchases
HW donation being shipped
Initial network design released
May
Receive first donations
Conclude initial rounds of Topology review
Begin physical installation of HW, including cabling
Setup server remote management
Install 6 ThunderX2 Gigabyte ARM servers
June
Issue PO's for HPE, Edgecore, Mellanox (NICS)and Cisco devices
Define acceptable usage policy
Continue Lab Topology reviews
Install 8 Wolfpass servers & 4 NUC devices Intel donation
July
Install HPE, Edgecore and Cisco devices
Issue PO for Dell servers (w/discount)
Publish acceptable usage policy
The Linux Foundation Internal Use Only
9/5/2019

3. Community Lab Pods Unicyle Nokia Intel Huawei Marvell Pod segmentation
8 physical servers (combinations of x86, Dell/HP)
Network
2 x Edge Core Leaf
1 x Cisco catalyst mgmt
Nokia
3x OCP Control nodes
9x OCP compute nodes
3x OCP storage nodes
1x rackmount storage
1x Airframe z900
1x Airframe S3048-ON
Intel
6x Compute 2 U, 36 cores
2x Storage
4x NUC devices
1 x Edge Core Leaf
Huawei
2x IoT GW AR651-A
2x uCPE AR651-X8
2x Taishan 2280
Marvell
6x Gigabyte R281-T91 (Marvell)
The Linux Foundation Internal Use Only
9/5/2019

4. What is needed to present for Pod topology?
Designated Blueprint contact (PTL on most of the cases) will request space to present at CI subcommittee, presentation must include:
Pod overview
Key Contacts
CI or CD business logic
Time frame by milestone
BoM (physical, and virtual)
Physical and logical connectivity
Detailed Communication flows and ports
Dependencies with LF services (Jenkins, Nexus, SonarQube, etc)
VPN users
The Linux Foundation Internal Use Only
9/5/2019

5. CI requirements for R2 Jenkins peering Push logs through Nexus
Usage of topics for release
Releases >= 1.0 (e.g. 1.xyz, 2.xyz etc) are reserved for BP that have been approved as Core by the TSC (considered ‘GA’ quality).
Releases <1.0 (e.g. 0.xyz etc) are reserved for projects that have not reached the Akraino Core level (i.e. anything that is in Incubation (‘alpha’ quality) and Mature (‘beta’ quality).
Enforcement of Static Code Analysis through SonarQube SaaS, WIP LF Release Engineering & Security Subcommittee.
Blueprint Validation Framework requirements.
Specifics BP requirement that might come from CI logic.
Specific BP validation lab requirements that will come from PTL’s.
The Linux Foundation Internal Use Only
9/5/2019

6. Contacts ci@lists.akraino.org Cesar Berho – Subcommittee chair
Eric Ball – LF release manager
Lincoln Lavoie – primary contact UNH IOL contract for Akraino
The Linux Foundation Internal Use Only
9/5/2019

7. Backup
The Linux Foundation Internal Use Only
9/5/2019

8. Basic CI Services
All CI services are run/maintained by the Linux Foundation
Basic layout/operation of services is similar to other LF-run sites (e.g. onap.org, acumos.org, etc.)
Gerrit: for source code (gerrit.akraino.org)
Jenkins: for code builds and unit tests (jenkins.akraino.org)
Nexus: for repositories (nexus.akraino.org)
SonarQube: for automated code inspection (sonar.akraino.org)
Wiki: for documentation (wiki.akraino.org)
Jira: for issues (jira.akraino.org)
All services are https or ssh (Gerrit)
A Linux Foundation ID is required for all services
Code moved from internal repo in end of june 2018
Running for 4 months now

9. New Projects
PTL reach out to Blueprint Validation Lab sub-committee to create project under Gerrit and in other LF infra. Including VMs or community lab share they may need.
CI/Validation sub-committee approves the request and assist PTL to access the resources.
PTL coordinates with the project team to start the development.
Projects have a list of committers who can put code into the projects
Recommend projects be named as such: <blueprint-name>_<subproject-name>
New Projects: Blueprint Validation Lab sub-committee sends an to with name of project (lower case) and list of committers
Documentation in wiki generally refers to the latest master branch code (may be overridden by documentation subcommittee).
PTL encourage to work with Blueprint Validation Framework.

10. CI Process - Gerrit Code submitted to Gerrit from the developer
Code is reviewed and voted on via the normal Gerrit code review process
Reviewers need to have permissions (assigned by LF) to merge code
LF uses a voting range of ; +2 code is eligible to merge
LF guidelines on Gerrit use:
Code Review process described here:
The idea is that the current master branch should contain a working set of code, development may not work as a group

11. CI Process - Jenkins Jenkins jobs are primarily defined by LF code
All Jenkins jobs are maintained in the ci-management project
Jobs are written as JJB (Jenkins Job Builder) templates, on a per- project basis
LF personnel code review/approve all changes to the ci-management project
More details here:
Jenkins Sandbox ( ) available to do limited testing of jobs (without Nexus)
Somewhat common with other LF sides (onap.org, acumos.org, etc) although may be running differing versions
Sandbox does not support Nexus
List what the various jobs do:
- job to build docker container (and push to nexus)
- job to test submitted code in gerriot compiles
- job to build code with maven and push to nexus
- Job to run sonarqube tests of code (via maven)
- Verify dependencies
New JJB template required for new projects

12. Development workflow Extend the pipeline for dynamic CI:
Community Lab HW.
Akraino Validation Framework.

13. CI Process - Nexus All built artifacts are stored in Nexus
nexus.akraino.org - .tar, .war, and.jar files
nexus3.akraino.org - Docker containers
CD retrieves from Nexus as the result of Gerrit API events
nexus3 can be used to retrieve Docker containers (supports Docker v2 API) – don’t need DockerHub

14. CI Process – Wiki/Sonar/Jira
Wiki is the documentation of record for Akraino
SonarQube - used to check code quality of projects so configured in Jenkins