User Tools

Site Tools



Genesis sandbox: Example requirements

Example requirements to help kick-off the Genesis work.

Requirements fall into several categories:

  • Target system requirements: Hardware components of the installed system
  • Target system requirements: Software components of the installed system
  • Common software artifacts and scripts used across all installers
  • Requirements for a common user experience

Target system requirements: Hardware components

  • Deploy on a "Pharos-compliant" lab (details to be added)
  • Deploy on a single node with nested virtualization

Target system requirements: Software components


  • Base OS distribution supported: Centos 7, Ubuntu 14.04
  • SDN Controller: OpenDaylight Helium SR4, OpenDaylight Lithium
  • VM controller: OpenStack Juno, OpenStack Kilo
  • Hypervisor: KVM (version tbd)
  • Virtual forwarder: OVS (version tbd)


Component Required? Version Notes
Nova Yes Juno, Kilo
Glance Yes Juno, Kilo
Neutron Yes Juno, Kilo
Keystone Yes Juno, Kilo
MySQL Yes Juno, Kilo Must be HA
RabbitMQ Yes Juno, Kilo Must be HA
Pacemaker cluster stack Yes Juno, Kilo Required for HA
Corosync Yes Juno, Kilo Required for HA
Ceilometer No Juno, Kilo
Horizon Yes Juno, Kilo
Heat No Juno, Kilo
Swift No Juno, Kilo
Cinder Yes Juno, Kilo Required to use Ceph Storage as Cinder backend



Component Sub-Component Version Notes
odl-config-persister-all OpenDaylight :: Config Persister:: All
odl-aaa-all OpenDaylight :: AAA :: Authentication :: All Featu
odl-ovsdb-all OpenDaylight :: OVSDB :: all
odl-ttp-all OpenDaylight :: ttp :: All
odl-openflowplugin-all OpenDaylight :: Openflow Plugin :: All
odl-adsal-compatibility-all OpenDaylight :: controller :: All
odl-adsal-all OpenDaylight AD-SAL All Features
odl-config-all OpenDaylight :: Config :: All
odl-netconf-all OpenDaylight :: Netconf :: All
odl-base-all OpenDaylight Controller
odl-mdsal-all OpenDaylight :: MDSAL :: All
odl-yangtools-all OpenDaylight Yangtools All
odl-restconf-all OpenDaylight :: Restconf :: All
odl-netconf-connector-all OpenDaylight :: Netconf Connector :: All
odl-akka-all OpenDaylight :: Akka :: All

Common software artifacts and scripts

  • Scripts
    •,, scripts available for integration with CI/CD
  • Common puppet manifests
    • OpenDaylight configuration manifest: common/puppet-opnfv/manifests/controller.pp

Requirements for a common user experience


  • Deploy OpenStack with High-Availability (for those components that support it in Kilo) - >=3 control nodes. To be validated with tests (functest defined).
  • Deploy OpenDaylight with Clustering - >=2 control nodes
  • Restartable system components of installer. Idempotent behavior for components of the installer


  • Track/control all versions of all components pulled from external sources (user should be able to identify the versions and origins of all software components deployed
  • Multiple releases support: Support installation of different OPNFV releases (e.g. Arnom Arno SR1, etc.)
  • Hitless hardware upgrade: Increase size of a deployment (add additional servers) without service interruption.
  • Hitless software upgrade/downgrade: Upgrade/downgrade the deployment to a new version of OPNFV operating software without tenant disruption

System definition/configuration

  • Common ability to input site, topology, and server information so that information can be applied to servers during provisioning
  • User-configurable parameters available via single config.yaml file - with all defaults shown
  • Allow assignment of different roles to servers, so that hardware and software can be configured according to the role.
  • Deployment tool to provide for automatic device discovery.
  • Automatically populate discovered servers into install tool (reduce user-intervention to a minimum).

Deployment process qualities

  • Configure boot-order of servers for automated (re-)provisioning
  • Configure RAID (for local storage resiliancy) on boot drives, so that the OS can be installed on redundant drives. RAID to be configured in the earliest phase of bare metal install and without user interaction.
  • Enable SELinux by default
  • Install ssh keys on servers so that key-based login can be used for administration
  • Configure NTP servers on the server for clock synchronization. Configured as early as possible to avoid later skew. Configured to support multiple pools.
  • Format non-boot drives on compute servers, so that they can be used as CEPH Object Storage Devices (OSDs).
  • Specify the VIC in the servers to use, so that I can deploy servers with more than one VIC.
  • Unique kickstart file per platform/role, so that OS can be customized for hardware and role.
  • Option to provide a set of ssh user keys to be installed on all servers (for administration)
  • Kickstart to wipe-out all old partitions during installation, so that servers perviously deployed can install cleanly.
  • Disable booting from all but a single PXE slot and single HDD (to reduce boot times).
  • Allow for enablement of SDNcard on certain profiles for OS installation and booting.


  • Protect passwords, keys, credentials: Allow for mandatory access control, method for chaning passwords.


  • Functional tests (functest defined) that test deployment success pass successfully


  • Installer user-guide
  • Installer release-notes


  • Support IPv6 and IPv4 addresses for tenants (for VMs and for API endpoints)
  • Support IPv6 and IPv4 transport (a.k.a. "underlay") network

Installation method

  • Bootable disk image (.iso format) to install jumphost (and from there, entire OPNFV system)
  • Set of scripts to automatically install jumphost (and from there, entire OPNFV system)

Installer sources

  • Deployment using binaries from 3rd-party repos (vendor specific distro)
  • Deployment using OPNFV created binaries from upstream (for "build from source" option)
genesis/requirements_examples.txt · Last modified: 2015/07/31 17:26 by David Duffey