kubernetes: Namespaced CRD cannot used label selector

Is this a BUG REPORT or FEATURE REQUEST?:

/kind bug

What happened:

When listing a namespaced CRD with a valid label selector no results are returned

What you expected to happen:

Results returned

How to reproduce it (as minimally and precisely as possible):

  1. Create a namespaced CRD.
  2. Create a resource with that CRD with labels
  3. List the resources with a valid label selector

Anything else we need to know?:

Environment:

  • Kubernetes version (use kubectl version): Client Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.2", GitCommit:"5fa2db2bd46ac79e5e00a4e6ed24191080aa463b", GitTreeState:"clean", BuildDate:"2018-01-18T10:09:24Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.2", GitCommit:"5fa2db2bd46ac79e5e00a4e6ed24191080aa463b", GitTreeState:"clean", BuildDate:"2018-01-18T09:42:01Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"linux/amd64"}

Test Resources:

apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: volumes.sandwichcloud.com
spec:
  group: sandwichcloud.com
  names:
    kind: Volume
    listKind: VolumeList
    plural: volumes
    singular: volume
  scope: Namespaced
  version: v1alpha1
---
apiVersion: sandwichcloud.com/v1alpha1
kind: Volume
metadata:
  finalizers:
  - delete.sandwichcloud.com
  labels:
    sandwichcloud.com/attached_to: null
    sandwichcloud.com/id: 9f52f5b2-559a-475e-95f1-c7b8f0067116
    sandwichcloud.com/name: vol1
    sandwichcloud.com/region: e7444046-fc8b-4c40-81e2-357a5c80168a
    sandwichcloud.com/zone: 88f97cb1-6375-4a13-b9ea-bfd013a33bbd
  name: 9f52f5b2-559a-475e-95f1-c7b8f0067116
spec:
  backingId: 892a404d-60f8-4263-9c5a-5eb45906eb06
  clonedFrom: null
  size: 10
status:
  errorMessage: ""
  state: Created
  task:
    kwargs: {}
    name: null

Run kubectl get volumes -l sandwichcloud.com/name=vol1 and it will return no results.

I0206 19:26:04.343321   11513 loader.go:357] Config loaded from file kubeconfig.yml
I0206 19:26:04.365620   11513 round_trippers.go:417] curl -k -v -XGET  -H "Accept: application/json" -H "User-Agent: kubectl/v1.9.2 (linux/amd64) kubernetes/5fa2db2" http://localhost:8081/apis/sandwichcloud.com/v1alpha1/namespaces/e7a3017c-36fb-466f-97f6-d7079b31e5aa/volumes?labelSelector=sandwichcloud.com%2Fname%3Dvol1&limit=500
I0206 19:26:04.375805   11513 round_trippers.go:436] GET http://localhost:8081/apis/sandwichcloud.com/v1alpha1/namespaces/e7a3017c-36fb-466f-97f6-d7079b31e5aa/volumes?labelSelector=sandwichcloud.com%2Fname%3Dvol1&limit=500 200 OK in 7 milliseconds
I0206 19:26:04.377152   11513 round_trippers.go:442] Response Headers:
I0206 19:26:04.377662   11513 round_trippers.go:445]     Content-Type: application/json
I0206 19:26:04.378014   11513 round_trippers.go:445]     Date: Wed, 07 Feb 2018 01:26:04 GMT
I0206 19:26:04.378400   11513 round_trippers.go:445]     Content-Length: 229
I0206 19:26:04.379130   11513 request.go:873] Response Body: {"apiVersion":"sandwichcloud.com/v1alpha1","items":[],"kind":"VolumeList","metadata":{"continue":"","resourceVersion":"2574","selfLink":"/apis/sandwichcloud.com/v1alpha1/namespaces/e7a3017c-36fb-466f-97f6-d7079b31e5aa/volumes"}}
No resources found.

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Comments: 30 (19 by maintainers)

Commits related to this issue

Most upvoted comments

I’d expect CRD’s to match native resources, as weird as the behavior is:

  • null label/annotation values would get coerced to “” and would actually persist “” to etcd
  • null label/annotation values previously persisted to etcd would return “” from the API and work correctly with label selection
  • other invalid values (numbers, booleans, structured values, etc) would fail validation and prevent persistence

unfortunately, it looks like the way metadata is validated for CRD’s allows quite a lot of invalid data to be persisted:

  • it only validates values extracted via the accessor, and persists any other key/values as-is, like this:

    "metadata": {
                "foo": "bar",
                "name": "myobj",
                "namespace": "default"
    }
    
  • the values it extracts sometimes swallow errors (as we saw for the labels), and persists the bad data anyway, like this:

    "metadata": {
                "name": "myobj",
                "namespace": "default",
                "labels": {
                    "bar": "baz",
                    "foo": null,
                    "quux": [
                        1,
                        2,
                        3
                    ],
                    "qux": true
                }
    }
    

a good first step would be to tighten validation on create to stop allowing bad data and unknown fields in metadata in, then figure out what to do to resolve existing bad data