these slides aim to improve our IT infrastructure and nothing else
- TAC discussions focused a lot in a move to GitLab CI/CD
- meanwhile skipped all new Jenkins features which would have offered the same self-maintained capabilities (see Jenkins Docker or Kubernetes providers)
- what about self-maintained project via Jenkins+Gerrit (e.g. removing shell runners as much as we can. See next slide)?
The architecture cannot stay unchanged forever
Jenkins Shell Runner Updates
- ticketing makes sense if the community asks for specific tasks (e.g. write our jenkins jobs) but quickly failed for maintainance which is on regular basics
- our runner distributions and the related software versions are becoming obsolete (see Anuket and ONAP as good example).
The community could help here. The ticketing model is partially counterproductive
factorizing jobs (global-jjb)
- is a good idea but it quickly leads to additional conditions if the runners aren’t uniformed accross LFN (e.g. python versions, distributions, etc.)
- tightly couples all the LFN projects
- asks the same quality level in global jjb as the project which would have to leverage it (e.g. upper-constraints as in ONAP or Anuket)
- forbids the project releng committer to fix issues in self-contained jobs
Seems overkilled for Anuket but we lost control
- should be a jenkins-job-builder call via tox
- executes 8 shell scripts installing lots of libraries useless for job verification (e.g. OpenStack clients) and without pinning versions (upper-constraints)
- failed in Anuket because of job-cost.sh
Let’s keep it simple and straightforward
How the community can simplify the current model decided via global jjb?
- apply the same GitLab-CI architecture principles in the existing infrastructure
- open releng-global-jjb’s meeting to the community (discussed by ODL TSC)
- allow the community to update the shell runner (new Jenkins agents? shared credentials?)
- care of the server maintainance in the budget discussions ?
Room for improvement between the community and LFN IT