• Deploy on a "Pharos-compliant" lab
• Deploy on a single node with nested virtualization

(Evolve: https://wiki.opnfv.org/get_started/get_started_system_state)

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

• OpenStack Juno Components OpenStack Juno
• OpenStack Kilo Components OpenStack Kilo

OpenDaylight

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

• 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

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

• Configure boot-order of servers for automated (re-)provisioning
• Configure RAID on boot drives, so that the OS can be installed on redundant drives
• 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
• Format non-boot drives on compute servers, so that they can be used as CEPH OSDs.
• Specify the VIC in my 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

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

• Deployment using binaries from 3rd-party repos (vendor specific distro)
• Deployment using OPNFV created binaries from upstream (for "build from source" option)