Controller-runtime: Fake client doesn't apply the FieldSelector options on List

Created on 19 Mar 2020  路  14Comments  路  Source: kubernetes-sigs/controller-runtime

Currently the fake client doesn't apply the ListOptions.FieldSelector to filter results when using the List function.

Here is the current fake client's List function code:

gvk, err := apiutil.GVKForObject(obj, c.scheme)
    if err != nil {
        return err
    }

    if !strings.HasSuffix(gvk.Kind, "List") {
        return fmt.Errorf("non-list type %T (kind %q) passed as output", obj, gvk)
    }
    // we need the non-list GVK, so chop off the "List" from the end of the kind
    gvk.Kind = gvk.Kind[:len(gvk.Kind)-4]

    listOpts := client.ListOptions{}
    listOpts.ApplyOptions(opts)

    gvr, _ := meta.UnsafeGuessKindToResource(gvk)
    o, err := c.tracker.List(gvr, gvk, listOpts.Namespace)
    if err != nil {
        return err
    }
    j, err := json.Marshal(o)
    if err != nil {
        return err
    }
    decoder := scheme.Codecs.UniversalDecoder()
    _, _, err = decoder.Decode(j, nil, obj)
    if err != nil {
        return err
    }

    if listOpts.LabelSelector != nil {
        objs, err := meta.ExtractList(obj)
        if err != nil {
            return err
        }
        filteredObjs, err := objectutil.FilterWithLabels(objs, listOpts.LabelSelector)
        if err != nil {
            return err
        }
        err = meta.SetList(obj, filteredObjs)
        if err != nil {
            return err
        }
    }
    return nil
help wanted kinfeature lifecyclrotten prioritimportant-longterm

All 14 comments

/kind feature
/help
/priority important-longterm

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

/kind feature
/help
/priority important-longterm

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.

@vincepri Maybe I can work for it?

Go for it, @LeoLiuYan

/assign

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

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-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

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

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/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.

This sounds useful, can somebody reopen it please?

/reopen

@invidian: You can't reopen an issue/PR unless you authored it or you are a collaborator.

In response to this:

This sounds useful, can somebody reopen it please?

/reopen

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.

@invidian Are you interested in implementing this? If so, please open a Pull Request and reference this issue and we'll sort it out.

I'm not sure if I find time to implement this, as I can workaround it by putting required information in label for now.

I am also interested in this and is quite annoying for me that I cannot even inject custom behaviour in the fake client. I am willing to work on adding this feature if someone has any suggestions how to incorporate it. I saw how the kubernetes API implements this here. I think this would mean that the fakeClient.ClientBuilder should get a slice of fieldIndexers/fieldMappers that are able to create a map with field name and field value for objects. This would probably mean that those indexers/mappers need to be type specific. Then we should make sure those are applied when filtering.

Was this page helpful?
0 / 5 - 0 ratings