chore(ci): configure nested e2e cluster for nightly tests

[universal-itengineer]

Description

This PR adds support for automated E2E testing of the Virtualization module in nested clusters for nightly tests. A complete infrastructure is implemented for deploying a static Deckhouse cluster with support for various storage types (Ceph and Replicated), configuring the Virtualization module, and running E2E tests.

Key Changes:

• New reusable workflow (.github/workflows/e2e-reusable-pipeline.yml) for E2E testing with parameterization support
• Updated matrix workflow (.github/workflows/e2e-matrix.yml) with support for running tests for different storage types
• Static cluster infrastructure (test/dvp-static-cluster/) including:
  • Helm charts for cluster and infrastructure configuration
  • Scripts for kubeconfig generation and Deckhouse queue management
  • Storage configurations (Ceph and SDS Replicated)
• CI/CD improvements:
  • Automatic generation and configuration of kubeconfig for nested cluster
  • Storage setup (Ceph/RBD and SDS Replicated)
  • Virtualization module configuration with support for various storage classes
  • Collection and reporting of test results
• Dependency updates: updated deckhouse_lib_helm from version 1.55.1 to 1.65.2
• Various fixes in templates and configurations

Why do we need it, and what problem does it solve?

Problems Solved by This PR:

1. Lack of automated E2E testing in nested clusters: Previously, there was no way to automatically test the Virtualization module in real nested cluster conditions with various storage types.

2. Lack of coverage for different storage scenarios: There was no unified mechanism for testing the Virtualization module with different storage types (Ceph, Replicated) within a single CI/CD process.

3. Need for nightly testing: Infrastructure was required for regularly running long-running E2E tests at night without blocking development.

Solution Benefits:

• Automation: Fully automated process of cluster deployment, storage configuration, Virtualization module setup, and test execution
• Scalability: Reusable workflow allows easy addition of new storage types and configurations
• Reliability: Automatic checks at each stage of deployment and configuration
• Transparency: Centralized test result reports with delivery to communication channels
• Flexibility: Parameterization allows testing different versions of Deckhouse and Virtualization module

What is the expected result?

1. Automatic nested cluster deployment:

   • Creation of a static Deckhouse cluster using VMs
   • Automatic configuration of networks, pods, and services
   • Generation and configuration of kubeconfig for accessing the nested cluster

2. Storage setup:

   • Automatic configuration of Ceph/RBD storage with creation of necessary resources (StorageClass, CephCluster, BlockPool)
   • Automatic configuration of SDS Replicated storage with creation of LVM Volume Groups and ReplicatedStorageClass
   • Verification of storage readiness before use

3. Virtualization module configuration:

   • Automatic enabling of the Virtualization module in the nested cluster
   • DVCR (Deckhouse Virtual Container Registry) configuration using the appropriate StorageClass
   • CIDR configuration for virtual machines
   • Waiting for module components to be ready (virt-handler, virt-controller, etc.)

4. E2E test execution:

   • Automatic launch of E2E tests in the configured environment
   • Support for timeouts and error handling
   • Collection of test results

5. Reporting:

   • Generation of JSON reports with test results
   • Generation of JUnit XML reports for integration with CI/CD systems
   • Automatic sending of summary reports to communication channels with information about test status for each storage type

6. Nightly testing support:

   • Ability to run long-running E2E tests at night via workflow_dispatch
   • Parallel execution of tests for different storage types
   • Efficient resource usage with concurrency group support

7. Improved debugging:

   • Detailed logging at each stage of the process
   • Preservation of artifacts (kubeconfig, reports) for subsequent analysis
   • Informative error messages indicating the stage where the failure occurred

Technical Improvements:

• Updated Helm library to the latest version (1.65.2)
• Improved error handling and retry logic
• Optimization of execution time through parallel component configuration where possible
• Improved code structure with separation into reusable components

Checklist

• The code is covered by unit tests.
• e2e tests passed.
• Documentation updated according to the changes.
• Changes were tested in the Kubernetes cluster manually.

Changelog entries

section: ci
type: feature
summary: e2e nightly test in nested cluster