Fakeclient requires types read through unstructured to be registered in the scheme

[alvaroaleman]

Writing a test that uses the fakeClient for code that uses *unstructured.UnstructuredList to list something, the test fails with a

failed to list ImageRegistryConfigs: non-list type *unstructured.UnstructuredList (kind "my-api/v1, Kind=Config") passed as output

The same code works fine when using a non-fake client.
/kind bug

[alvaroaleman]

Okay so actually it seems I should have just read the error message, because I didn't pass in the ListType which happens to work with the non-fake client.

However after fixing that, the next error is this:

deletion_test.go:155: Deletion failed: failed to cleanup TYPE: failed to list TYPE: no kind "TYPEList" is registered for version "APIVERSION" in scheme "k8s.io/client-go/kubernetes/scheme/register.go:65"

This issue seems to be rooted in the underlying object tracker used by the fake client. Not sure if and how to fix it. Maybe register *unstructured.Unstructured for the given GVK?

Not being able to use *unstructured.Unstructered with an unregistered GVK defeats the reason of using it in the first place.

[DirectXMan12]

I think the objectracker needs to use the passed-in scheme, not the kubernetes scheme -- use NewFakeClientWithScheme instead of NewFakeClient (which totally violates our controller-runtime API conventions, but that's a whole different story...)

[alvaroaleman]

I think the objectracker needs to use the passed-in scheme, not the kubernetes scheme -- use NewFakeClientWithScheme instead of NewFakeClient (which totally violates our controller-runtime API conventions, but that's a whole different story...)

The problem is that it requires the type I am trying to get via an unstructured.Unstructured to be registered. But the reason I am using unstructured.Unstructured in the first place is that I do not have the go types.

[DirectXMan12]

oh, yeah, sorry, triaging too fast :-P

[DirectXMan12]

need to dig into objecttracker here probably

/help

[k8s-ci-robot]

@DirectXMan12:
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:

need to dig into objecttracker here probably

/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

[DirectXMan12]

/remove-lifecycle stale

[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

[DirectXMan12]

/lifecycle frozen

[mittachaitu]

Is there any specific reason to add this check?

[alvaroaleman]

Is there any specific reason to add this check?

I think now that we changed the interface of List to take an client.ObjectList as second argument instead of a runtime.Object we can remove that check. Alternatively, we can skip the check if the incoming type is an *unstructured.UnstructuredList

[kellengreen]

Hello all, is there a workaround for this at the moment?

[alvaroaleman]

Not to my knowledge. We are happy to take a PR for this that changes the client to work with both UnstructuredList and SomeObjectList if someone is interested.

[mittachaitu]

I would like to fix this issue

[mittachaitu]

Hello all, is there a workaround for this at the moment?

Yes, I think we have to make in the following way

list := &unstructured.UnstructuredList{}
list.SetAPIVersion("apps/v1")
list.SetKind("DeploymentList")
err = cl.List(context.TODO(), list)

It make sense to set APIVersion and Kind while making a query with unstructuredlist.

Note: We have to setAPIVersion and Kind before making call to List func

[xenolog]

I confirm, this workaround is good.

[alvaroaleman]

@mittachaitu @xenolog this bug report isn't about the issue you are describing, see the second message. I have retitled it to make that clearer. What you are describing is a different issue, I've opened a fix for that: #1467

[slintes]

Hi, is anyone working on this? My team is hitting this issue and we can spend some time trying to fix it.

[alvaroaleman]

@slintes no, feel free to pick it up!

[wbrefvem]

@alvaroaleman I'm not sure if this is the same issue, but I noticed that if I set the GVK for the UnstructuredList, fake client does fetch the correct list, but it still errors because client-go returns a list of the underlying type instead of Unstructured. Fake client tries to populate the UnstructuredList with objects of the underlying type, which produces an error.

Again, not sure if it's related, and not sure if I know an elegant fix. Explicitly handling UnstructuredList as a special case in fakeClient.List would work (i.e., just convert the items in the list that client-go returns to Unstructured), but that seems clunky and brittle.

[alvaroaleman]

Sounds like a different but potentially related issue. This is about fetching objects through unstructured that are not registered in the Scheme, which implies that client-go is never going to return something other than Unstructured{,List}

[alvaroaleman]

/assign