Skip to content

summary-dev-production.md

Latest commit

 

History

History
54 lines (38 loc) · 3.25 KB

summary-dev-production.md

File metadata and controls

54 lines (38 loc) · 3.25 KB

Certsuite Script Modification: Operand Installation

Why

The certsuite batch script (run-basic-batch-operators-test.sh) installs operators via OLM but has no generic way to install operands. Without operands running, certification tests can't exercise real workloads. Today, only multicluster-engine has a hardcoded CR creation block (lines 775-791). We need a generic system that works for any operator.

What We're Adding

A generic operand installation system that reads test bundles from the TestConfigurationBundle repo. After each operator's CSV succeeds, the script:

  1. Looks up the operator in operator-map.yaml
  2. Applies 00-prerequisites.yaml if present (namespaces, RBAC)
  3. Applies 01-operand-crs.yaml to deploy operand CRs
  4. Runs 02-validate.sh to confirm the operand is healthy
  5. After tests, runs teardown.yaml to clean up

Bundle Source Roadmap

Phase Source How it works
Now Centralized repo (TestConfigurationBundle) Clone once at script start, look up bundles via operator-map.yaml
Future Operator's own repo oc get packagemanifest <name> discovers repo URL, clone it, find bundle at test/certification/

A TEST_BUNDLE_SOURCE variable (centralized by default) controls which mode is used. Switching to packagemanifest later requires implementing one function (get_bundle_dir) — no structural changes to the rest of the script.

Why We Keep the multicluster-engine Block

The existing hardcoded multicluster-engine block (lines 775-791) stays in place:

  • It works today — proven and tested in production
  • The bundle system is new — replacing working code with untested code is unnecessary risk
  • No bundle exists for multicluster-engine yet — removing the block would break existing behavior

The generic install_operands call runs after the multicluster-engine block. Once a bundle for multicluster-engine is created and verified, the hardcoded block can be removed in a follow-up PR.

Script Changes Summary

Change Location Description
Input variables After line 38 TEST_BUNDLE_SOURCE, TEST_BUNDLE_REPO, TEST_BUNDLE_BRANCH, TEST_BUNDLE_DIR
clone_test_bundles() New function Shallow clones the centralized repo to a temp dir
get_bundle_dir() New function Returns bundle path for an operator; single switchpoint for centralized vs packagemanifest
install_operands() New function Applies prerequisites, 01-operand-crs.yaml, runs 02-validate.sh
teardown_operands() New function Applies teardown.yaml before operator uninstall
Clone call After catalog setup clone_test_bundles called after wait_all_packages_ok
Install call After line 791 install_operands called after the multicluster-engine block
Teardown call Before line 875 teardown_operands called before operator uninstall
Cleanup After line 948 Remove temp dir after catalog deletion

Dependencies

  • yq must be available to parse YAML files (operator-map.yaml, metadata.yaml)
  • Bundle files follow numbered convention: 00-prerequisites.yaml, 01-operand-crs.yaml, 02-validate.sh
  • The existing script uses jq for JSON; yq is a new dependency