Introduction

Rover pods are deployed from an existing Regional Controller and consist of a single nodes. In this guide since a Rover pod is implemented on a single server the term Rover pod and Rover Server are used interchangeably.

A choice of Dell or HP servers is supported. The choice of which type of servers are deployed is achieved by simply creating different pod specific yaml input files.

In R1 the options include:

Preflight Requirements

Server iDRAC/iLO provisioning

The Target Rover Server's  iDRAC/iLO  IP address and subnet must be manually pre-provisioned into the server before installation begins.

Networking

The Target Rover Server has two physical and multiple VLAN interfaces. The RC uses different interfaces on the Target Rover Server during the different stages of its creation of a Rover pod. A very detailed description of the entire networking setup can be found in the  Network Architecture section of this release documentation. In addition the networking configuration with example values similar to that used during validation testing is contained in the Validation Labs section of this release documentation Ericsson Rover Validation HW, Networking and IP plan.

The RC must have IP connectivity to the Target Rover Server's dedicated BMC port using ports 80 (http) and 443 (https) in order to issue Redfish commands to configure the Target Rover Server's BIOS settings. The Target Rover Server's BMC IP address is denoted as <SRV_OOB_IP> in this guide. The Target Rover Server's BMC must be manually pre-configured with the <SRV_OOB_IP> address.

After setting the Target Rover Server's BIOS, the RC will then (usually) act as the DHCP server for the initial Target Rover Server's boot process. The Target Rover Server will be automatically configured by the Redfish API commands to send its initial DHCP Request from one of its main NICs via the VLAN tagged 'host' network. Thus the Target Rover Server's 'host' interface and the RC's DHCP server interface must be in the same broadcast domain so that the DHCP Request broadcast frame can reach the RC. It is possible to remove the need for the Build Server and Target Server to be on the same L2 domain using  DHCP relay/helper functionality in the TOR to relay the Target Server's DHCP requests across an IP routed network, however this has not been verified in the R1 release and this guide assumes the RC and Target Rover Server to be on the same L2 broadcast domain as described in the detailed networking section.

During the layer stages of the installation the Target Rover Server's 'host' interface must have connectivity to the internet to be able to download the necessary repos and packages.

Software

When the Rover pod is installed no software is required on the Target Rover Server. All software will be installed from the RC and/or external repos via the internet.

Preflight Checks

To verify the necessary IP connectivity from the RC to the Target Rover Server's BMC confirm from the RC that at least port 443 is open to the Target Rover Server's  iDRAC/iLO BMC IP address <SRV_OOB_IP> :  

root@regional_controller# #nmap -sS <SRV_OOB_IP>
 
root@regional_controller# nmap -sS 10.51.35.145
 
Starting Nmap 7.01 ( https://nmap.org ) at 2018-07-10 13:55 UTC Nmap scan report for 10.51.35.145 Host is up (0.00085s latency). Not shown: 996 closed ports PORT STATE SERVICE 22/tcp open ssh 80/tcp open http 443/tcp open https 5900/tcp open vnc Nmap done: 1 IP address (1 host up) scanned in 1.77 second

Note: The enumerated IP shown (10.51.35.146) is an example iDRAC address for a RC deployed in a validation lab.

Preflight Rover Pod and Site Specific Input Data

The automated deployment process configures the new Rover Server based on a set of user defined values specific to each Rover pod. These values must be defined and stored in a yaml site and pod specific input configuration file before the Rover pod deployment process can be started.

An example input file similar to that used during Ericsson Validation testing is shown at the end of this page.

During the installation using the RC's UI the input site yaml file will need to be accessible from RC.

Deploying a Rover Pod

Deployment of each new Rover pod at a given site is performed from the RC's UI. 

Warning! Internet Explorer and Edge may not work thus it is strongly recommended to use Chrome.

If an action appears to fail click 'Refresh'.

Select a Region and select 'Rover' for the blueprint :

Click 'Upload' to allow you to select the Rover site and pod specific input yaml file:

Choose the input file that you have created for the new Rover pod you want to deploy then clock 'Submit'

To initiate the automated deployment click 'Deploy'

Rover Pod Site Specific Configuration Input Files

This section contains links to the input files used to build the Rover pods in ATT's and Ericsson's validation labs for the R1 release. Being pods and site specific the enumerated values will differ. Full details of the relevant validation lab setup that should be referenced when looking at these files is contained in the Validation Labs section of this documentation.

Please note, superficially these files may appear very similar but they are all included as examination of the details shows the differences dues to HW differences such as vendor, slot location of NICs as well site specific differences due to VIDs, subnets etc.

This template should be used to create the deployment specific input file for the new Rover pod. The example below is for a file called aknode27 to create a Rover pod on a server called aknode27.