Network attachment using removed type from k8s api
Mmduh-483 opened this issue · comments
Network attachment is using type apimachinery.pkg.runtime.serializer.DirectCodecFactory, which is replace with WithoutConversionCodecFactory starting from release 1.16.
When use the Network attachment keep getting the error serializer.DirectCodecFactory not found.
The Kubernetes dependencies we have in the projects are quite dated already. Would you mind opening a PR bumping the Kubernetes version and adjusting the code if needed?
Any chance for this issue to get more attention from maintainers? Thanks :).
It got attention. Once somebody from the users community opens a PR bumping the dependency version, I will be glad to review and merge it. I think that somebody who faces this issue is in a good position to prepare a patch and test that the issue was indeed resolved.
"Fix your own bug" is not an acceptable answer, especially coming from a maintainer. Also, this is making the assumption that everyone is a developer...
I assume that somebody facing this issue during compilation after bumping version of Kubernetes is a developer. My question in #20 (comment) was not answered, not with "I don't know how" nor with "I will need guidance". So again, it has got attention, it just won't move anywhere without conversation.
I'm sorry if my answer came out harsh, but assuming that maintainers are the people responsible for swarming around issues and fixing them is harmful to open source projects. Any sign of this way of thinking is making me a little upset, and sorry if I got a wrong impression. I will be of course happy to assist resolving this issue :)
I assume that somebody facing this issue during compilation after bumping version of Kubernetes is a developer. My question in #20 (comment) was not answered, not with "I don't know how" nor with "I will need guidance". So again, it has got attention, it just won't move anywhere without conversation.
I'm sorry if my answer came out harsh, but assuming that maintainers are the people responsible for swarming around issues and fixing them is harmful to open source projects. Any sign of this way of thinking is making me a little upset, and sorry if I got a wrong impression. I will be of course happy to assist resolving this issue :)
I don't want to keep arguing for too long nor derail the thread but it is part of the maintainer role to look at issues and fix them, at least from my perspective. But anyway no hard feelings here :-).
For me "more attention" meant, is there a maintainer willing to fix this? This will benefit the project overall and also broaden the adoption of that go-client.
I'm trying to use it in Rook and our k8s go-client is more recent, hence the failure. Even though I'm a developer, I don't know this project well enough nor have time to attempt a fix. Someone with a better experience on that project will definitely fix this more rapidly than me. Hence, my call for assistance.
However, I could certainly understand this issue might not be the maintainer's highest priority and I'll live with that.
I prefer when open-source projects are driven by their users who use them for their advantage while maintainers make sure that the quality of the project is not damaged and contributors get enough guidance to deliver their enhancements and fixes. So we all can benefit from our shared project. More users this project gets, more collaborators should participate. Projects grow stronger from engaged contributor-community, especially when it comes to a library (compared to user-facing apps).
Despite that, since you dedicated me time to discuss this and I won't have easy sleep with this opened now, here is the PR: #22
I prefer when open-source projects are driven by their users who use them for their advantage while maintainers make sure that the quality of the project is not damaged and contributors get enough guidance to deliver their enhancements and fixes. So we all can benefit from our shared project. More users this project gets, more collaborators should participate. Projects grow stronger from engaged contributor-community, especially when it comes to a library (compared to user-facing apps).
Despite that, since you dedicated me time to discuss this and I won't have easy sleep with this opened now, here is the PR: #22
Happy to discuss maintainer stuff anytime!
Thanks for the quick PR :-D