"Get all classes from server" Function or "get_class(check_server=True)" Argument

[rherriott]

Which project are you requesting an enhancement for?

kr8s

What do you need?

Currently, as get_class() does not question the server, I'd be very thankful for any method that would give me all server classes, any server class, or an arguement in get_class() that allowed searching the server.

This would enable me to get a class like 'Appian' from the server, without first getting an instance of it.
After all, it is entirely possible that there are no instances.

The function new_class() is nice, but what if I do not know all the details it requires?
Best-case, I can get most of them via api_resources(), but not all (async, scalable, scalable_spec).
Current drop-in takes api_resources(), selects all not known, and calls new_class on each of them, presuming nothing.

Best

[jacobtomlinson]

@rherriott it would really help if you could share a couple of examples of what you are trying to do. What would this workflow look like?

[rherriott]

For context, I'm working with Appian, which involves a large set of CRDs. 'Appian' among them.

If I am to open python, import kr8s, and call kr8s.objects.get_class() on 'appian' it will throw a KeyError: 'no object registered for appian'.

I guess what I'm asking for is some function or argument passsable to get_class for which I can provide 'appian' an get the class from the server.

appian_class = kr8s.objects.get_class('appian', check_server=True)

currently the closest is:

appian_class_description = next(filter(lambda c: c['name'] == 'appians', kr8s.api_resources()))
appian_class = kr8s.object.new_class(kind=appian_class_description['kind'],
    version=appian_class_description['version'],
    namespaced=appian_class_description['namespaced'],
    plural=appian_class_description['name'])

Note that the above does not include anything related to scalability, as that is not mentioned in .api_resources()

OR this works currently if and only if there is an appian I can pull down:

next(kr8s.get("appian", namespace=<appian-containing namespace>))
appian_class = kr8s.objects.get_class('appian')

As now that the local server has seen an instance, it knows the class.

[jacobtomlinson]

Yeah that does make sense, it would be good for get_class to support these kind of lookups. I shouldn't be too difficult, but we should consider refactoring the currently logic around get_class and new_class and how they are used in kr8s.get(), etc.

I think the workaround I would recommend today is something like this:

import kr8s

api = kr8s.api()
appian_kind, appian_plural, appian_namespaced = api.lookup_kind("appian")
Appian = kr8s.objects.new_class(appian_kind, namespaced=appian_namespaced, plural=appian_plural)

[rherriott]

I am embarrassed to say this is the first time I've heard of `lookup_kind()` 🤦 I'll integrate this in the short term though, thanks!

…

On Fri, Jun 27, 2025, 3:08 AM Jacob Tomlinson ***@***.***> wrote: *jacobtomlinson* left a comment (kr8s-org/kr8s#598) <#598 (comment)> Yeah that does make sense, it would be good for get_class to support these kind of lookups. I shouldn't be too difficult, but we should consider refactoring the currently logic around get_class and new_class and how they are used in kr8s.get(), etc. I think the workaround I would recommend today is something like this: import kr8s api = kr8s.api()appian_kind, appian_plural, appian_namespaced = api.lookup_kind("appian")Appian = kr8s.objects.new_class(appian_kind, namespaced=appian_namespaced, plural=appian_plural) — Reply to this email directly, view it on GitHub <#598 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKRZI57IQBUPHZW7M2LDBBT3FUJZ3AVCNFSM6AAAAABZQ2AMC2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTAMJSGQ2TSMBXGM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[jacobtomlinson]

Don't be embarrassed, its sort of buried. We don't expose it via the top level kr8s helpers, it's only available as an API method. And we only use it internally.

I do think that if we are going to update kr8s.objects.get_class() in the longer term to do the lookups we should resolve #256 first to avoid caching issues when adding new CRDs. Especially if you're using kr8s to create the CRD and then you immediately want to get a class for it.