improve: remove seamless type change #2726
Conversation
The curret implementation changed the underlying type, what is not we expect when passing an instance will create issues when some compares GVKs that are first passed then read. On the other hand if the user passes an instance of GVKP just can casr back. Signed-off-by: Attila Mészáros <[email protected]>
Signed-off-by: Attila Mészáros <[email protected]>
csviri
changed the title
Usually we discuss such breaking changes based on some possible impact, the Generic Kubernetes Resource APIs is already something quite limited, usually used to just cover resources for which there is no generated Java classes - what is rare - since there is a generator, or you doing some dynamic resource handling. This was asked also from some users, but probably the major use case is the Glue operator, where this is causing problem during the update. (Also I see usage some places in QOSDK - but not for this API). Is this used in QOSDK or planned, @metacosm @xstefank ? |
|
@csviri not to my knowledge. My question was purely based on semantic versionsing. |
|
I don't understand why this change is needed. As you can pass a GVKP to create a |
I literally was debugging 3 hours because of this, since you pass GVK and it under the hood changes it to GVKP, where the equal fails from that point. So we either do this this way or override GVK / GVKP equals method so they are aware of each other: But I prefer this since it can be very confusing for other users also. |
|
@metacosm where is this used now at all? I mean GVKP. |
|
Hmm, so the problem is that if I pass GVK it transforms it seamlessly to GVKP, so when I get it back that is not comparable to the input. So we have a history with this also that GVKP is not used in JOSDK at all, we added this because of RBAC feature of in QOSDK, but it is not used atm neither in QOSDK. Is there still the intention to use it? Shouldn't we just move GVKP to QOSDK in that case? Or remove it in general, at least in scope of JOSDK this does not make sense to keep. |
|
I think the appropriate fix should be #2731. It needs to stay in JOSDK because downstream projects do not control how these objects are created. Generally speaking, plurals are pretty badly handled in Kubernetes despite the fact that they are quite central… |
|
replaced by: #2731 |
The curret implementation changed the underlying type, what is not we expect when passing an instance
will create issues when some compares GVKs that are first passed then read.
On the other hand if the user passes an instance of GVKP just can cast back.
Signed-off-by: Attila Mészáros [email protected]