Wrong object type created despite calling hikaru.register_version_kind_class
Closed this issue · 5 comments
Scenario 1: After registering a custom Pod class, API methods returning a PodList contain Pods and not the custom class
from kubernetes import config
config.load_kube_config()
import hikaru
from hikaru.model import *
class TestPod(Pod):
pass
hikaru.register_version_kind_class(TestPod, Pod.apiVersion, Pod.kind)
l: PodList = PodList.listNamespacedPod("somens").obj
for p in l.items:
print(type(p))
Scenario 2: register_version_kind_class seems to be entirely broken for Job objects (perhaps because it isn't in the regular API group?)
First run: kubectl apply -f https://kubernetes.io/examples/controllers/job.yaml
Then run the following code:
from kubernetes import config
config.load_kube_config()
import hikaru
from hikaru.model import *
class TestJob(Job):
pass
hikaru.register_version_kind_class(TestJob, Job.apiVersion, Job.kind)
j = Job.readNamespacedJob("pi", "default").obj
print(type(j))
You managed to find two bugs related to registration. tl;dr, both are fixed on the dev branch.
The first issue, where a pod list didn't have the right derived pod classes, was an oversight on consulting the registry when those kinds of embedded objects were encountered in a list. Actually, there are two places where this happens, and both are fixed.
The second, involving registering a Job subclass, is a disagreement between what the doc advises and the implementation. Internally, Hikaru has no use for groups at runtime and so all registrations are based on version and kind alone (no group value). But the doc suggests using 'apiVersion' during registration, and some of those have groups in them. I decided that I like the documentations usage a bit better, so I changed the implementation to remove the group for you (it will work with pure version strings as well). In the short term, you could have gotten around this by registering a Job without the group portion of apiVersion.
Fixed in 0.5b