support for auto-generation
Closed this issue · 4 comments
I just came across Hikaru and am very interested. We're currently using cdk8s and are not happy with it, so looking for an alternative.
Our gripes with cdk8s aside: one thing it does very well is supporting crds and any kubernetes version. It does this by allowing users to "import" the spec from a cluster (https://cdk8s.io/docs/latest/cli/import/#crds). As far as I can tell, Hikaru relies on auto-generated code based on inspecting Kubernetes' openapi spec. I'm wondering if maintainers have considered opening up this code generation process so that users can "compile" their own hikaru module and thereby represent their own cluster versions and/or crds?
I've been contemplating what to do about CRDs, that is, from the meta-angle, not direct representation. Currently Hikaru supports building your own 'document' classes and registering these with the system, so you can both create in-code and from the wire instances of your own resources. But I've been considering what to do to raise the bar and build out classes from a read-in CRD message. Your suggestion would be another way at getting to the same thing: using the builder to process more OpenAPI code to generate the classes. The best approach would depend where you're coming from I would imagine.
The builder isn't packaged with the wheel, but is right there in the repo, so you could give it a whirl with your own swagger file. I must warn you though that I've found the official K8s swagger to be a bit dodgy, so I can't represent that I don't have some special processing that may not fly with your swagger. I didn't write a generalized swagger processor, just one that gets through the nits and lice of the K8s swagger. It would be interesting to hear about your experience if you try it though.
A quick word on versions: I'm a bit behind in rolling out support for 1.19 and 1.20, and this is because I've found an error in my processing the swagger that involves not handling multiple classes with the same name well (there aren't many, but they are out there). I'm trying to figure out the best approach that will have minimal user impact as I hate changing things on people if I can avoid it, even if Hikaru is in beta. But I'm a bit swamped at the moment and this is a tricky piece of work. Hopefully the holidays will provide some idle cycles where I can give this decent consideration.
I wanted to circle back on this as I've been re-implementing the build system due to some changes that have arisen in the K8s 1.19 client that have broken some of the assumptions in the old builder. The long and short of this is that I currently don't plan on making a supported build tool a part of Hikaru's features for the foreseeable future. The reason is that the swagger that is processed now is full of inconsistencies and make writing the builder much harder than it really should be, and I'm not keen on adding a tool that may have to handle more weird cases than I already do. I'd be willing to discuss a work-for-hire project to create such a thing, but right now I'm not inclined to make it part of the open source project-- it just smacks of being a time sink.
However, I am still interested in solving the problem your request is trying to address, and have plans on looking into processing CRD messages into Hikaru classes. I think that should give you the same end benefit unless I'm missing something (so let me know if I've got it wrong).
I'm going to close ticket, but follow up if you want to discuss a custom solution. Otherwise, you can wait for me to add CRD support.
Hey, just to nudge this one more time: Hikaru 1.0 now provides support for CRDs. While it won't build a CRD automatically from one read from the cluster, it does allow you to create your own Hikaru class that mimics an existing CRD that will work with your cluster. In addition, you can then use the rest of Hikaru's capabilities like Watchers to build controllers for your CRDs in Python with Hikaru.