mirror of
https://github.com/aljazceru/kata-containers.git
synced 2025-12-17 06:14:26 +01:00
034d7aab87
With these 2 simple checks we can ensure that we do not regress on the behaviour of allowing the runtime classes / default runtime class to be created by the kata-deploy payload. Fixes: #7491 Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
29 lines
1013 B
Bash
29 lines
1013 B
Bash
#!/usr/bin/env bats
|
|
#
|
|
# Copyright (c) 2023 Intel Corporation
|
|
#
|
|
# SPDX-License-Identifier: Apache-2.0
|
|
#
|
|
|
|
load "${BATS_TEST_DIRNAME}/../../common.bash"
|
|
load "${BATS_TEST_DIRNAME}/tests_common.sh"
|
|
|
|
setup() {
|
|
# We expect 2 runtime classes because:
|
|
# * `kata` is the default runtimeclass created, basically an alias for `kata-${KATA_HYPERVISOR}`.
|
|
# * `kata-${KATA_HYPERVISOR}` is the other one
|
|
# * As part of the tests we're only deploying the specific runtimeclass that will be used, instead of all of them.
|
|
expected_runtime_classes=2
|
|
}
|
|
|
|
@test "Test runtimeclasses are being properly created" {
|
|
# We filter `kata-mshv-vm-isolation` out as that's present on AKS clusters, but that's not coming from kata-deploy
|
|
current_runtime_classes=$(kubectl get runtimeclasses | grep -v "kata-mshv-vm-isolation" | grep "kata" | wc -l)
|
|
[[ ${current_runtime_classes} -eq ${expected_runtime_classes} ]]
|
|
[[ $(kubectl get runtimeclasses | grep -q "${KATA_HYPERVISOR}") -eq 0 ]]
|
|
}
|
|
|
|
teardown() {
|
|
kubectl get runtimeclasses
|
|
}
|