Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Only the first ThirdPartyResource created in a groupVersion actually installed #25570

Closed
sjenning opened this issue May 13, 2016 · 4 comments · Fixed by #29724
Closed

Only the first ThirdPartyResource created in a groupVersion actually installed #25570

sjenning opened this issue May 13, 2016 · 4 comments · Fixed by #29724
Labels
sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery.

Comments

@sjenning
Copy link
Contributor

sjenning commented May 13, 2016 •
edited
Loading 

# kubectl version
Client Version: version.Info{Major:"1", Minor:"3+", GitVersion:"v1.3.0-alpha.3.756+64c5809bd57784", GitCommit:"64c5809bd577848ba0fb271e1cbe6b372256fe15", GitTreeState:"clean", BuildDate:"2016-05-12T21:33:55Z", GoVersion:"go1.6.2", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"3+", GitVersion:"v1.3.0-alpha.3.756+64c5809bd57784", GitCommit:"64c5809bd577848ba0fb271e1cbe6b372256fe15", GitTreeState:"clean", BuildDate:"2016-05-12T21:33:55Z", GoVersion:"go1.6.2", Compiler:"gc", Platform:"linux/amd64"}

I create two TPRs:

# cat catalog.yaml 
kind: ThirdPartyResource
apiVersion: extensions/v1beta1
metadata:
  name: catalog.alpha.redhat.com
description: "A specification of a catalog of resources"
versions:
- name: v1alpha1
# cat catalog-entry.yaml 
kind: ThirdPartyResource
apiVersion: extensions/v1beta1
metadata:
  name: catalog-entry.alpha.redhat.com
description: "A specification of a resource in a catalog"
versions:
- name: v1alpha1

Both show up in the ThirdPartyResourceList...

curl http://127.0.0.1:8080/apis/extensions/v1beta1/thirdpartyresources
{
  "kind": "ThirdPartyResourceList",
  "apiVersion": "extensions/v1beta1",
  "metadata": {
    "selfLink": "/apis/extensions/v1beta1/thirdpartyresources",
    "resourceVersion": "75"
  },
  "items": [
    {
      "metadata": {
        "name": "catalog-entry.alpha.redhat.com",
        "selfLink": "/apis/extensions/v1beta1/thirdpartyresources/catalog-entry.alpha.redhat.com",
        "uid": "8c4a60e0-1889-11e6-bfe6-bc5ff47352bf",
        "resourceVersion": "25",
        "creationTimestamp": "2016-05-12T21:36:12Z"
      },
      "description": "A specification of a resource in a catalog",
      "versions": [
        {
          "name": "v1alpha1"
        }
      ]
    },
    {
      "metadata": {
        "name": "catalog.alpha.redhat.com",
        "selfLink": "/apis/extensions/v1beta1/thirdpartyresources/catalog.alpha.redhat.com",
        "uid": "89a0a0c8-1889-11e6-bfe6-bc5ff47352bf",
        "resourceVersion": "23",
        "creationTimestamp": "2016-05-12T21:36:07Z"
      },
      "description": "A specification of a catalog of resources",
      "versions": [
        {
          "name": "v1alpha1"
        }
      ]
    }
  ]
}

but only the first is actually installed.

curl http://127.0.0.1:8080/apis/alpha.redhat.com/v1alpha1/
{
  "kind": "APIResourceList",
  "apiVersion": "v1",
  "groupVersion": "alpha.redhat.com/v1alpha1",
  "resources": [
    {
      "name": "catalogs",
      "namespaced": true,
      "kind": "Catalog"
    }
  ]
}

If I reverse the order in which they are created, the first one is always the one that gets installed.
@sjenning sjenning changed the title Only the first ThirdPartyResource created in a groupVersion actually usable Only the first ThirdPartyResource created in a groupVersion actually installed May 13, 2016
@j3ffml j3ffml added the sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. label May 14, 2016
@j3ffml
Copy link
Contributor

j3ffml commented May 14, 2016

cc @brendandburns

@ericchiang
Copy link
Contributor

Does #28414 address this issue?

@sjenning
Copy link
Contributor Author

@ericchiang unfortunately no. Just pulled master and rebuilt and the same situation exists.

@sjenning sjenning mentioned this issue Aug 10, 2016
Merged
@brendandburns
Copy link
Contributor

For anyone else who hits this:

This is fixed in #29724

k8s-github-robot pushed a commit that referenced this issue Aug 14, 2016
Merge pull request #29724 from brendandburns/thirdparty3
3a8b21b 
Automatic merge from submit-queue

Fix third party APIResource reporting

@polvi @caesarxuchao @deads2k 

This "fixes" some additional bugs in third party `APIResourceList` reporting.

This code needs a bunch of cleanup, and more tests, but sending it out for a quick smell check review in case I'm doing something stupid.

Fixes the bug referenced here:  #28414 (comment) and in #23831

Fixes #25570
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Fix third party APIResource reporting brendandburns/kubernetes
4 participants
@sjenning @j3ffml @ericchiang @brendandburns