PLEASE NOTE THAT THE INFORMATION ON THIS PAGE IS PRELIMINARY AND SUBJECT TO CHANGE...
As described in Release Process Proposal, XCI will push the scenario ownership to projects that develop them.
One of the most important advantages of giving the ownership to the projects is that if a project needs to issue fixes, use different set of OpenStack services, or use a different version of an upstream component for a specific reason, it will only impact that project and the scenario delivered by the project. Any problems that might arise from doing this will be isolated to that project and scenario, safeguarding other projects and scenarios from possible negative impacts.
An example to this would be the OpenStack services that are enabled for a certain project/scenario. Not all projects need same set of services enabled so giving projects the ability to decide which services they need and making it possible for them to enable/disable services based on their needs will ensure none of the projects impact each other negatively by (accidentally) disabling a service needed by another project. Apart from limiting the potential issues, this has additional benefits such as shortening the time it takes to deploy and test the scenarios since unneeded components and test cases for them can be disabled. This will be achieved by providing a technically viable solution and establishing guidelines so that OPNFV projects can override the defaults provided by XCI by keeping upstream role versions and list of the services in their repo so the XCI can bring the components together as stated by the project and run the composed platform using those versions and by enabling those services. (XCI will always have set of services that are enabled by default and list of SHAs to use.)
Increased reusability is another important point XCI based way of working. T
Traceability and Reproducibility
Two of the most important aspects that are ignored by some of the projects are end-to-end traceability and reproducibility. Since XCI pins exact versions of the upstream components (even on sub-component level), it is always possible to get the list of components with the corresponding versions to reproduce a specific problem, identify the root cause, find correct component/project, and get the fix issued. This is built into XCI from day one.
Structuring the Work to Onboard to XCI
Ansible Roles for Components
The roles for the components used by the scenarios need to be developed and delivered by the upstream communities who are developing the component. This ensures that the upstream community has full ownership and control over their artifacts and makes it possible for them to oversee the development of the roles.
A perfect example to this is the OpenDaylight Ansible Role developed and maintained by OpenDaylight community and consumed by OPNFV and others who want to use as OpenDaylight as SDN controller.
XCI consumes these roles through OpenStack Ansible with no or minimum changes directly from the corresponding upstream communities.
Component Integration to OpenStack
In order for components to be deployed in OpenStack, the Ansible Roles developed by other communities need to be integrated with OpenStack. This is directly done in upstream in OpenStack Ansible playbooks and nothing is kept within XCI.
XCI consumes these playbooks through OpenStack Ansible with no changes.
Ansible Roles for OPNFV Scenarios
The Ansible Roles for the OPNFV Scenarios are developed and maintained by the corresponding OPNFV Projects where the scenario is developed. A side benefit of the OPNFV projects developing these roles is that these roles can be consumed by others as well so this increases reusability as well.
XCI consumes these roles directly from the OPNFV projects.
An Example: Service Function Chaining
OPNFV SFC Project is the first project to embrace the XCI and the project is at the final phase of finalizing their work with onboarding to XCI. The work that is done by SFC project helped XCI to find out how best to structure the work and the way of working documented above is a result of this.
Apart from benefiting from SFC experiences to adjust the way of working with XCI, the project is a perfect example of integrating multiple components from different upstream communities and deploying the scenario by a role written by the project.
Here are the details regarding Ansible Roles for Components, Component Integration to OpenStack, and Ansible Role for the SFC Scenario;
- Ansible Roles for Components: SFC uses two components as part of the scenario; OpenDaylight and Tacker.
- Ansible Role for OpenDaylight: Developed and maintained by OpenDaylight community. Link to the role:
Scenario Descriptor File (SDF) and XCI
The way the development work is proposed to be structured for XCI has lots of similarities with proposed Scenario Lifecycle and Scenario Descriptor Files (SDF).
The work done as part of SDF will be evaluated from XCI point of view and possible ways to incorporate it to XCI will be investigated. In current thinking the SDF could point to the roles and playbooks used by XCI in the same way as it needs to point to installer specific configuration files for the stable track.
One of the common themes both XCI and SDF have in common is the types of the scenarios; generic and specific. In XCI way of working proposal, SFC is a specific scenario. How to handle the generic scenarios (such as os-nosdn-nofeature and os-odl-nofeature) haven't been finalized yet but it is currently being planned to keep them under XCI and ownership for these scenarios will be on community, more specifically on the projects who base their scenarios to generic scenarios. (For example, os-odl-nofeature can be developed and maintained by SFC and BGPVPN project collaboratively.)