kuttl
kuttl copied to clipboard
Allow assert of a key inside a resource without defining the actual value
What would you like to be added: A way to assert that a key in a resource is set, but without actually defining the value of that key - normally, because it will contain a semi-random value.
Why is this needed:
For example to check if cert-manager has inserted the caBundle
into a resource. The caBundle value will be semi-random, so we can't put the value inside the 00-assert.yaml
, but we still want to make sure that they key is set:
apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
metadata:
name: cert-manager-webhook
webhooks:
- clientConfig:
caBundle: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUJvakNDQVNpZ0F3SUJBZ0lRYk1yekNyRUVLUVpsWjQ4eXRHYndQREFLQmdncWhrak9QUVFEQXpBaU1TQXcKSGdZRFZRUURFeGRqWlhKMExXMWhibUZuWlhJdGQyVmlhRzl2YXkxallUQWVGdzB5TURFd01USXhNekUwTVRaYQpGdzB5TVRFd01USXhNekUwTVRaYU1DSXhJREFlQmdOVkJBTVRGMk5sY25RdGJXRnVZV2RsY2kxM1pXSm9iMjlyCkxXTmhNSFl3RUFZSEtvWkl6ajBDQVFZRks0RUVBQ0lEWWdBRTVhaDlkbTFneGcxOFhLK1ZPQXZoT3l6TVIwbjIKRExJTlY3U2gxRzNQd1Z2N1pOZHpyRThxb0xGY3BZc2ZFc0k3cFQ5dlZOV0h3c1UrTU9pNlBob3NLbkRkSGNsagpmOXZnZ3JzSG1DK2RRR1FFdlFOV3AyajN5SUtBTGVjS0FpR0NveU13SVRBT0JnTlZIUThCQWY4RUJBTUNBcVF3CkR3WURWUjBUQVFIL0JBVXdBd0VCL3pBS0JnZ3Foa2pPUFFRREF3Tm9BREJsQWpFQXNZbEVDRU40UHVjdnJJNzAKU2ErZU5LRDBFd095UzE3NCtvdzlzKzlmU2p0MTRNTklVczlZUkhVUEdWVElXR1BQQWpCb3d1eDMxZmI1U1RlcgpXMTkrYnhjN1lrZUR0ODMvbEdNbDVCRW96RmVrRjdoVGFUVkZ0eDJ5L3h0b0JqdWsyakE9Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
An assert could maybe look like:
apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
metadata:
name: cert-manager-webhook
webhooks:
- clientConfig:
caBundle: ***
?
kuttl current does very little to the declared assert files... however... there are lots of requests for this kind of ability. we need to put some thought on a good approach. This seems like a very useful enhancement.
This is somewhat related to #76 in the sense that both probably need some kind of a language to express the condition.
It would be good to think about both (and other related issues like value equal to or more than X
) when solving this.
yeah... we are thinking along the same lines!
This enhancement is exactly what we need for testing whether a deployment succeeded or failed, because when a Deployment succeeds, the state.readyReplicas
key is available. But it might have any number of replicas.
An assertion of this kind then becomes difficult to achieve.
apiVersion: v1
kind: Deployment
metadata:
namespace: kube-system
status:
readyReplicas: 1
# but can be any number, say "n"
thanks @rishinair11 ! it helps to prioritize and make we have this use case covered!
Another example requiring this type of partial matching asserter occurs when you're using kuttl to validate if the resources are set for deployments with integration level tests. Not caring about the specific values - just that they are set. So definitely a +1 for me.