Potential propsoal: Include Kubernetes Gomega extension with to make testing controllers easier

[JoelSpeed]

While building a number of controllers last year, a colleague and I came up with an extension to Gomega that allowed us to reduce a lot of boilerplate within our test suites. Our assertions ended up looking something like

m.Eventually(workerNode1, timeout).Should(utils.WithField("Spec.Taints",
	ContainElement(SatisfyAll(
		utils.WithField("Effect", Equal(corev1.TaintEffect("NoSchedule"))),
		utils.WithField("Key", Equal("node.kubernetes.io/unschedulable")),
	)),
))

To check that the node object eventually had a taint with the desired Key and Effect. The benefit here being that we knew what we wanted to test in a particular test case, we wanted to see the controller adding this taint, we didn't care what the rest of the object looked like so comparing a whole object was out of the question. The act of fetching and creating the async assertion is all captured by the custom matcher we wrote and our transformation utils.WithField allowed us to extract raw fields from any object passed so that we could use Gomega's core matching library to make asserations.

For comparison, the code to check there's a taint for this object in raw Gomega would look something like

Eventually(func() (bool, err) {
    node := &corev1.Node{}
    key := client.ObjectKey{Namespace: workerNode1.Namespace, Name workerNode1.Name}
    err := c.Get(ctx, key, node)
    if err != nil {
        return false, err
    }
    for _, taint := range node.Spec.Taints {
        if taint.Effect == corev1.TaintEffect("NoSchedule") && taint.Key == "node.kubernetes.io/unschedulable" {
            return true, nil
        }
    }
    return false, nil
}, timeout).Should(BeTrue())

It has long been on my mind that contributing this Gomega extension upstream may be desirable so that others can make use of it, but I hadn't got around to posting yet.

So my question to the community is, does this look like something that could be useful? Is it something you want to know more about? Would a PR to add this kind of extension be accepted? I am happy to share more if there is interest in adding this kind of thing to the kubebuilder/controller-runtime project

[vincepri]

This would be a great addition to controller-runtime

/milestone v0.7.x
/priority important-longterm

[vincepri]

/help

[k8s-ci-robot]

@vincepri:
This request has been marked as needing help from a contributor.

Please ensure the request meets the requirements listed here.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.

In response to this:

/help

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[JoelSpeed]

/remove-lifecycle stale

I'm hoping to get to this soon

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[JoelSpeed]

/remove-lifecycle stale

Have added a WIP PR to implement an initial version of this

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten

[MadhavJivrajani]

/remove-lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[fabriziopandini]

FYI In Cluster API we implemented something similar, wondering if it makes sense to merge those efforts...

[JoelSpeed]

I think having a generic central utility for this kind of thing makes sense, and the generic nature of the CAPI implementation of those matchers fits in with what I was envisioning here so totally up for including those as well if the community is happy to donate those to this effort

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue.

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.