Page tree
Skip to end of metadata
Go to start of metadata

PLEASE NOTE THAT THE INFORMATION ON THIS PAGE IS PRELIMINARY AND SUBJECT TO CHANGE...

Introduction

As described in Release Process Proposal, XCI will push the scenario ownership to projects that develop them. The details of how this is proposed to work is documented in following sections.

Principles

Separation of Concerns

The approach described here puts separation of concerns at its core. This means that, XCI does what it is supposed to do; providing a framework for projects to bring their scenarios to OPNFV. Projects then can focus on what is they are developing.

Separating what work is done where and letting OPNFV projects to have more control/flexibility on their code/scenario without thinking the base platform availability/quality itself more than they need is a crucial need for the community to develop things faster. This is enabled by the XCI framework, the components utilized by it and the way of working described here.

Reduced Complexity

XCI aims to hide the complexity as much as possible since the main thing the projects need to do is to provide artifacts for their scenario, assuming the roles for the components and integration of them are completed upstream.  XCI will not add any overhead to this.  (the prerequisite to this is to follow XCI guidelines when it comes to enabling scenarios through XCI.)

Ability to Choose

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.)

Reusability

Increased reusability is another important point XCI based way of working. The roles for components written in upstream communities and the roles for scenarios written in OPNFV projects can be consumed by anyone just like how we are doing for ODL Ansible Role. 

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.

CI-ability

On top of making projects' lives easier, this approach will help CI as well since we will have the ability to run CI in a much better way and at a faster pace. Rather than running things without checking if they are good enough or whether if anything changed or not, we will have more granular approach to how scenarios are integrated and tested through CI since whenever a project changes their scenario, CI will trigger jobs for the impacted scenarios to deploy and test the changes as needed, providing feedback directly to the projects that own the scenarios.

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;

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.)

  • No labels