Jack Morgan, Intel Ever heard of the POD descriptor file? Ever wonder what it is? You've come to the right place! This presentation will answer what the POD descriptor file is and why it was made. The presenter will dive into the details of the POD descriptor file, how to create one from the template and how to store them in the securelab repository. In addition, the presenter will look at how the POD descriptor file benefits the testing community. Current efforts such as the Pharos Dashboard and Lab-as-aService already use the POD descriptor file. Extending its scope to work with test frameworks will be discussed. Finally, The presenter will cover how the POD descriptor file plugs into Dynamic CI. The POD descriptor file plays an important role in moving to a way of dynamically allocating hardware resources in community test labs. Details of the POD descriptor file converter will be covered as we look to meet the needs of installer projects who are not able to use the POD descriptor file natively. This presentation hopes to interactive so come prepared to ask questions.

2. POD Descriptor File
Deep Dive
Jack Morgan, Intel

3. What is a POD descriptor file?
• POD descriptor file defines what hardware is in an OPNFV POD
• It’s part of the common configuration file consolidation effort
• Currently, each installer has its own hardware resource files
• There is no consistency between these installer resource files
• This is an effort to solve this inconsistency issue

4. POD Descriptor File
Sections:
• Lab details
• Jump Server
• Nodes

5. Pharos Lab
details:
pod owner: Lab Owner
contact: email@address.com
lab: Linux Foundation
location: Portland, Oregon, USA
type: {production|development}
link: http://wiki.opnfv.org/

6. Jump Server
jumphost:
name: pod1-jump
node:
type: {baremetal|virtual} # can be virtual or baremetal
vendor: supermicro
model: S2600JF
arch: {x86_64|aarch64}
cpus: 2
cpu_cflags: {broadwell|hasewell|etc} # add values based on CFLAGS in GCC
cores: 10 # physical cores, not including hyper-threads
memory: 32G

7. Jump Server
disks: # disk list
- name: {disk#number} # first disk
disk_capacity: {M|MB|G|GB|T|TB} # volume
disk_type: {hdd|ssd|cdrom|tape} # several disk types possible
disk_interface: {sata|sas|ssd|nvme} # several interface types possible
disk_rotation: {5400|7200|10000|15000} # define rotation speed of disk
- name: 'disk2' # second disk
disk_capacity: 2048G
disk_type: hdd
disk_interface: sas
disk_rotation: 15000

8. Jump Server
remote_para: &remoteparas
type: {ipmi|amt} # hardware manggement tool
versions:
- 1.0
- 2.0
user: root
pass: root
remote_mangement:
<<: *remoteparas
address: 10.4.7.3/24
mac_address: "10:23:45:67:89:AC"

9. Jump Server
interfaces: # physical interface list
- nic: {nic#number} # first interface
address: 192.168.100.1 # ip address of nic
mac_address: "10:23:45:67:89:AC"
vlan: {native|1-4095} # vlan tag, may have multiple tags
- nic: 'nic2' # second interface
address: 10.20.0.1/24
mac_address: "10:23:45:67:89:5B"

10. Nodes
- name: pod1-node1
node: &nodeparas # for nodes in the same pod may have the same configuration
type: baremetal
vendor: supermicro
model: S2600JF
arch: x86_64
cpus: 2
cpu_cflags: hasewell
cores: 12
memory: 128G

11. Nodes
disks: &disks # for nodes in the same pod may have the same configuration
- name: 'disk1'
disk_capacity: 4906G
disk_type: hdd
disk_interface: sata
disk_rotation: 7200
- name: 'disk2'
disk_capacity: 2048G
disk_type: hdd
disk_interface: sas
disk_rotation: 15000

12. Nodes
remote_mangement:
<<: *remoteparas
address: 10.4.7.7/24
mac_address: "10:20:22:67:89:A2"

13. Nodes
interfaces:
- name: 'nic1'
speed: {1gb|10gb|25gb|40gb}
features: {dpdk|sriov}
address: 10.2.4.7/24
mac_address: "10:23:22:67:89:AC"
vlan: 201
- name: 'nic2'
speed: 1gb
features: ''
address: 10.2.4.8/24
mac_address: "10:23:22:67:89:5B"
vlan: 202
interfaces:
- name: 'nic3'
speed: 10gb
features: 'dpdk|sriov'
mac_address: "00:1b:21:22:f1:b4"
vlan: 203
- name: 'nic4'
speed: 10gb
features: 'dpdk|sriov'
mac_address: "00:1b:21:22:f1:b5"
vlan: 204

14. - name: pod1-node2
node: *nodeparas
disks: *disks # disks are same as pod1-node1
remote_mangement:
<<: *remoteparas
address: 10.4.7.8/24
mac_address: "10:20:22:67:88:A3"
interfaces:
- name: 'nic1'
speed: 1gb
features: ''
address: 10.2.4.8/24
mac_address: "10:23:22:67:88:AC"
vlan: 201
- name: 'nic2'
speed: 1gb
features: ''
address: 10.2.4.8/24
mac_address: "10:23:22:67:88:5B"
vlan: 202
- name: 'nic3'
speed: 10gb
features: 'dpdk|sriov'
mac_address: "00:1b:21:22:f8:b4"
vlan: 203
- name: 'nic4'
speed: 10gb
features: 'dpdk|sriov'
mac_address: "00:1b:21:22:f8:b5"

15. How to create your own POD descriptor file
• Check our the template from the pharos git repo
• https://git.opnfv.org/pharos/tree/config/pod1.yaml
• Edit lab, jump server and nodes sections
• Commit to securelab:labs/(lab)/pod#.yaml via gerrit
• Committers in Infra WG projects have access (-1/+1/+2)
• pharos, releng, octopus, security
• Merge commit

16. Who would use the POD descriptor file?
• Lab owners
• Pharos Dashboard
• Lab-as-a-Service (LaaS)
• Test Frameworks
• POD descriptor file converter
• Dynamic CI

18. Questions?
Thank you for attending