Table of Contents
outline true

Introduction

...

Jenkins Information

...

To add more Jenkins slave nodes, please follow the Akriano Jenkins guide

To setup private Jenkins, please refer to the README.md under icn/ci/

...

• Triggered by gerrit patch creation/update. 
• The job runs verify.sh under ICN project. The verify.sh currently has integrated the golang test and bashate test.
• Post +1/-1 for gerrit patch if the build succeeds/fails
• Upload the job log to Nexus server in post-build actions

...

ICN Master Bare Metal Deployment Verifier

Image Removed

ICN Master Virtual Deployment Verifier

Image Removed

Bare metal deployment

...

Hostname

...

CPU Model

...

Memory

...

BMC 

Firmware

...

Storage

...

1GbE: NIC#, VLAN,

(Connected

Extreme 480 switch)

...

10GbE: NIC# VLAN, Network

(Connected with IZ1 switch)

...

40GbE: NIC#

...

Jump

...

Intel

2xE5-2699

...

64GB

...

3TB (Sata)
180 (SSD)

...

IF0: VLAN 110 (DMZ)
IF1: VLAN 111 (Admin)

...

IF2: VLAN 112 (Private)
VLAN 114 (Management)
IF3: VLAN 113 (Storage)
VLAN 1115 (Public)

...

node1

...

Intel

2xE5-2699

...

64GB

...

3TB (Sata)
180 (SSD)

...

IF0: VLAN 110 (DMZ)
IF1: VLAN 111 (Admin)

...

IF2: VLAN 112 (Private)
VLAN 114 (Management)
IF3: VLAN 113 (Storage)
VLAN 1115 (Public)

...

node2

Image Added

(image source: https://gerrit.akraino.org/r/gitweb?p=icn.git;a=blob;f=doc/pod11-topology.png)

• Baremetal network, lab networking for SSH, it is used as the control plane for K8s, used by OVN and Calico for the overlay networking with Internet access
• Provisioning network used by Ironic to do inspection and serve OS images (Will be having DHCP server)
• IPMI LAN to do IPMI protocols for the OS provisioning

ICN Master Virtual Deployment Verifier

Image Added

(image source: https://gerrit.akraino.org/r/gitweb?p=icn.git;a=blob;f=doc/vm-topology.png)

• Baremetal network is used as control plane for K8s, used by OVN and Calico for overlay network with NAT's Internet access
• Provisioning network used by Ironic to do inspection and server OS images
• Redfish protocol is executed over baremetal network using sushy-emulator

Bare metal deployment

Virtual deployment

Test Framework

All components are tested with end-to-end testing

Test description

Testing

CI Testing:

bashate:

The bashate test is to check the shell scripts code style. i.e. trailing white space. We find all files with suffix '.sh' and run bashate against the files. './cmd/bpa-operator/vendor/' directory is excluded.

golang testing:

BPA Operator: 

• The BPA operator has unit tests using the golang framework. The unit tests check the following:
  • Job is created with the right job name for KUD installation.
  • The job metadata has the right cluster name
  • Expected error is produced when a host with the specified MAC address is not found
  • Expected error is produced when no DHCP lease is found for the specified host

BPA Rest Agent:

• Currently, automated unit tests are implemented using the golang testing framework.

CD Verifier (end-to-end testing):

All the test case are tested as follows:

Metal3:

Metal3 verifier will check all the servers are provisioned, Metal3 verifier check the status of the bare metal servers for every 60 second for the provisioning status.

BPA Operator:

Bare Metal Host Provisioning

• The bpa_bmh_verifier.sh script gets the MAC addresses and IP addresses of the 2 VMs provisioned by Metal3, then creates a fake DHCP lease file using the IP address and MAC address information. It also creates a provisioning CR using the MAC address information
• The script the creates an ssh secret key using the ssh keys of the test host, applies the the provisioning CR
• The script busy loops till the KUD installation job completes or fails. If it completes successfully, it does a curl command using the authentication info of the new cluster to confirm if it was successful or not. On completing all the steps, it does a tear down step where it deletes everything it created.

BPA Rest Agent

• Test script, e2e_test.sh, creates dummy image file, creates test JSON file, checks BPA rest agent status, issues POST, GET, and PATCH requests sequentially.
• Next, e2e_test.sh checks uploaded MinIO image object size, and calls DELETE.
• If the script fails at any point then verification was unsuccessful.

Kubernetes Deployment (KUD)

...

Virtual deployment

Test Framework

All components are tested with end-to-end testing

Test description

Testing

CI Testing:

bashate:

The bashate test is to check the shell scripts code style. i.e. trailing white space. We find all files with suffix '.sh' and run bashate against the files.

CD Verifier (end-to-end testing):

All the test case are tested as follows:

Cluster API (infrastructure and bootstrap provisioning):

Verifier will check that servers are provisioned with OS and K8s control plane is ready.  The provisioning status is checked every 60 seconds.

Addons:

Test cases verify if the addons are running correctly. All the test Test cases can be found in tests directory in the multicloud-k8s project. For each of these, we bring up the deployment that is specific to the addon, perform addon specific actions on the pod related to the deploymentfound in the ICN deploy/addons, deploy/istio and deploy/kata directories.

Multus:

• Multus CNI is a container network interface (CNI) plugin for Kubernetes that enables attaching multiple network interfaces to pods. This is accomplished by Multus acting as a "meta-plugin", a CNI plugin that can call multiple other CNI plugins.
• A 'NetworkAttachmentDefinition' is used to set up the network attachment, i.e. secondary interface for the pod. 
• A pod is created with requesting specific network annotations with bridge CNI to create multiple interfaces. When CNI to create multiple interfaces. When the pod is up and running, we can attach to it to check the network interfaces on it by running ip a command

Nodus: 

• Nodus provide Provider networks using VLAN networking and Service Function Chaining.
• After the pod is up and running , we can will be able to attach to it to check the network interfaces on it by running ip a command

Nodus: 

• Nodus provide Provider networks using VLAN networking and Service Function Chaining.
• After the pod is up and running we will be able to attach to the pod and check for multiple interfaces created inside the container. 
• Nodus networking is setup and createdthe pod and check for multiple interfaces created inside the container. 
• Nodus networking is setup and created

Nodus Validation and test case results

Node Feature Discovery

• Node Feature Discovery for Kubernetes detects hardware features available on each node in a Kubernetes cluster and advertises those features using node labels.
• Create a pod with specific label information in the case the pods are scheduled only on nodes whose major kernel version is 3 and above. Since the NFD master and worker daemonset is already running, the master has all the label information about the nodes which is collected by the worker.
• If the OS version matches, the Pod will be scheduled and up. Otherwise, the Pod will be in a pending state in case there are no nodes with matching labels that are requested by the Pod

...

• CPU Manager for Kubernetes provides CPU pinning for K8s workloads. In KUD, there are two test cases for the exclusive and shared CPU pools testing.

EMCO:

• EMCO sanity testing check the health connectivity to EMCO micro services, once it is installed

SDEWAN:

• Use KUD to setup 3 clusters (sdewan-hub, edge-a, edge-b)
• Run the SDEWAN CRD Controller in each clusters.
• Create SDEWAN CNF instance and dummy pod (using httpbin instead) in edge-a, SDEWAN CNF instance and httpbin pod in edge-b
• Create IPSec CR to configure sdewan-hub as responder to provide virtual IP addresses to any authenticated party requesting for IP addresses through SDEWAN CRD Controller.
• Create IPSec CR to configure edge-a and edge-b IPSec configuration to get the IP addresses through SDEWAN CRD Controller.
• Establish edge-a tunnel to sdewan-hub, edge-b tunnel to sdewan-hub, and hub XFRM policies will automatically route traffic between edge-a and edge-b
• Create SNAT CR to establish SNAT rule in edge-a and DNAT CR to establish DNAT rule in edge-b which will enable TCP connection from edge-a to edge-b's httpbin service.
• Verify curl command is successful from edge-a dummy pod (using httpbin instead) to edge-b's httpbin service. The function of the curl command is to return back the ip address of the requester.

Image Removed

EMCO:

• EMCO sanity testing check the health connectivity to EMCO micro services, once it is installed

Image Added

BluVal Testing

Status as of July 7th 2021:

...

Layer

...

Result

...

Comments

...

os/lynis

...

PASS with exceptions

...

...

os/vuls

...

PASS with exceptions

...

...

k8s/conformance

...

PASS with exceptions

...

...

k8s/kube-hunter

...

PASS

...

...

Release 5 Blueprint Scanning StatusRelease 6 Blueprint Scanning Status

Akraino CVE Vulnerability Exception Request

Akraino BluVal Exception Request

CD logs

...

ICN Master Bare Metal Deployment Verifier

ICN Master Virtual Deployment Verifier

ICN SDEWAN Master End2End Testing

...