PLEASE NOTE THAT THE PROPOSAL ON THIS PAGE IS CURRENTLY UNDER DISCUSSION
Putting Both Models Together
The diagram below tries to illustrate how the OPNFV Releases would look like when they are put next to each other.
Several things need to be clarified in above diagram.
As it is visible, the straight line on top tries to show the current release model with its milestones and official releases. It is called as "stable track" on this page.
The dotted line below tries to show the proposed release process that is running in parallel to traditional one. It is called as "latest track" on this page.
The 4-pointed starts in "latest track" are the tags applied by the projects to make certain versions available to their users as their intermediate releases as summarized in the previous section. They can be named like latest monthly or latest weekly releases for example. These versions are also candidates for the official OPNFV releases; the projects need to determine which version should be part of the official OPNFV release and pass this information to Release Manager. The chosen version then gets tagged by official release tag and the projects will not need to wait for release to happen in order to continue with the work for the upcoming release.
Milestones in Latest Track
Another important point to highlight regarding "latest track" is that it
and how they are done in latest track.
XCI vs OPNFV Projects/Scenarios vs Upstream Projects
The relations between XCI, OPNFV Projects/Scenarios and Upstream Projects in latest track from release point of view can be seen from the diagram below.
The way how the development is proposed to be structured makes it possible to release XCI itself and the scenarios independently from each other - like how upstream projects do their releases; independent from OPNFV.
Another point to mention here which makes the releases independent is the relation between XCI and the OPNFV scenarios; OPNFV projects are upstream to XCI.
The details of proposed way of onboarding projects/scenarios to XCI and the way of working is available on Onboarding Projects/Scenarios to XCI.
In CD based development, the scenarios will be fully owned by the projects as oppose to how it is done today; the ownership and the responsibility to develop the scenarios, tag intermediate releases, branch the repositories, and promote an intermediate release as official OPNFV release are fully controlled by the projects themselves. This means that all the work that is required to develop a scenario and put it through XCI will be done in Git repositories of the corresponding projects, not in XCI repository. The development work will be supported by XCI to provide fast feedback to the projects, giving projects the opportunity to catch and fix faults earlier than what it is today. (The details/mechanics of the proposed way of developing scenarios is documented on Onboarding Projects/Scenarios to XCI.)
A very high level list of steps are
- project develops a scenario and scenario is put through XCI continuously
- the documentation is done in parallel to the development work
- scenario fulfills the requirements to be tagged as intermediate release (tests pass, documentation is available, known issues logged to JIRA) and project has confidence
- project tags the version and makes it available as intermediate release
Having frequent intermediate releases makes it possible to get the software in the hands of users early and often to establish feedback channels between developers and users. Apart from that, this helps upstream projects to gather additional feedback from OPNFV, essentially improving the overall quality of the component they are developing.
Finally, making a scenario part of official OPNFV release will be as simple as passing a tagged version to Release Manager as version to release. No additional check is needed here since all the prerequisites will already be fulfilled long before due to gaining the right to tag a version as intermediate release.
Releasing None-Scenario Based Projects
This document mainly focuses on scenarios and their relation to XCI but none-scenario based projects (eg test projects) will be impacted by and possibly benefited from the new way of working.
One thing that must be highlighted here is that if we see OPNFV Platform Testing (daily runs) as the production environment for OPNFV Test Projects, one cay say that OPNFV Test Projects work in (kind of) Continuous Deployment model. This means that whenever a change comes into a test project, it gets merged to master after (limited) CI checks, resulting in the use of that version during platform testing, which does not always produce good results due to not having necessary checks in place. (lack of CI coverage)
By utilizing what is provided by XCI and following the accompanying release model, the Test Projects will have chance to adapt themselves to this way of working by employing similar approach; the versions to use within established XCI loops must have been verified properly, tagged, and made available for consumption to XCI and users in general. This might seem like slowing the test projects down but in reality, it helps increasing the overall speed of OPNFV by limiting the faults that slip into platform testing and ensuring we focus and troubleshoot on testing the platform instead of the test frameworks or the test cases. At the same time, the availability of the test frameworks and test cases will be improved along with the quality of them.
XCI is beneficial for requirement projects that do their development work directly upstream as well. If these projects do the development in upstream, XCI can pull down those components from master version and run the test cases that are developed within OPNFV or in upstream. The projects do not need to wait for their contributions to become available to OPNFV through traditional release model; they will directly be available when their contribution gets merged to master in upstream. (or even before the contribution gets merged to master in upstream by providing patchset verification jobs for the upstream projects the contribution is done.)
Q: Do we have to follow CD and use XCI?
It is entirely up to the projects to follow CD and use XCI. It is also important to mention that it is possible for the projects to join to CD & XCI initiative later on, when they feel confident about XCI.
Q: Will XCI be available for all the projects by default and the new release model enforced on them?
XCI will only be available to the projects who want to participate in XCI initiative.
This means that the CI support provided by XCI and the ability to integrate and test the scenarios using the master versions of upstream components will only be available to the ones who join since the projects need to make necessary adjustments within their projects, follow guidelines, and make their artifacts available to be integrated and tested in XCI.
It is important to highlight that not participating in XCI does not mean what is made available by XCI or the participating projects are only available to these projects. All the projects are welcomed to use whatever is made available by XCI, such as sandbox.
As noted in corresponding chapters, CD & XCI way of working and the accompanying release model will not be enforced on non-participating projects. The development and release work will remain same for these projects.
Q: Our project have ongoing commitments to OPNFV Installer(s). Do we have to forget about our commitments in order to go CD and use XCI?
e model and installers.
Q: How mature is XCI?
XCI is under heavy development currently and there are many things that are changing on a daily basis.
XCI currently has
- partial implementation of CI Evolution
- scenarios os-nosdn-nofeature, os-odl-nofeature and os-odl-sfc, the last 2 ones being under development
So, what is currently made available by XCI should be seen as early drop to start collecting feedback from OPNFV projects, upstream communities, and the users.
XCI will be released as part of Euphrates as "experimental" along with the scenarios onboarded to XCI.
Q: Can we take part in "stable" and "latest" tracks both at the same time?
If the projects believe they have the time and resources and they can support both "stable" and "latest" tracks, it is possible to participate in both at the same time.
But it is important to highlight that this will put demand on the project itself more rather than XCI.
Q: It seems the CD based development model and proposed release model only applicable to mature projects. Is that so?
Q: This model seems to be a better fit to the projects that release scenarios.
Even though the document mainly focuses on scenarios and the projects that work on developing scenarios, CD is applicable to different types of projects as they all can get different benefits from applying CD and using XCI.
Q: How difficult it is to work in CD and use XCI?
Q: Do we have to work against master? Can we use stable version of a component?
However, XCI framework makes it possible for projects to use different versions of one or more all upstream components for their scenario and this only impacts their scenario. If a project works with 2 scenarios, they can even use different versions of the upstream components for these 2 since the level of granularity is on scenario level.
Q: When can we mark a version as "latest" and have it available is an intermediate release? What are the criterias?
The criteria to mark a version as "latest" is same as the current release criteria for OPNFV;
- The scenario deploys on baremetal and passes functest/yardstick
- The documentation is complete
- Known issues/bugs are logged to JIRA
Q: Doesn't CD emphasize any version from master releasable at all times? If so, why do we need to mark versions as "latest X"?
That is correct but in order for us to experience with CD and find what works for us best, we need to take a slightly conservative approach. This is also visible in the proposal; starting monthly intermediate releases, followed by bi-weekly and weekly, finally reaching to true-CD.
Once the participating projects feel ready and confident, there is no reason for them not to issue more frequent releases or announce that any version users can pick from their project's master branch is expected to work.
Q: What will be the artifacts for my project if we take part in XCI?
There will be no traditional artifacts (RPMs/ISOs) at this phase. The artifacts that will be released by the projects are
- Ansible Roles for the scenarios
Q: What about establishing fixed set of components for OpenStack and other upstream projects and their versions?
Q: Will this really work?
OPNFV is not the first one who tries to work in CD. In fact CD has been around for quite a while and worked well for many different organizations.
However, no one can guarantee that the textbook definition of CD will work for OPNFV. We need to find what works and what doesn't for us and fine tune the way of working that suits us well and does not limit the benefits we will get from CD. So it is important for OPNFV to not stand still and continue trying new ways of doing things in order to have progress.
The only thing one can promise at this phase is that the journey to CD will be challenging but immensely rewarding and fun.