Skip to content

Latest commit

 

History

History
344 lines (230 loc) · 10 KB

CNF_TESTSUITE_YML_USAGE.md

File metadata and controls

344 lines (230 loc) · 10 KB

Test Suite Configuration Usage: cnf-testsuite.yml

What is the cnf-testsuite.yml and why is it required?:

The cnf-testsuite.yml is used by cnf_setup in order to install the CNF to be tested onto an existing K8s cluster.

The information in the cnf-testsuite.yml is also used for additional configuration of some tests e.g. white_list_container_names is used for exculding containers from the privileged_containers container test.

Table of Contents

Overview of all cnf-testsuite.yml

The following is a basic working example cnf-testsuite.yml file that can be found in the cnf-testcatalog respository: cnf-testcatalog/spec/fixtures/cnf-testsuite-v2-example.yml

---
config_version: "v2"
common: 
  container_names:
    - name: coredns
      rolling_update_test_tag: "1.8.0"
      rolling_downgrade_test_tag: 1.6.7
      rolling_version_change_test_tag: 1.8.0
      rollback_from_tag: 1.8.0

deployments:
  helm_charts:
    - name: coredns
      helm_repo_name: stable
      helm_repo_url: https://cncf.gitlab.io/stable
      helm_chart_name: coredns
#  helm_dirs:
#    - name: envoy
#      helm_directory: ../example-cnfs/envoy/envoy
#  manifests:
#    - name: nginx
#      manifest_directory: manifests

Generator Quick Start

cnf-testsuite.yml can be dynamically generated by running ./cnf-testsuite generate_config. The process is interactive an should be friendly to new users. Prereqs: You must have kubernetes cluster, curl, and helm 3.1.1 or greater on your system already.

Updating config from older versions

New releases may change the format of cnf-testsuite.yml. To update your older configs automatically to the latest version, use the update_config task.

./cnf-testsuite update_config input_config=OLD_CONFIG_PATH output_config=NEW_CONFIG_PATH

Keys and Values

Config version

Current config version is "v2" Missing config version is presumed to be config version "v1", which is not supported, but should be transformed to new version if written correctly.

Common Parameters

Common parameters are required for proper functioning of some tests. If these parameters are not set up, corresponding tests will be failed/skipped or would not function properly (in example - whitelist_container_names). common: ...

container_names

Array of container parameters for rolling version change tests, example: name: coredns rolling_update_test_tag: 1.8.0 rolling_downgrade_test_tag: 1.6.7 rolling_version_change_test_tag: 1.8.0 rollback_from_tag: 1.8.0

whitelist_container_names

The values of this key are the names of the 'containers' defined in the Kubernetes pod spec of pods that are allowed to be running in privileged mode. (Optional) This value is used to allow 'particular' pods to run in privileged mode on the K8s cluster where the CNF is installed. The reason this is needed is because the Test Suite will check, 'all' pods in the cluster, to see if they're running in privileged mode. This is done because it's a common cloud-native practice to delegate 'privileged' networking tasks to only a single app e.g. Multus, NSM vs making the CNF privileged itself. As a consequence the whitelist can only be used to exempt 'privileged' infrastructure services running as pods e.g. NSM, Multus and cannot be used to exempt the CNF under test.

Example setting:

white_list_container_names: [coredns]

docker_insecure_registries

The docker client expects the image registries to be using an HTTPS API endpoint. This option is used to configure insecure registries that the docker client should be allowed to access.

This parameter is responsible for configuring Docker to use HTTP when accessing the registry API.

For an image registry service named foobar, running in default namespace, on port 5000, the following would be the expected configuration.

docker_insecure_registries: ["foobar.default.svc.cluster.local:5000"]
image_registry_fqdns

When using a private registry hosted on the cluster, the image references in the CNF's helm chart may refer to the registry host with the Kubernetes service name alone. The CNF Testsuite runs a docker daemon in a separate cnf-testsuite namespace on the Kubernetes cluster. So it is required for the testsuite to be aware of the FQDN of the service, along with the port.

Use this option to configure FQDNs of image registries for the testsuite to access.

If the CNF's helm charts use the image url foobar:5000/hello:latest, then please use the configuration in below in cnf-testsuite.yml to provide the FQDN mapping for the image registry.

image_registry_fqdns:
    "foobar:5000": "foobar.default.svc.cluster.local:5000"
five_g_parameters

Described below: link

Dynamic parameters

Dynamic parameters are not meant to be set up manually. They exist due to limitations of testsuite design.

source_cnf_dir

Directory where config is located.

destintaion_cnf_dir

Internal directory where CNF installation files are copied, currently in cnfs folder

installation_method

Installation method of the CNF and additional info according to it.

Deployments

Deployments are defined as three arrays, each for different installation method. Each array element represents one deployment, and they are meant to represent a single CNF together (Not implemented yet). At least one deployment should exist in CNF config for it to be a proper config. All info for deployments is used in cnf_setup and cnf_cleanup tasks.

deployments:
  helm_charts:
  ...
  helm_dirs:
  ...
  manifests:
  ...
helm_charts

Deployment, defined by helm chart and helm repository. Helm repository name and url can be omitted if repository is already present locally. Explanations with example:

helm_charts:
  - name: coredns  # Name of the deployment
    helm_repo_name: stable  # Name of the repository for the helm chart
    helm_repo_url: https://cncf.gitlab.io/stable  # Repository URL
    helm_chart_name: coredns  # Name of the helm chart in format repo_name/chart_name
    helm_values: --set myvalue=42 # Additional values that would be used for helm installation
    namespace: cnf-default # Namespace to which deployment would be installed (cnf-default is default)
helm_dirs

Deployment, defined by directory with Chart.yaml file and all templates for resources. Explanations with example:

helm_dirs:
  - name: envoy  # Name of the deployment
    helm_directory: chart  # Path to the directory with Chart.yaml, relative to CNF configuration file
    helm_values: --set myvalue=42 # Additional values that would be used for helm installation
    namespace: cnf-default # Namespace to which deployment would be installed (cnf-default is default)
manifests

Deployment, defined by directory with manifest files, that are meant to be directly installed by Kubernetes. Explanations with example:

manifests:
  - name: nginx  # Name of the deployment
    manifest_directory: manifests  # Path to the directory with deployment manifests, relative to CNF configuration file

5G Parameters

These parameters are used for RAN, Open5gs and UERANSIM tests

ric_label

The ran tests expect a ric to be configured under the ric_label. The entry must be the k8s label which is most likely a full key/value identification.

For a ric named flexrric, under the label key app.kubernetes.io/name the following would be the expected configuration.

ric_label:  app.kubernetes.io/name=flexric

mmc

Mobile Country Code. This identifies the country of the mobile subscriber. In this case, '999' is a test code.

dmmc: '999

mnc

Mobile Network Code. This identifies the mobile network within the country specified by the MCC. '70' is a test code.

mnc: '70'

sst

Single-NEC Single Radio Voice Call Continuity. This value indicates the type of services a Slice/Session should support.

sst: 1

sd

Slice Differentiator. This is used to differentiate between different slices within the same SST.

sd: '0x111111'

tac

Tracking Area Code. This is used for paging procedures and to manage mobility between eNBs in LTE.

tac: '0001'

protectionScheme

The type of security protocol being used.

protectionScheme: 1

publicKey

This is the public key used in asymmetric encryption.

publicKey: 0ac95ceeb93308df01be82ff9994d8330e38804ece1700ee4b972d8028796275

publicKeyId

Identifier for the public key.

publicKeyId: 1:

routingIndicator

This is used to route messages in the network.

routingIndicator: '0000'

enabled

Indicates whether the network is currently enabled or not.

enabled: true

count

Used in UERANSIM to specify the number of entities (like User Equipment or UEs) to be simulated.

count: 1

initialMSISDN

This MSISDN is a unique number that identifies a subscription in a GSM or a UMTS mobile network.

initialMSISDN: '0000000001'

key

Cryptographic key used in the network.

key: 465B5CE8B199B49FAA5F0A2EE238A6BC:

op

The operator variant algorithm configuration field. Used in conjunction with the key for security purposes.

op: E8ED289DEBA952E4283B54E88E6183CA

opType

Indicates that the operator variant algorithm is in use.

opType: OPC

type

The type of IP addresses being used in the network.

type: 'IPv4'

apn

Access Point Name. This is the name of a gateway between a GPRS, 3G or 4G mobile network and another computer network, frequently the public internet.

apn: 'internet'

emergency:

Indicates whether this is an emergency APN.

emergency: false