-
Notifications
You must be signed in to change notification settings - Fork 3k
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.
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
Using for ThirdPartyResource's #8
Comments
@smarterclayton @krousey Do we have a convenient go struct <-> TPR codec laying around somewhere? |
/cc @fabxc |
Okay, so I've made progress on my side. Using the Doing a type ProjectList struct {
unversioned.TypeMeta `json:",inline"`
unversioned.ListMeta `json:"metadata,omitempty"`
Items []Project `json:"items"`
} Notice the The final issue I have here still is that when I try to pull that same list with this call: type ProjectSpec struct {
Description string `json:"description"`
}
type Project struct {
unversioned.TypeMeta `json:",inline"`
api.ObjectMeta `json:"metadata,omitempty"`
Spec ProjectSpec `json:"spec"`
}
projectList := ProjectList{}
err := ah.Client.Rest.Get().
Namespace("default").
Resource("projects").
Do().
Into(&projectList) The list object gets the right details, but the actual items do not. They are just blank with no data. I've figured out that it is the ObjectMeta type that is causing this error. If I recreate my own ObjectMeta struct, then it works perfectly. So I think there is another interface-detecting mechanism somewhere in the decoding that doesn't like the ObjectMeta type. If I get all of this to work, I would definitely like to write a doc for how to use all this. |
You might be getting bit by ugorji codec generation. We had a problem with it downstream that we resolved by carrying a patch that deleted the generated codecs until we generated them for our types. Also, if you're using third party resources, make sure you're aware of the known issues/missing features: kubernetes/enhancements#95 |
I think it's because there's an interface check that passes because the object is anonymously included, but I haven't dug into this case to make sure. I don't know of an issue. We discovered it in OpenShift and didn't think it was reasonable to try to force reversion or object shape change to accommodate it. I think we fixed the correctness problems in the codec generator, so it ought to be safe to use for generating a codec now. |
It's ugorji--either run ugorji to generate en/decoders for your types, or On Mon, Oct 10, 2016 at 4:37 AM, David Eads notifications@github.com
|
I'm encountering similar issues to others in this issue. Please excuse my ignorance here. I'm playing catch-up on the internals of this repository still. Would you be able to point me towards what the I can also publish some of the code that I've been working on for our use case publicly to demonstrate what I'm doing (or more likely doing wrong 😉 ) if context is lacking (that said, my work is modeled pretty closely after what I've read from others here in this issue). |
Yes. Or you can take a look at this file, which is the generated ugorji code in the k8s repository, you can generate similar code for your types. The code is generated using this script. (I think write your own Decode() is easier, k8s uses ugorji because it's more efficient than the default json package). |
Paste the slack discussion here since it might be useful for other people. As ugorji doc says: So you need to implement the UnmarshalText() method for your type, you can use json.Unmarshal to implement it. For example: type YourType struct {
}
func (yourType *YourType) UnmarshalText(data []byte) error {
return json.Unmarshal(data, yourType)
} |
I created a repo to test just accessing the third party resources. https://github.com/tiaanl/kube-tpr-demo It has a few simple comands to interact with k8s. The first issue with using the dynamic package is solved by registering my types with The only last issue is still the decoding of the json into the correct types. Ive tried all the recommendations in this thread, except for generating that huge file for my type, which tbh is entirely overkill for trying to create something this simple. Being able to store your meta data inside k8s, using the api versioning and all the other benefits you get for free would be fantastic. No more separate etcd with boilerplate code you have to write yourself. Any help on this issue would be greatly appreciated. |
@tiaanl I heard the |
Thanks so much! I know the indirection and back-and-forth can be really
|
Finally got it work. See "Problem 1" and "Problem 2" in the code: See wfarr/k8s-tpr-playground#1. |
Reported issue ugorji/go#178 |
I can definitely confirm these work-arounds are functional. 👍 The serialization mostly seems to work with The current reflector errors with
Of note, the contained |
Good news! I was able to get Namely:
wfarr/k8s-tpr-playground@3b0d143#diff-7ddfb3e035b42cd70649cc33393fe32c demonstrates a working example |
That's very cool! |
We are going to nuke ugorji in 1.6 (now that we have protobuf support) and On Thu, Nov 3, 2016 at 4:18 PM, Chao Xu notifications@github.com wrote:
|
@caesarxuchao @wfarr thx for your examples. Can also confirm that #29 works. |
Thanks @rmohr for the confirmation. The example got merged. |
This will work around some apimachinery bugs (kubernetes/client-go#8)
This will work around some apimachinery bugs (kubernetes/client-go#8)
This will work around some apimachinery bugs (kubernetes/client-go#8)
This will work around some apimachinery bugs (kubernetes/client-go#8)
This will work around some apimachinery bugs (kubernetes/client-go#8)
This will work around some apimachinery bugs (kubernetes/client-go#8)
This will work around some apimachinery bugs (kubernetes/client-go#8)
This will work around some apimachinery bugs (kubernetes/client-go#8)
This will work around some apimachinery bugs (kubernetes/client-go#8)
There is known issue with TPR in client-go: kubernetes/client-go#8 Workarounds: - We include `Metadata` field in object explicitly. - Copy the solutions from client-go TPR examples to work around a known problem with third-party resources and ugorji. ```go type ClusterListCopy ClusterList type ClusterCopy Cluster func (c *Cluster) UnmarshalJSON(data []byte) error { tmp := ClusterCopy{} err := json.Unmarshal(data, &tmp) if err != nil { return err } tmp2 := Cluster(tmp) *c = tmp2 return nil } func (cl *ClusterList) UnmarshalJSON(data []byte) error { tmp := ClusterListCopy{} err := json.Unmarshal(data, &tmp) if err != nil { return err } tmp2 := ClusterList(tmp) *cl = tmp2 return nil } ```
There is known issue with TPR in client-go: kubernetes/client-go#8 Workarounds: - We include `Metadata` field in object explicitly. - Copy the solutions from client-go TPR examples to work around a known problem with third-party resources and ugorji. ```go type ClusterListCopy ClusterList type ClusterCopy Cluster func (c *Cluster) UnmarshalJSON(data []byte) error { tmp := ClusterCopy{} err := json.Unmarshal(data, &tmp) if err != nil { return err } tmp2 := Cluster(tmp) *c = tmp2 return nil } func (cl *ClusterList) UnmarshalJSON(data []byte) error { tmp := ClusterListCopy{} err := json.Unmarshal(data, &tmp) if err != nil { return err } tmp2 := ClusterList(tmp) *cl = tmp2 return nil } ```
I don't think this is fixed. Users of TPR client still have the problem. When defining types, they need to understand the workarounds and put them in their code. But there isn't any docs for it. There isn't any easy way for user to write a TPR client either. Before we have a complete fix for it, can we keep this open? Or shall we open another to track the issue? |
Just had the same problem both with
Indeed, some implicit interface seems to be the root cause of the issue. So the workarounds are:
So you will have to manually create a copy of this object to satisfy the interface.
Great news! Debugging problems like this is not fun. |
@nilebox thanks for sharing the workarounds. Did you see the tpr example in this repo? Is it not working? I'm trying to determine if we should update the example, or if we should move it to a more obvious place. |
@caesarxuchao Yes, I saw this example, and it should work (since you explicitly called a field Metadata). But since there are no comments around it, I didn't expect the naming is important here. I created my type based on the Kubernetes Deployment type which has an ObjectMeta field. So I ran into problem tracked in this issue, and renaming the field solved it. I would suggest to add some comment or link to this issue to your example so newcomers would pay attention to it. |
workaround for a ugoji bug, see kubernetes/client-go#8 (comment)
Use types from openshift/api
…-and-docs Restore README and docs
I've started using this library and it works very well.
When extending the API with ThirdPartyResource resources, things become a major issue. Using the dynamic part doesn't work well because I don't want to convert all my objects into map[string]interface{} objects. The rest part alone also doesn't work well, because there are no Encoders/Decoders.
I'm sure all the tools required to start working with my own resources is available, but get them all up and running is just a major pain point currently.
Right now I don't know enough of the internals to be productive towards a solution, but any solution would be MUCH appreciated.
The text was updated successfully, but these errors were encountered: