📞📱☎️📡🌐 Cloud Native Telecom Initiative (CNTI) Test Catalog is a tool to check for and provide feedback on the use of K8s + cloud native best practices in networking applications and platforms
Is your feature request related to a problem? Please describe.
The clusterapi_enabled test only checks surface-level information without verifying the functionality of the cluster. The current test checks two things:
Clusterapi is installed.
Some node is being managed.
The problematic check is the number two which only checks that a resource exists, not its status, which as you can see here is quite bad in my case and passes anyway:
kubectl get kubeadmcontrolplanes.controlplane.cluster.x-k8s.io -o json
...
"status": {
"conditions": [
{
"lastTransitionTime": "2024-04-17T08:01:26Z",
"message": "Scaling up control plane to 3 replicas (actual 0)",
"reason": "ScalingUp",
"severity": "Warning",
"status": "False",
"type": "Ready"
},
{
"lastTransitionTime": "2024-04-17T08:01:26Z",
"message": "Scaling up control plane to 3 replicas (actual 0)",
"reason": "ScalingUp",
"severity": "Warning",
"status": "False",
"type": "Resized"
}
],
"observedGeneration": 1,
"selector": "cluster.x-k8s.io/cluster-name=capi-quickstart,cluster.x-k8s.io/control-plane"
}
Describe the solution you'd like
It would be great to do some in-depth checks verifying that the cluster is functional (i.e. scaling the cluster/deploying some application on it/monitor what is being managed by the workload cluster/verifying that the management cluster is not doing stuff it should not). Admittedly when someone is using clusterapi it is likely that they have it in operational state.
Describe alternatives you've considered
If the aim of the test is simply to verify surface-level functionality, the second check might as well be unnecessary since the first check makes sure that clusterapi is present (which is what the second one does in a roundabout way).
How will this be tested? aka Acceptance Criteria
Needs a deeper discussion (since my knowledge of the matter is very limited), different providers may access some things differently further complicating in-depth verification.
Is your feature request related to a problem? Please describe. The
clusterapi_enabledtest only checks surface-level information without verifying the functionality of the cluster. The current test checks two things:The problematic check is the number two which only checks that a resource exists, not its status, which as you can see here is quite bad in my case and passes anyway:
Describe the solution you'd like It would be great to do some in-depth checks verifying that the cluster is functional (i.e. scaling the cluster/deploying some application on it/monitor what is being managed by the workload cluster/verifying that the management cluster is not doing stuff it should not). Admittedly when someone is using clusterapi it is likely that they have it in operational state.
Describe alternatives you've considered If the aim of the test is simply to verify surface-level functionality, the second check might as well be unnecessary since the first check makes sure that clusterapi is present (which is what the second one does in a roundabout way).
How will this be tested? aka Acceptance Criteria Needs a deeper discussion (since my knowledge of the matter is very limited), different providers may access some things differently further complicating in-depth verification.