wiki:opnfv_distribution
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
wiki:opnfv_distribution [2014/11/13 07:46] Tapio Tallgren [Initial Distribution selection] |
wiki:opnfv_distribution [2015/03/26 05:52] (current) Narinder Gupta [Table] |
||
|---|---|---|---|
| Line 7: | Line 7: | ||
| 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. | 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. | ||
| - | ^Criteria ^RHEL ^CentOS ^Ubuntu ^Fedora ^Devstack ^ | + | ^ Criteria ^ RHEL ^ CentOS ^ Ubuntu ^ Fedora ^ Devstack ^ |
| - | |Release |7.2 | |14.04 | 21 | Latest | | + | | Release | 7 | 7 | 14.04 LTS | 21 | Latest | |
| - | |Installer | Packstack | Packstack | MaaS/Juju | Packstack | Devstack | | + | | Installer | Packstack | Packstack | JuJu, MAAS, Cloud Installer | Packstack (RDO), DevStack | Devstack | |
| - | |Support | | + | | Support | Yes | Community | Yes | Community | No | |
| - | |Resident Developer | | + | | Resident Developer | | | | | | |
| - | |Openstack Release | | | | Icehouse (yum) | | | + | | Openstack Release | Juno (RDO), Icehouse (RHEL OSP) | Juno (RDO) | Juno | Icehouse (packaged), Juno (RDO) | Kilo | |
| - | | | | | | Juno (RDO) | | | + | | ODL Release | | | | Hydrogen, Helium (not in repositories) | | |
| - | |ODL Release | | | | Hydrogen (?) | | | + | | Installer Languages | Puppet | Puppet | Juju, various | Puppet (RDO), bash (Devstack) | | |
| - | |Installer Languages | | | | Puppet (RDO) | | | + | | Plugins Availability | | | | | | |
| - | |Plugins Availability | | + | | Ease of Development | | | Yes | | | |
| - | |Ease of Development | | + | | Virtual Environment | | | Vagrant, Kvm, Docker, LXC etc | Qemu/kvm, Docker, lxc etc | | |
| - | |Virtual Environment | | + | | Zero Touch including PXE Boot | | | Yes (JuJu/MaaS/Cobbler) | | | |
| - | |Zero Touch including PXE Boot | | | | Yes | + | | Troubleshooting Ease | | | | | | |
| - | |Troubleshooting Ease | | + | | Long Term Evolution | | | 14.04 | | | |
| - | |Long Term Evolution | | + | | Automated Testing Framework Integration | | | OSTF | | | |
| - | |Automated Testing Framework Integration | | + | | Kernel Version | 3.10 | 3.10 | 3.13 | 3.17 | | |
| + | | Qemu version | 2.0 | 2.0 | 2.0 | 2.1 | | | ||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| Each criteria is explained briefly below, so that the OPNFV community understand them in the same way. | Each criteria is explained briefly below, so that the OPNFV community understand them in the same way. | ||
| Line 32: | Line 42: | ||
| Specify the type of support we can get. For example, we can consider Instantaneous, 1 Day, 1 Week, 2 weeks etc. | Specify the type of support we can get. For example, we can consider Instantaneous, 1 Day, 1 Week, 2 weeks etc. | ||
| ==== Resident Developer ==== | ==== Resident Developer ==== | ||
| - | 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. | + | 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. |
| ==== Openstack Release ==== | ==== Openstack Release ==== | ||
| Specify the Openstack Release supported by the Distro release. For example, Juno or Icehouse or Kilo etc. | Specify the Openstack Release supported by the Distro release. For example, Juno or Icehouse or Kilo etc. | ||
| Line 40: | Line 50: | ||
| Specify what installer languages are supported. For example, Puppet, JuJu etc. | Specify what installer languages are supported. For example, Puppet, JuJu etc. | ||
| ==== Plugins Availability ==== | ==== Plugins Availability ==== | ||
| - | Richness of the plugins availability for different upstream projects that we want to integrate | + | 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" | ||
| ==== Ease of Development ==== | ==== Ease of Development ==== | ||
| - | How easy is it to develop plugins using installer language. Note. This is not about general development. General development tools are well defined. | + | 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". |
| ==== Virtual Environment ===== | ==== Virtual Environment ===== | ||
| - | Does it support virtual environment. | + | 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". |
| ==== Zero Touch including PXE Boot ==== | ==== Zero Touch including PXE Boot ==== | ||
| - | Supports PXE boot of servers or not | + | 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". |
| ==== Troubleshooting Ease ==== | ==== Troubleshooting Ease ==== | ||
| - | How easy it is to enable logging/debugging of the system | + | 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. |
| ==== Long Term Evolution ==== | ==== Long Term Evolution ==== | ||
| + | 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 Testing Framework Integration==== | ==== Automated Testing Framework Integration==== | ||
| + | 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. | ||
wiki/opnfv_distribution.1415864805.txt.gz · Last modified: 2014/11/13 07:46 by Tapio Tallgren
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: Creative Commons Attribution 4.0 International License
