Infrastructure Working Group Summary Report
Introduction
The LFN Technical Community is critically dependent on its software development tool chain for success. The standard tool chain today is Gerrit for Source Code Management (SCM) , Jenkins for Continuous Integration / Continuous Deliver (CI/CD) and Nexus for artifact repositories.
Some of these tools have been supplanted in popularity the larger open source development communities with more modern tools .
for example, most developers are now more familiar with GitHub/GitLab than gerrit and there is a growing need for CI/CD tooling that is readily compatible and supported with these tools.
At the same time as community and corporate developers are asking for GitHub/GitLab/Bitbucket compatibility there is a need to re-evaluate the cost structure for per project dedicated resources for the tool chain and whether moving to an "As A Service" model would be overall better for the LFN communities.
CNCF projects predominately utilize an "As a Service" approach where each project selects and utilizes Github, various CI/other services that meet its needs and the CNCF handles payment and negotiation of discounts and donations from the service providers. This has resulted in superior community experience at much lower costs and empowers the community to do what is best for each project. CNCF also actively surveys its maintainer community a few times a year to gauge any satisfaction issues and community needs to stay on top of things
The LFN TAC formed a working group to investigate the software development tooling and answer two questions:
Should the TAC recommend to member projects that they move off Gerrit/Jenkins/Nexus and onto a new tool chain.
Should the TAC recommend to member projects that they pursue with LF a "As A Service" mode of operation for the recommended tool chain.
This report summarizes the efforts from the LFN TAC and its member and the two recommendations requested of the working group by the TAC.
Criteria
The primary criteria to be used for recommending a tool will be the ease of use and ability for the community developers to get their job done. Changing tooling will take effort and impact resources so it should not be done lightly. A new tool chain must be better for today's community, stable and supported with a community of its own developers that will meet the ongoing needs of the LFN developers.
Easy for new and existing Developers to use
Compatible with predominate tool chains that developers are using in their corporate or community development outside of LFN
Supported
Up to date with the latest technologies (e.g. Docker container friendly , modern build system support etc)
The recommendation on "As A Service" should be based on an analysis of the costs to LFN and would be dependent on assumed pricing from the suppliers. A recommendation should include input from LF so that business negotiations on any final pricing and support would be done through LF.
Information/Experience Gathering
a. Prototyping
Team members using their project repositories obtained accounts on the various as a service tool chains and actually used them to build the code and generate artifacts.
Many tools were evaluated but not all tools work with each other equally well. The table below shows the tools and their respective role that were evaluated (demonstration and/or prototype)
SCM | CI/CD Pipeline | Repository |
---|---|---|
GitHub | CircleCI | DockerHub |
GitLab | GitLab-CI | |
BitBucket | Travic-CI | |
Zuul (Demo) | ||
OPNFV CI | ||
Drone/Drone.io |