Question about codegen and Besom (scala impl): Is ...
# kubernetes
b
Question about codegen and Besom (scala impl): Is it possible to run a codegen for a CRD? Like Istio objects
@quaint-spring-93350 maybe you know? I'm looking to codegen against this definition https://github.com/istio/istio/blob/master/manifests/charts/base/crds/crd-all.gen.yaml
There are openapi definitions in there. I tried using https://guardrail.dev/#/ on the openapi portion, but it didn't work
q
Hi Eli, we don't have a besom-native CRD/CR parser and generator yet. The newest release (0.3.1, already on maven, to be announced this week with a new blogpost) has support for ConfigGroup in 4.10.x kubernetes provider as seen here: https://github.com/VirtusLab/besom/blob/main/examples/kubernetes-yaml-crd/Main.scala That's not much given that you need a stringified form of yaml there (at least you could safely interpolate with
p""
interpolator). We're waiting for changes in core pulumi that will merge things like crd2pulumi and tf2pulumi into a common pipeline that each language codegen would implement a backend for but as far as I know that's not done yet. Separate tool to generate CRD/CR classes probably could also be done with overlays but that would probably be a temporary solution given the aforementioned changes.
Guardrail generates client/server code for OpenAPI, it's completely unrelated to infra side of the equation. Are you trying to generate a client library for that spec?
b
Yeah I'm using Guadrail kind of creatively here =] It can generate models out of openapi. The client/server aspect is irrelevant here. The idea is that the Istio CRD definition is 90% defined in terms of openapi, so its theoretically possible to generate all the needed code to model that resource in Pulumi
q
Well, yeah and no... if it was that simple you could take yaml to json and then just generate case classes from json with something like https://transform.tools/json-to-scala-case-class, then add
derives YamlCodec
from
scala-yaml
and push that to ConfigGroup mentioned above but the pickle is that you only get plain case classes when you do this so if you want to provide some of the information for those classes not in literal form but as
Output[A]
you have to, basically, construct a for comprehension in which you extract all data from outputs and then in yield segment create instances of said case classes and convert them to yaml string yielding you an
Output[String]
that you can put into
ConfigGroupArgs
and this would still be a workaround 😄
proper solution would be to generate true pulumi resources based on CRD yamls kinda like https://github.com/pulumi/crd2pulumi does
b
for sure! Thanks for looking into it
q
it's on our radar, we'd love to have support for CRD/CR