openshift-kni / cnf-features-deploy

Kustomize configs for installing CNF features and e2e functional tests for verifying feature deployment/integration
Apache License 2.0
57 stars 134 forks source link

Overview

This repo contains example kustomize configs used to installed openshift features required for CNF workloads and a e2e functional test suite used to verify CNF related features.

Contributing kustomize configs

All kustomize configs should be entirely declarative in nature. This means no bash plugin modules performing imperative tasks. Features should be installed simply by posting manifests to the cluster. After posting manifests, determining when the cluster has converged on those manifests successully should be observable.

Usage

Prerequisites

You can run make setup-test-cluster to have the first two (or the first in case of only one) workers labeled as worker-cnf and to have the MachineConfigPool created.

Configuring

All the Makefile rules depend on two environment variable, either for deploying, waiting and choosing what tests to run.

FEATURES

e.g. FEATURES="sctp ptp sriov", drives what features are going to be deployed using kustomize, and what tests are going to be run.

The current default values is "sctp performance"

e.g. FEATURES="sriov" FOCUS_TESTS="operator.Generic.SriovNetworkNodePolicy.Resource.Injector operator.Generic.SriovNetworkNodePolicy.VF.flags", drives sriov deployment using kustomize, and two sriov tests are going to be run.

FEATURES_ENVIRONMENT

i.e. FEATURES_ENVIRONMENT=demo determines the kustomization layer that will be used to deploy the choosen features.

The current default value is e2e-gcp

Deployment

For each feature choosen via FEATURES we expect to have a layer either in feature-configs/deploy or in feature-configs/$FEATURES_ENVIRONMENT.

Testing

We expect to have a section of the test suite named after each feature we want to test (for example sctp named after the sctp feature).

External tests are consumed as dependencies and ran as part of this same suite.

origin-tests

Verifies behavior of an OCP cluster by running remote tests against the cluster API that exercise functionality. These tests may be disruptive.

Running a dockerized version of origin-tests from quay.io/openshift/origin-tests. The full test suite can be found at https://github.com/openshift/openshift-tests.

Custom RPMs

The custom RPMs utility allows to install RPMs from an external source on an OCP node. RPMS_SRC (RPMs download source URL) must be provided. REMOVE_PACKAGES should be set when installing RT kernel RPMs to override the installed kernel packages (no need to set it when replacing a regular kernel with a different regular kernel or a RT kernel with a different RT kernel). RPMS_NODE_ROLE is optional and defaults to node-role.kubernetes.io/worker.

The CNF-Tests Container (Latency Tests)

A dockerized version of the Node Tuning Operator latency test suite available at quay.io/openshift-kni/cnf-tests. For more details on how to use it, please check the official docs.

The Conformance tests

The conformance test suites verify that the operators we maintain are working properly on CNF enabled cluster. Nightly upstream ci jobs are using those tests, triggered from the openshift/release ci-operator link. For more details, see cnf-tests/README.md

Zero-Touch Provisioning for RAN

Zero-touch provisioning enables a gitops-based flow for deploying and configuring OpenShift for RAN applications.

For an overview, see ztp/gitops-subscriptions/argocd/README.md

Release Branching

This repository follows the same version numbering and release branching schedule as OpenShift: https://docs.ci.openshift.org/docs/architecture/branching/

Branching

  1. Create a new 'release-x.y' branch and push it into Git
  2. Advance the CI configuration in openshift/release to create new lanes for the release branch and move the master along to the next release version number
  3. Change the ZTP templates examples label du-profile: latest under gitops-subscriptions/argocd/example to match the branch release-x.y
  4. Pin all midstream branches to the new release branch, and create new midstream branches for the next release