Skip to main content

XCI: How OPNFV Slashed Upstream Integration from Months to Days

By October 19, 2017Blog

By Fatih Degirmenci, Yolanda Robla Mota, Markos Chandras

The OPNFV Community will soon issue its fifth release, OPNFV Euphrates. Over the past four releases, the community has introduced different components from upstream projects, integrated them to compose different flavors of the stack, and put them through extensive testing to help establish a reference platform for Network Functions Virtualization (NFV). While doing this work, the OPNFV community strictly followed its founding principle: Upstream First. Bugs found or features identified as missing are implemented directly into upstream code; OPNFV has carried very little in its own source code repositories, reflecting the project’s true upstream nature. This was achieved by the use of stable release components from the upstream communities. In addition to the technical aspects of the work, OPNFV established good relationships with these upstream communities, such as OpenStack, OpenDaylight, FD.io, and others. 

Building on previous experience working on integrating and testing different components of the stack, Euphrates brings applied learnings in Continuous Delivery (CD) and DevOps principles and practices into the fray, via the Cross Community Continuous Integration (XCI) initiative.  Read below for a quick summary about what it is, where we are now, what we are releasing as part of Euphrates, and a sneak peek into the future.

Upstream Development Model
The current development and release model employed by OPNFV provides value to OPNFV community itself and the upstream communities it works with, but is limited and dependant on using stable versions of upstream components. This essentially limits the speed at which new development and bugfixes can be contributed to upstream projects. This results in losing the essence of CI (finding issues, providing fast and tailored feedback) and means that the developers who contribute to upstream projects might not see results for several months, after everyone has moved on to the next item in their roadmap. The notion of constantly playing “catch up” with upstream projects is not sustainable.

In order for OPNFV to achieve true CI, we need to ensure that upstream communities implement a CD approach. One way to make this happen is to enable patch-level testing and consuming of components from master branches of upstream communities–allowing for more timely feedback when it matters most. The XCI initiative establishes new feedback loops across communities and with supporting tooling makes it possible to:

  • shorten the time it takes to introduce new features
  • make it easier to identify and fix bugs
  • ease the effort to develop, integrate, and test the reference platform
  • establish additional feedback loops within OPNFV, towards the users and between the communities OPNFV works with
  • provide additional testing from a production-like environment
  • increase real-time visibility

Apart from providing feedback to upstream communities, we strive to frequently provide working software to our users, allowing them to be part of the feedback loop. This ensures that while OPNFV pushes upstream communities to CD, the platform itself also moves in the same direction.

Helping Developers Develop by Supporting Source-Based Deployments
One of the most important aspects of XCI is to ensure developers do what they do best: develop. XCI achieves this by supporting source-based deployments. This means that developers can patch the source on their workstations and get their patch deployed quickly, cutting the feedback time from months to hours (or even minutes). The approach employed by XCI to enable source-based deployments ensures that nothing comes between developers and the source code who can even override whatever is provided by XCI to ensure the deployment fits their needs. Additionally, users also benefit as they can adjust what they get from XCI to further fit their needs. This is also important for patch-level testing and feedback.

Choice
What we summarized until now are firsts for OPNFV and perhaps firsts for the entire open source ecosystem; bringing multiple open source components together from master. But we have a few other firsts provided by XCI as part of the Euphrates release, such as:

  • multiple deployment flavors ranging from all-in-one to full blown HA deployment
  • multi-distro support: Ubuntu, Centos, and openSUSE
  • extended CI pipelines for all projects that choose to take part in XCI

This is another focus area of XCI: giving choice. We believe that if we offer choices to developers and users, they will leverage these options to invent new things or use them in new and different ways. XCI empowers the community by removing barriers and constraints and providing freedom of choice.

XCI utilizes tools such as Bifrost and OpenStack Ansible directly from upstream and what is done by XCI is to use these tools in a way that enables CI.

Join the Party
Are we done yet? Of course not. We are working on bringing even more components together and are reaching out to additional communities, such as ONAP and Kubernetes.

If you would like to be part of this, check the documentation and try using the XCI Sandbox to bring up a mini OPNFV cluster on your laptop. You can find XCI developers on #opnfv-pharos channel on Freenode and while you are there, join us to make things even better.

Finally, we would like to thank everyone who has participated in the development of XCI, reviewed our patches, listened to our ideas, provided hardware resources, motivated us in different ways, and, most importantly, encouraged us. What we have now is just the beginning and we are on our way to change things.

Heading to Open Source Summit Europe? Don’t miss Fatih’s presentation, “Bringing Open Source Communities Together: Cross-Community CI,” Monday, October 23, 14:20 – 15:00.

Learn more about XCI by reading the Solutions Brief or watching the video, and signing up for this XCI-based webinar on November 29th.