codegen for openshift/origin APIs?

[rudoi]

From the Makefile, I see that code generation is based on the openapi spec for the specified KUBE_VERSION.

There are a few custom objects in Origin that aren't part of the Kubernetes api spec (Route, BuildConfig, etc).

Would support for Origin be achieved by simply pointing the codegen at the Origin openapi spec? I understand that would need to be a completely separate release/build/etc, but I'm curious if it would be that simple. :pizza:

[hausdorff]

In principle we should be able to share much or the codegen routines, but i'm not sure how time-intensive they would be to adapt. I'm guessing we'll either want to fork this codegen or adapt it to handle both cases, though I'm not sure when we'd get to that (significant customer interest makes it much more likely).

The reason why involves a bit of history: the unfortunate truth is that the Kubernetes OpenAPI spec is quirky and capricious enough that our codegen routines don't always work even between Kubernetes versions. We would use the official OpenAPI codegen routines, but they generate monstrous code, and because Kubernetes changes the way the types are addressed in the spec fairly frequently, tracking that would cause us to make breaking changes every minor Kubernetes release.

[lukehoban]

I think (correct me if I'm wrong!) that @rudeland's original question here was just whether it would be possible for the @pulumi/kubernetes code generator to be pointed at the Origin API spec to create the wrappers for the additional resources defined there.

I believe the answer is yes. These may need additional logic in awaiters and elsewhere to customize the behaviour.

The question though would be how to distribute these additional APIs. It's not clear they should be part of @pulumi/kubernetes - but is is possible to deliver them separately?

Note also that I believe that technically - you could use these Origin APIs without needing the strongly-typed code-generation. @hausdorff Is that possible and if so do you have an example? This may be part of how to answer the question in the previous paragraph.

[rudoi]

Understood. Thanks for that clarification!

[rudoi]

Re-opening as @lukehoban commented exactly when I did. 😎

That was my original question, yes. I was curious if those APIs would just work wholesale. I was able to get route.openshift.io/v1/route to work, for example, with only a few slight modifications, but was wondering how quickly that would become unmaintainable.

[hausdorff]

To clarify, I do think you can adapt the codegen routines to generate a library for OpenShift, but it's not clear to me how hard it is to do.

Remember: it is difficult to use these codegen routines even between minor versions of Kubernetes, because the OpenAPI spec is so volatile. This is to say nothing of the transition to OpenShift, which is a different project.

One example: from Kubernetes 1.8 -> 1.9, the types names changed from the form V1beta2Deployment -> IoK8sKubernetesPkgApisAppsV1beta2Deployment, which forced all downstream clients to break and rev major versions. In order to provide a stable experience for our users, we needed to map both of these type names to a stable class name (in this case k8s.apps.v1beta2.Deployment).

This sort of work is very nitty, detail-intensive work, and it can't be automated. We would need to undertake a similar process to get OpenShift support, too. I think we should not underestimate the time that will take.

Also, FWIW, I very seriously doubt that generating the types will be an impediment to the time to deliver a solution. Historically, just parsing the OpenAPI spec has been the serious time suck, probably by a factor of 10.

[hausdorff]

@rudeland I think we can keep this open, it's something I expect we'll get asked about more, and we'll probably want to decide what we want to do. :)

[hausdorff]

I'm tentatively moving this to M19 since I don't think I have enough time to address it in M18. @rudeland if you happen to want to do this work for M18, I'm happy to facilitate/get on calls/review code. :)

[rudoi]

@hausdorff that sounds like a plan. I'll do some homework and see how much API-breaking Origin does, too. :)

I imagine other people will ask about this, but to be honest I don't actually view it as that critical. OpenShift/Origin don't have THAT many unique objects, and it took me only a few minutes to amend the already-generated code for the 2 unique objects I actually use.

[albestia]

I'm really interested on Pulumi OpenShift support. For me, sounds good to have a new pulumi resource provider called pulumi-openshift that depends on the specific version of pulumi-kubernetes compatible with that OpenShift implementation. I'm not sure I have enough knowledge about pulumi to assert my proposal, but sounds nice in my mind :P. If I can help in any way, just guide me please.

[AvlWx2014]

Just catching up on this. Started learning about Pulumi recently and wanted to see if support for Routes is possible before I venture too far since the project I'm targeting to use Pulumi is Openshift based.

Sounds like there's no Pulumi Openshift API, but it's probably enough if we can extend the existing Pulumi Kubernetes API to add custom resource definitions like Route. Sadly if even that's not possible I'll have to abandon ship and hope first-class support for e.g. openshift-* type Pulumi projects is added in the future.

[blampe]

@rquitales is currently working on something to this effect -- https://github.com/pulumi/pulumi-kubernetes/issues/3121 might be the best public-facing issue. Stay tuned!