New Functest Kubernetes tags +release engineering insights

Cedric Ollivier



In addition to the classical river names, Functest Kubernetes now delivers Docker tags per Kubernetes release.

(Thank you for all the feedbacks, especially the last one from OOM PTL which convinced me to prioritize this idea)


The new tags simply match all Kubernetes versions from v1.13 :

For your information, there is no known CVE in all the Docker images (that should be a very key topic especially in OPNFV/Anuket deliverables) :


Badly they aren’t yet continuously verified via daily jobs as the classical docker images due to a lack of hardware resources.

This email is also a call for hardware resources ; 2 servers should be enough to install all 8 clusters required for a true gating.


This new Docker builds have been generated thanks to lots of new features in Xtesting CI published in 2021 about Continuous Development.

I proudly announce that all the 3000 Jenkins jobs needed by Functest are now fully generated from a single yml file mostly focusing on docker image, test case and src dir lists.

See all jjbs generated in the releng src dir:


As good example, here is the part which generates all Xtesting jjbs for Continuous Development and for Continuous Integration including:

-          patchset verification (test case verification vs compliant SUTs + tox: unit tests, linters, bandit, spell and link checks in docs, etc.)

-          deliverable verification (test case verification vs compliant SUTs)

-          CVE detection


(The Functest ones are just bigger due to the number of testcases and all the changes in test case names across the 6 active branches and it’s multiplied by the number of architectures supported: arm, arm64 and amd64)


- hosts:


    - vars/opnfv.yml


    - role: collivier.xtesting

      use_gerrit: true


      gerrit_project: functest-xtesting


        (?!{{ project }}-pi)^{{ project }}-[a-z-0-9.]+-trivy$


        - container: xtesting


            - first

            - second

            - third

            - fourth

            - fifth

            - sixth

        - container: xtesting-mts


            - seventh


        - latest:

            branch: master

            slave: lf-virtual1

            dependency: '3.13'

        - leguer:

            branch: stable/leguer

            slave: lf-virtual1

            dependency: '3.12'

        - kali:

            branch: stable/kali

            slave: lf-virtual1

            dependency: '3.11'

        - jerma:

            branch: stable/jerma

            slave: lf-virtual1

            dependency: '3.10'

        - iruya:

            branch: stable/iruya

            slave: lf-virtual1

            dependency: '3.9'

        - hunter:

            branch: stable/hunter

            slave: lf-virtual1

            dependency: '3.9'


We could infinitely debate between Jenkins and Gitlab CI/CD and falsy claim Jenkins Job Builder is too difficult (Hoping we will quickly stop assigning all LFN Releng design issues to Jenkins Job builder).

When we focus on the right abstractions for the project deliverables (all OPNFV test projects could leverage all this work as my company does), the release engineering becomes very simple and maintainable by all.

Hoping to see this kind of discussions in a Dev event rather than the previous marketing lead discussions quickly failing in the different tools and their targets.


To conclude, switching 3000 Functest Jobs to ONAP Releng is now as simple as changing OPNFV to ONAP in git url in this yaml file.

Same if you want to reuse all that work in your company (everything is in place to add bots from your lab if you’re interested to vote on reviews).


I’m now working on the CD part for Kubernetes runners in Jenkins which asks for a few small enhancements (hoping we would update our obsolete shell runners for common builds – that would be a cost saving simply by breaking the LFN project silos which falsy duplicate everything).

And then I would finish the full support of Gitlab CI/CD (only the CI part is currently supported which is already enough for CNTT RC1 and RC2).


Stay tune. Any help is welcome.




Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

Join to automatically receive all group messages.