CustomResource in Python is missing

[hausdorff]

Kubernetes provides the ability to extend the core API in a way that looks native. Users do this by defining CustomResourceDefinitions.

In the nodejs API, we allow users to define instances of CRDs using the class apiextensions.CustomResource. This is currently unimplemented in Python, and there are several subtleties:

• Python uses snake_case. Most CRDs use Go, which means they expect SCREAMINGCASE. How/should we do this conversion?

• We don't know anything about the schema of these resources, other than the fact that they all contain apiVersion, kind, and metadata. Does this mean we have to have a constructor like:

  new apiextensions.CustomResource("foo", apiVersion="v1", kind="Foo", properties={"spec": ...})
  

  This seems not amazing.

cc @lblackstone

[hausdorff]

First cut is here: #327

Not entirely sure this is the right direction though.

[lblackstone]

After talking with Alex, there isn't an obvious way to implement this so that it handles the required bidirectional snake_case to SCREAMINGCASE transformation.

I'm working on adding YAML support to the Python SDK, and that can be used as a workaround for CRDs while we work on a better native solution.

[4c74356b41]

ugh, no crd sux big time

[hausdorff]

@4c74356b41 happy to hear suggestions about how to implement this. I see no way to make it work such that it's idiomatic in python.

[4c74356b41]

i've looked through cert-manager, istio, prometheus, grafana, efk, and several other charts that contain custom resources, i dont understand what you are saying. google also doesnt help me with screamingcase definition.

[hausdorff]

@4c74356b41 The problem is that you have to know how to transform fields like ClusterIP -> cluster_ip, rather than cluster_i_p, or clusterip. And, we have to do the reverse, too. In the screaming case, you have to take something like CIDRIP -> cidr_ip.

This is doable for the Kubernetes spec because we can just look and make sure the transformation is right, but it seems impossible for CRDs, since we know nothing about those fields.

[hausdorff]

So in other words, we need to generate such mappings automatically. I don't know any way to do this with any predictable fidelity.

[4c74356b41]

i dont think there is any way to convert from SOMETHINGLIKETHIS to something_like_this, but why do you need that? you dont know anything about crd, i dont think you should know (??), just convert dict passed to spec to json and thats it?

[hausdorff]

That's not the way any of the other APIs work, though, and I think it runs a very high likelihood of confusing users.

Besides, what Levi is working on is the ability to instantiate CRDs from JSON or YAML -- which is essentially what you're asking for. The specifics are TBD, but I can imagine that we have a few APIs for this, one of which takes a JSON literal or a JSON string and parses it.

[4c74356b41]

I honestly dont think your concern about the casing matters enough to push back this feature. using files is a poor replacement, tbh

[hausdorff]

I'm not sure what you mean by "push back this feature." As I said before, I think we will probably end up supporting something like CustomResource.from_dict or CustomResource.from_json. I think something like this strikes a reasonable balance between making this possible, and avoiding the obvious confusion attendant to having multiple ways to address fields in Kubernetes resources.

And yes, I do happen to think that this is going to be very confusing to users. :)

[lblackstone]

The Initial implementation in #543 accepts a dict for the spec, which avoids casing issues since the underlying fields are unchecked. We will likely want to add some more strongly-typed inputs at some point, but this unblocks users wanting to manage CRDs/CRs in Python. (Validation will still occur server-side in k8s, but the IDE won't be much help in creating these.) YAML inputs are also supported.