EnvTest - Does not Accept Some Custom Resources

[DanArlowski]

Referencing the Issue created in Operator-SDK - https://github.com/operator-framework/operator-sdk/issues/5514

Technically - When you create an envtest using ginko, and adding resources to the scheme, It looks like cluster wide resources are not being accepted (They are added to the scheme, but the envtest API rejects their creation:

1.6487184909959798e+09  ERROR   controller.<name>      Reconciler error        {"reconciler group": "<group>", "reconciler kind": "<Kind>", "name": "<name>, "namespace": "", "error": "no matches for kind \"Project\" in version \"project.openshift.io/v1\""}
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem
        <home>/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:266
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2
        <home//go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:227

This is the logs from the unittest custom operator creating the resource,

the exact same resource getting applied on a runtime-cluster, and not envtest.

We managed to add custom resources to the scheme, but only namespaced ones (openshift route, for instance) But both Openshift Project, and SecurityContextConstraint (Openshift, too) were added to the scheme but rejected by the EnvTest.

Another Cause may be because these 2 object extend existing k8s functionality (namespace, securityContext), so it may be the root cause of that.

Thought I'd opened an issue here too, as it might not be completely Openshift & Operator-SDK Related and might be related to the Envtest Behaviour.

[camilamacedo86]

It shows that you did not register the Kind. You need to inform the API/Kind so that is possible to use them.

[DanArlowski]

Sorry for not being fully detailed.

I install the kind:

	err = projectv1.Install(scheme.Scheme)
	Expect(err).ShouldNot(HaveOccurred())

In the envtest test-suite

I also install it in the operator itself main.go file:

utilruntime.Must(projectv1.AddToScheme(scheme))

So that is not the case. In the issue I referenced there are a bit more logs & code - Technically - the kind is getting registered sucsessfully (other resources are getting registered & Created correctly.

[jmrodri]

This issue seems similar to an old issue: https://github.com/kubernetes-sigs/controller-runtime/issues/1191

[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

[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.