VolumeSnapshot missing

[aantn]

I think VolumeSnapshot is missing from the Hikaru API.

I'm running an older version of Hikaru and it doesn't appear there. I also searched the Hikaru docs for newer releases and couldn't find it.

Is it possible this is missing?

https://kubernetes.io/docs/concepts/storage/volume-snapshots/ https://kubernetes.io/blog/2020/12/10/kubernetes-1.20-volume-snapshot-moves-to-ga/

[aantn]

Looks like these are CRDs which explains why they're missing: https://github.com/kubernetes-client/python/issues/1195#issuecomment-699510580

[haxsaw]

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?

[aantn]

As always, thanks for the detailed write up.

I'm a little skeptical about the registry of community contributed classes because of my experience with other Python libraries that used handwritten classes for k8s. In practice coverage was bad and even existing classes were incomplete.

I'm ok registering my own class though. I would even be ok using some generic CustomResource class. That's basically what I'm doing anyway with the official kubernetes library as a workaround. It would be a minor improvement to just use hikaru and not drop down into the official library.

Would things be simpler if you queried an actual running APIServer for type definitions or is that the same as the swagger? The ability to autogenerate a custom class that way would be useful. (Autogenerate at development type using a utility not at runtime inside my app.)

All this said, I think I have a working workaround with the kubernetes client so please don't prioritize any of this on my account.

Best regards.

On Wed, 16 Feb 2022, 22:54 Tom Carroll, @.***> wrote:

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?

— Reply to this email directly, view it on GitHub https://github.com/haxsaw/hikaru/issues/27#issuecomment-1042301684, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADYUBZU73T7E6BRB644TRLU3QFJLANCNFSM5ORD5ESA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you authored the thread.Message ID: @.***>

[haxsaw]

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 :-).

[aantn]

Interesting, someone just requested CRD support for Robusta, so there could be a real use case for this on our end: https://github.com/robusta-dev/robusta/issues/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.)

[haxsaw]

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.

[aantn]

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.

[flare-ws]

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

[aantn]

@flare-ws not yet. Can you ellaborate on your use case at https://github.com/robusta-dev/robusta/issues/213

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

[haxsaw]

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.

[haxsaw]

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