OPNFV in the long term will support multiple distributions that includes Ubuntu, Redhat, Fedora etc. This is not a complete list and any preference or priority is not implied. To get started on OPNFV their is an urgent need to start on some distribution. However, in long term, the most popular distributions and upstream project supported methodologies shall be supported. This document lists the different aspect that needs to be addressed to meet this goal.

• Initial kick start distribution selection
• Long term evolution

We have a urgent need to select an initial distribution as several projects depend on this selection. The following table is lists some of the popular distribution and other mechanisms along with several criteria that will enable the OPNFV community to select the initial distribution.

Each criteria is explained briefly below, so that the OPNFV community understand them in the same way.

The installer is a collection of scripts and tools that will enable the associated distribution to be installed. The installer should be flexible to support most configurations required by the distribution as well as the upstream projects that are of interest to us. In this row we will specify the best supported installer on this distribution.

Specify the most suitable release that we should consider. Note that some of the other criteria will be based on this specified release

Specify the type of support we can get. For example, we can consider Instantaneous, 1 Day, 1 Week, 2 weeks etc.

Specify if we have a developer in OPNFV who can help to develop, provide help for debugging trouble shooting for the short term, at least, until we get going. A committed name will be excellent, otherwise a company name or Yes/No is good. Limited support in this area will impede our progress.

Specify the Openstack Release supported by the Distro release. For example, Juno or Icehouse or Kilo etc.

Specify the ODL Release supported.

Specify what installer languages are supported. For example, Puppet, JuJu etc.

Richness of the plugins availability for different upstream projects that we want to integrate that is based on the installer language. For example, puppet provides several plugins for openstack, KVM, other open source software etc. On the other hand, some installer scripts are not that rich and therefore requires effort from our community. The response can be "Extensive", "Medium", "Rare"

How easy is it to develop plugins using installer language. Note. This is not about general development. General development tools are well defined. Since our goal here is to get started immediately, and we may see the need for a certain open source component (for example some Test tool that needs to launched or triggered periodically). In such cases we may need to develop some plugin in the installer. In such case, how easy is it to develop the plugin. The ease here is a factor determined by the richness of the language, availability of skils etc. The response could be one of "Easy", "medium", "difficult".

Does it support virtual environment. Some of the installers don't support developer friendly installation in a VM nodes. We may need to put some effort to get this fixed by our community. So, the response can be one of "In built support", "Requires some effort", "Not possible".

Supports PXE boot of servers or not. Some of the installers like packstack does not support PXE boot. If the installer does not support this then we have to address this in a different way or manually install the base OS on all nodes. Note: Packstack may be addressing this issue even as we speak. However, in general the requirement is we want the complete OPNFV software installed (including the base OS, tools, test tools) and configured with manual Zero Touch. The choice here could be "Zero touch", "Requires manual intervention in few places like ….". "Requires extensive work to make it zero touch".

How easy it is to enable logging/debugging of the system. After we install the software and start the testing, we may need to trouble shoot a certain node or the entire setup. Now, if we have a mechanism that exports logs (critical, major, error) and other debugging data to a central node and organizes them neatly, this helps debugging ease. We used to configure the syslogd to export such data to a remote node. Likewise, all core dumps on the remote nodes are copied to a single node, decodes a stack trace if possible, sends a e-mail etc., to the alias. These are few examples. Most important here is an alert that something went wrong on one of the nodes, followed by collection o any log, traces associated with that and making it available.

What are the plans of this distro in supporting upstream projects releases as we go long. If they support newer versions then it will reduce one level of complexity and integration issues when we move forward to different version of upstream project.

Automated test framework is an important requirement for the integration and testing project. While the installer takes care of the basic install, orchestration takes care of the bringing up the VNFs and setting them up, the automated testing framework works on the system after the orchestration is done. For example, it can turn on test equipment like IXIA, Spirent, trigger a test VM to inject traffic, turn on/off traffice, collect data on logs, stats etc. IF a distribution supports such a framework and adding custom scripts then that will be great. Naming these frameworks here will be useful.