Anuket Weekly Technical Discussions - 2023.10.25

Anuket Project

Anuket Weekly Technical Discussions - 2023.10.25

Participants

  • @Cédric Ollivier 

  • @Gergely Csatari 

Antitrust policies

Anuket Specifications in RTD and repo split

Anuket aims to produce GSMA documents per stream also rendered by Readthedocs (RTD).

  • all stream documentations should be standalone and published both in HTML to RTD and in DOCX/PDF for GSMA

  • ideally the main doc is just an umbrella listing the document per stream (note: it also contains specific documentation per stream) - only needed for RTD and has no meaning in GSMA

  • all RST could be on the same git tree as every RTD project settings redefined setup.py and conf.py which were in their specific dirs - but RTD dropped this capabilities

  • we now have to use the .readthedocs.yaml which must be unique and under root

Splitting the git tree is the only solution which doesn't diverge to our RTD+GSMA targets

  • only managing local builds via tox wouldn't help having the documentation on RTD

  • having a single documentation project would diverge from our GSMA target and would ask for many many manual editing of the GSMA documents. it would be such a regression compared for GSMA NG133

Pros/Cons splitting the git repo as it was discussed mostly from the beginning

  • Pros: it has been done in minutes by @Cédric Ollivier  by keeping the full history of the projects

  • Pros: it fixes our current doc issues! and without any change in our documentation

  • Pros: it will help fine tuning the git rights according to the contributions per stream (and not falsy globally as today)

  • Cons: it will ask to publish the right change in the right repo and to create several PRs for overall changes (theme, tox version, etc.) - Nothing compared to Anuket renaming, to the wiki and Jenkins issues after DNS changes and software updates

Here are some useful links which would have led the discussions:

Conclusions

  • We are good to split the repos if we can create a governance to keep the documentation look and feel consistent and share the burden of managing the repos

Anuket CI/CD

A few reminders:

  •  All Software projects represented at TSC clearly stated in favor of Gerrit+Jenkins 1 year ago

  • Jenkins has been down for several months multiple times a year

  • The community was unable to help because of missing Jenkins rights or credentials on the host

  • Functest and Xtesting are in production. This project cannot wait CI/CD for many months

  • Before Jenkins breakdown, Anuket Jobs were fully rewritten to improve the portability

  • @Cédric Ollivier as Anuket Gerrit stream rights as Releng committer and because of his contributions (byw +ODL Gerrit stream rights too)

  • All Job history, crucial for GSMA NG.133, was lost when switching from build.opnfv.org to jenkins.anuket.io → HUGE impact to GSMA

A few technical details:

  • Multiple Jenkins can vote on the same Gerrit patchset (see Zuul in OpenStack)

  • Many Jobs can even duplicated such as Xtesting integration jobs which doesn't ask for a specific SUT or a single source (ex: docker image builds)

  • OPNFV has been build in a community lab spirit in which Jenkins runners or even Jenkins can be distributed in the community

  • Functest has his own servers to verify it and they have been used for all the OPNFV projects since LFN servers were down

  • CI/CD works now thanks to the new Jenkins and its runner maintained by Orange

Next:

  • a deep analysis to which jobs should be where or even duplicated to have a safe CI/CD not only depending on unmaintained services or builders

  • keep cleaning the obsolete Jenkins jobs

  • remove github actions which were not asked by the software projects

Notes

  • Orange Jenkins server

    • 2500 functest jobs

    • barometer

    • NFV bench

    • CNTT documentation (anuket-specs)

    • opnfvdocs

    • Vineperf

  • LFN Jenkins server

    • No jobs running there

    • @Cédric Ollivier can not manipulate the server, it seems to be not working

    • The plan is to use this to build redundancy of the jobs

  • Workers

    • LaaS and a datacenter in Portland connected to the Orange Jenkins

AoB

  • None