VolumeSnapshot missing about hikaru HOT 11 CLOSED

Looks like these are CRDs which explains why they're missing: kubernetes-client/python#1195 (comment)

from hikaru.

Yep, that would explain it; I don't see VolumeSnapshot in the source swagger, so of course we don't have a definition for it.

CRDs are something that I'm starting to turn my attention to. Someone previously asked if I'd open up the build system in order to support CRDs, but from what my research is showing that won't work as the JSON schema in the CRD probably doesn't have enough info to use the build system as it stands (worse, there's all kinds of odd problems in the swagger that make the build more fragile than I'd like, though that's been improved due to the recent re-implementation). So it looks like I'll need something new to handle the JSON schema info.

Given what I'm seeing from the spec and the kind of experience I want to provide it will take a bit of work to give what I'd call a 'nice' experience to a user of CRDs in Hikaru. It looks like the only short-term workaround will be to create your own class and register it like you would with a derived class. Maybe we need a registry of community-contributed classes to cover CRD objects until we get fuller support?

from hikaru.

from hikaru.

Querying a CRD and generating a class from it is what I have in mind. There are specific issues with this though that one doesn't face with the swagger. From my read of JSON schema, you could get a description of a simple flat object, a hierarchy of objects with no type names in the embedded objects, or a reference to an existing K8s object. It's these latter two cases that are posing the challenges: in the former case, what I've been trying to avoid in Hikaru is for users to have to know the structure and types of fields, but if I don't have a type name for a contained object all I can do is offer some some kind of dict-like thing. In the latter case, this may or may not be a problem: I have some lookup in in the runtime system, but other info is tossed out when the build system exits, and I may have to bring along more data from that process. None of this is insurmountable, and a few ideas are starting to form that I kind of like, but it will take some research and then a solid chunk of dev effort. But we haven't had any really new functionality in some time, and I'm kind of itching for some new features :-).

from hikaru.

Interesting, someone just requested CRD support for Robusta, so there could be a real use case for this on our end: robusta-dev/robusta#213

We're still a few Hikaru versions behind, so it'll be a good excuse for us to finally do the work on updating. (We haven't done it yet because we want to do thorough testing given the API changes and haven't found the time yet.)

from hikaru.

Yeah, sorry about the disruption; perils of early adoption I guess, but I do try to keep your pain to a minimum. Things have settled down quite a bit over the last few releases so I would expect it to be more stable going forward. CRD support is probably only going to go into the newer stuff, so you may want to consider taking on the upgrading burden.

from hikaru.

Oh no worries. I want to update to get various fixes including ones we requested and currently are working around!

We're going to upgrade and of course no need to add CRD support to older versions.

from hikaru.

@aantn hi, thanks for your work, this tool has a great potential.
Any news on CRDs so far?

from hikaru.

@flare-ws not yet. Can you ellaborate on your use case at robusta-dev/robusta#213

It will help us prioritize vs other stuff we're working on

from hikaru.

Hi there--

I presume you mean CRD support in Hikaru and not Robusta, so I'll answer wrt that.

While Hikaru has some of what's needed for CRD support (registering custom classes is a key one), automatic generation is bigger project. The issue is around the flexibility of JSON Schema which is used in the CRD message to describe the CRD. JSON Schema allows a lot of different mechanisms for specifying definitions for objects, and I really need to narrow the scope down since the full set of features is a material piece of work. Hikaru currently has a JSON Schema parser that is used to process the Kubernetes swagger, but that stuff has 1) a fixed set of uses that I can generally count on when coding the processor, and 2) a number of idiosyncratic uses that require special coding, making it less generalizable. I've already re-written the builder once to handle some of the things that cropped up in this code.

Having said that, some preliminary work has begun, but is behind my efforts at adding support for v23 of the K8s Python Client. I would love to find some existing tooling that I could add to Hikaru that does some of the lifting for processing the message for me, so if you're aware of any good Python JSON Schema parsers that ideally present a constructed object model of the objects in the schema, that would be a big leg up.

from hikaru.

I'm going to leave direct issues regarding CRDs to another ticket and close this one.

from hikaru.