Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents
Overview

This will be the 'software' counterpart of this work. The validation of the software configuration, should be performed against the requirements, that is preferably defined in a machine-readable format. Hence, this project relies heavily on an implementation of PDF 2.0 defined in CNTT. 


Team

NameAffiliationRemarks

Sridhar K. N. Rao

Sridhar Rao

SpirentCIRV-SDV Lead

Parth Yadav

Parth Yadav

Delhi UniversityLFN Intern

Ashwin Nayak

NITKLFN Intern

Shivam Balikondwar

Shivam Balikondwar

PICTStudent Volunteer 

Implementation of PDF 2.0 in JSON

This implementation will be "SPECIFIC" to support software validation, and multiple installers/installations (Airship, TripleO, Fuel, etc). In this implementation, there will be parameters that are not part of CNTT-PDF. The implementation has two parts:

  1. PDF-Template in JSON.
  2. Site-specific PDF in JSON

The PDF-Template includes "extrapolation" information, which will help to create site-specific pdfs. The template will be filled by the user and extrapolated by the tool to create complete site-specific PDF.

The below figure summarizes the organization of the template.

Image Added


Architecture

There will be two versions with single code-base. 

Version-1

The below figure provides the software architecture of the SDV. The user only runs 'valid' program, and select one or more validations.

Image Added

Version-2

The containerized version.

Image Added

Testcases

The initial testcases can be found here: http://testresults.opnfv.org/test/#/projects/cirv 

Pre-Deployment Software Validation: Hyperlinks


The below table and excel-sheet summarizes the links for which the connectivity is to be checked. Along with the connectivity, the 'Latency' can also be noted.

PS: The table (sources) and the excel (images) are specific to Airship. For other deployments, the components and corresponding repo-names and tags may vary.

Images

Airship-Images.xlsx

Sources


Sl. No.ComponentRepository-NameTagsURL to use
1Neutronopenstack-helm/neutrond2abe39d498f48c4721e26aca19e81189bc8891bhttps://opendev.org/openstack/openstack-helm
2helm-toolkitopenstack-helm-infra/helm-toolkit
03580ec90afa162c166661acf27f351b83565375
https://opendev.org/openstack/openstack-helm-infra
3novaopenstack-helm/novad2abe39d498f48c4721e26aca19e81189bc8891bhttps://opendev.org/openstack/openstack-helm
4openvswitchopenstack-helm-infra/openvswitchd0b32ed88ad652d9c2226466a13bac8b28038399https://opendev.org/openstack/openstack-helm-infra
5calico, libvirt, mariadb, memcached, rabbitmq, postgresql, ceph-client, ceph-mon, ceph-osd, ceph-provisioners, openstack-helm-infra/< >03580ec90afa162c166661acf27f351b83565375https://opendev.org/openstack/openstack-helm-infra
6apiserver, calico/etcd,
controller-manager, coredns, etcd, haproxy, ingress, proxy, scheduler, promenade
charts/< >64807416b71958e31156ef7a50e169813acc4e15 https://opendev.org/airship/promenade
7barbican, cinder, glance, heat, horizon, keystone, tempestopenstack-helm-infra/< >52c132b9356695bf455ae25ec78cef9f532f9fe8https://opendev.org/openstack/openstack-helm
8tillercharts/tiller50384e47c762438b9e39abe4677f3c29f3c09184 https://opendev.org/airship/armada
9calico-utility, ceph-utility, compute-utility, etcd-utility, mysqlclient-utility, openstack-utility, postgresql-utility charts/<>9c2038cb59bfbb3ff5c3bbf11c7001d621437b98https://opendev.org/airship/porthole


Pre-Deployment Software Validation: Configuration

Apart from ensuring that the requirements are met, this validation helps in minimizing/eliminating any deployment errors, drives test-automation, and checks for consistency to achieve efficient automation. The below picture summarizes the scope (in red dashed rectangle) of the software validation.

Image Added

This software validation can be: (a)  'Pre-Deployment' Software Validation (b) NW Links Validation  (c) Post-Deployment Software Validation


The below table summarizes validation of different configurations. The table uses Airship and its configurations as an example. 


Sl-NoValidation-Parameterexpected valueFile To look at  (Applies to AIRSHIP ONLY)"Key" to match (Applies to AIRSHIP ONLY)Requirement Level
1OSubuntu
xenial
gobal/software/charts/ucp/drydock/maas.yaml
type/cntt/profiles/host/*
default_os:
image:
Mandatory
2HugePage Configurationsize: 1G
count: 32 (minimum)
profiles:
type/cntt/profiles/hardware/*
site/<site_name>/profiles/hardware/*
hugepages:
    dpdk:
        size:
        count:
Mandatory
3CPU Isolation Ex: 4-43, 48-87same as abovecpuset:
    kvm:
    vcpu_pin_set
Mandatory
4Openstack Versionocata/pike/steinNo Single Explicit Location.
global/software/config/versions.yaml includes the mention of the version
osh:
    <service_name>:
        <service_component>:*ocata*
Mandatory
5Openstack Services ?ingress-controller, ceph-config,, mariadb, rabbitmq, memcached, keystone, radosgw, glance, cinder, compute-kit, heat, horizontype/cntt/software/manifests/full-site.yaml
global/software/manifests/full-site.yaml

Mandatory ?
6Virtual-Switch


openvswitch
openvswitch-dpdk

Config only - Version as supported by OSH
site/<podname>/software/charts/osh/openstack-compute-kit/chart-group.yaml
chart_group:
    - openvswitch-dpdk
    - neutron-ovsdpdk
Mandatory
7Version of the Manifests1.7site/<site-name>/site-definitions.yamlrevision:Mandatory
8Node-Names ?list of all the names.site/<site_name>/baremetal/nodes.yamlname:Mandatory ?
10bootstrap protocol ?pxeprofiles:
type/cntt/profiles/hardware/*
site/<site_name>/profiles/hardware/*
bootstrap_protocol: Mandatory ?


Sl-NoValidation-Parameterexpected valueFile To look at  (Applies to AIRSHIP ONLY)"Key" to match (Applies to AIRSHIP ONLY)Requirement Level
1Hypervisorkvmglobal/software/charts/osh/openstack-compute-kit/nova.yamlvirt_type: Optional
2Container Enginedockerglobal/software/config/versions.yamlrepositories:
    docker:
Optional
3Container Management kubernetesNANAOptional
4k8S components proxy, container-networking, dns, etcd, haproxy, coretype/cntt/software/manifests/full-site.yaml
global/software/manifests/full-site.yaml

Optional
5Ceph Components mds, mon, osd, rgw, mgrtype/cntt/profiles/genesis.yaml
------------------
type/cntt/software/config/endpoints.yaml
labels:
    dynamic:
        <ceph-*>: enabled
-------------
data:
    <tenant-ceph-*>:
Optional
6K8S NetworkingcalicoNo single explicit location.
Optional
7LMA Components - Client Sidepromethues-openstack-exporter
fluentbit
type/cntt/software/manifests/full-site.yaml
global/software/manifests/full-site.yaml

Optional
8LMA Components  - Server Sideinfra-logging, infra-monitoring, infra-dashboardstype/cntt/software/manifests/full-site.yaml
global/software/manifests/full-site.yaml

Optional
9Special NIC Driversixgbe or i40ebaremetal/bootactions/*.yamlThe complete file.Optional
10Users


Optional
11UCP Componentsceph-update, ceph-config, core, keystone, divingbell, armada, deckhand, drydock-scaled, promenade, shipyard, type/cntt/software/manifests/full-site.yaml
global/software/manifests/full-site.yaml

Optional
12Tenant Ceph Components tenant-ceph (mgr, mon, rgw)type/cntt/profiles/genesis.yaml
------------------
type/cntt/software/config/endpoints.yaml
labels:
    dynamic:
        <tenant-ceph-*>: enabled
-------------
data:
    <tenant-ceph-*>:
Optional
13Post-Dep N/W Config Script


Optional
14Site-Typecnttsite/<site-name>/site-definitions.yamlsite_type:Optional
15Version of the Manifests1.7site/<site-name>/site-definitions.yamlrevision:Optional
16OVS DPDk ConfigurationNon-Datapath Threads,
PMD Threads
OVS-Bridge name
profiles:
type/cntt/profiles/hardware/*
site/<site_name>/profiles/hardware/*
--------------
type/cntt/network/common-addresses-ovsdpdk.yaml
cpu_sets:
    dpdk-lcore-mask:
    pmd-cpu-mask:
--------------
bridge_for_ovsdpdk

Optional


Network-Links Validation

Some of the options we have:

  1. Run LLDPtool on compute and control nodes – easiest to implement, but, it can get complex if the number of nodes are more.
  2. LLDP on TORs - Reuse the solutions that used by ‘data centers’ – opensource and scalable. It may take slightly more time.

We propose to use Option-1. The first problem is topology representation. If PDF 2.0 does not include this in its description, we will use DOT-Specified network graph .

Post-Deployment Software Validation : State


Sl. No.Validation TypeDescription
1Container or POD StatusEnsure container status is OK. Detect failed containers and raise an error
2Required Container ports are openEnsure relevant docker containers are up and running, with ports open to listen
3ntpVerify all deployed nodes have their clock synchronized
4OVS-DPDK ConfigurationValidates OVS DPDK PMD cores from all NUMA nodes
5RabbitMQ LimitsMake sure the rabbitmq file descriptor limits are set to reasonable values
6Service StatusDetect services status on the target host and fails if we find a failed service.
7SELinuxEnsure we don’t have any SELinux denials on the system
8TLS configurationEnsure endpoints are secured.
9Storage (Ceph) Health CheckHealth should be OK


Post-Deployment Software Validation: Security


Sl. No.Validation TypeDescription
1Security: Right File Permissionshttps://docs.openstack.org/security-guide/checklist.html
2Security: Right Configurations




Readouts


SDVState readouts

ReadoutAuthorSlidesNotes
SDVState announcement at LFN Mentorship Project PresentationParth Yadav

View file
nameSDV State Validation.pdf
height150