New CRD generation only includes resource kinds

[Geethree]

Now that #31 has landed(!!) this library just got even better.

That said.. say when it comes to things like istio there are lots of bits missing, which isn't really encapsulated in the CRD spec. In particular, let's take.. VirtualService

...virtualService.new("foo")

virtualService..withHttp( <- takes list of http or single entry
But Http has it's own spec here

With a deep list of references.. such as

  "istio.networking.v1beta1.HTTPRouteDestination": {
    "description": "Each routing rule is associated with one or more service versions (see glossary in beginning of document). Weights associated with the version determine the proportion of traffic it receives. For example, the following rule will route 25% of traffic for the \"reviews\" service to instances with the \"v2\" tag and the remaining traffic (i.e., 75%) to \"v1\".",
    "type": "object",
    "properties": {
      "destination": {
        "$ref": "#/components/schemas/istio.networking.v1beta1.Destination"
      },
      "weight": {
        "description": "The proportion of traffic to be forwarded to the service version. (0-100). Sum of weights across destinations SHOULD BE == 100. If there is only one destination in a rule, the weight value is assumed to be 100.",
        "type": "integer",
        "format": "int32"
      },
      "headers": {
        "$ref": "#/components/schemas/istio.networking.v1beta1.Headers"
      }
    }
  },

Not attempting to bike shed or nit pic here. Genuinely curious if we could extend this in the future? As from a end user perspective.. virtualService.new... without any other typings/hints is a little "meh" ?

[xvzf]

It even gets worse for some of the config connector CRDs, there not even the metadata is properly generated (ping @Duologic here, this is why I had this glue transform.jsonnet in my POC)

It seems partly related to the openapi endpoint not responding with the proper definitions. I'll investigate this in the next days

[xvzf]

I wasn't able to reproduce this with higher k8s versions; @Geethree can you try with 1.22 please?

[Duologic]

The current Istio lib is generated of the CRDs (https://github.com/jsonnet-libs/k8s/blob/master/libs/istio/config.jsonnet#L17), the reference you make comes from an OpenAPI or swagger spec, can you share a link to it? It might be useful to generate this lib from a spec instead of the CRDs, the spec might be more complete.

[ledouxpl]

Although I am not a GO developer, is there anything I could do to help address this issue? As @Geethree said, the libs would be miles better if jsonnet for nested objects could be also be generated.

[Duologic]

I just had another look at the CRDs, they do have the nested objects defined in the spec, k8s-gen just doesn't recurse that deep.

I have a POC with CRDsonnet that does recurse that deep, it would be a good idea to fix k8s-gen as it is possible.

[xvzf]

@ledouxpl @Geethree I think this is addressed now. Can you check it? :)

[ledouxpl]

@ledouxpl @Geethree I think this is addressed now. Can you check it? :)

Although #180 improves the generated lib, it still falls short of generating lib code for nested objects.

Take for exemple Contour's HttpProxySpec ...

An important part of defining the HttpProxy is specifying its VirtualHost. Sadly, this complex object's definition is still missing from the generated library. I still have no means of defining something like:

local c = import 'github.com/jsonnet-libs/contour-libsonnet/1.20/main.libsonnet';

{
  httpProxy: c.v1.httpProxy.new(.....) +
     c.v1.httpProxy.withVirtualHost(
        c.v1.httpProxy.virtualHost.new(....) +
        c.v1.httpProxy.virtualHost.withFqdn(...) +
        c.v1.httpProxy.virtualHost.withCorsPolicy(...) +
        c.v1.httpProxy.virtualHost.corsPolicy.withAllowOrigin([
           "localhost",
           "foobar.com" ])
           // etc.
  )
}

virtualHost, although not a CRD by itself, is found within Contour's CRDs, nested under the httpProxy CRD, listed in its spec as part of its properties, and defining its own properties.

For the generated lib to really be useful, I feel that all those nested objects also needs to be part of the generated libsonnet.

[xvzf]

okay, I see 👍🏻 Keeping it for the roadmap then.

[ledouxpl]

Wait @xvzf , I made a blunder testing for the new libs. I used the image I had previously built for generating the libs.

Testing by importing the latest release of contour-libsonnet, I can totally do:

contour.projectcontour.v1.httpProxy.new('foobar') + contour.projectcontour.v1.httpProxy.spec.virtualhost.corsPolicy.withAllowMethods("FOO"),

...generating:

{
   "apiVersion": "projectcontour.io/v1",
   "kind": "HTTPProxy",
   "metadata": {
      "name": "foobar"
   },
   "spec": {
      "virtualhost": {
         "corsPolicy": {
            "allowMethods": [
               "FOO"
            ]
         }
      }
   }
}

So it does fix this issue! 🎉

Thanks a lot for this.

[xvzf]

Amazing! I've been wondering where this could possibly be coming from. Closing this then and thanks for using our lib! 🎉