Unnecessary redundancy in generic resource api?

[Andrew Scribner]

I wonder if I'm misunderstanding something in the below example

The following creates a generic resource using a CRD that has been deployed in k8s:

client = lightkube.Client()
Profile = create_global_resource(group="kubeflow.org", version="v1", kind="Profile", plural="profiles")

profile_name = "newuser"
user_name = "[e-mail]"
profile_metadata = ObjectMeta(name=profile_name)
profile_spec = {
    "owner": {
        "kind": "User",
        "name": user_name,
    }
}
profile = Profile(apiVersion="kubeflow.org/v1", metadata=profile_metadata, spec=profile_spec, kind="Profile")
print(profile)
client.create(profile, profile_name)

It seemed odd that profile = Profile(...) needs apiVersion and kind specified - shouldn't these me apparent from the definition of Profile?

[Brad Fair]

I've just found this project, and am running into the same question. Intuitively, I'd think apiVersion and kind should already be part of the object, but they don't appear to be. I'm going to dig in further.

[Giuseppe Tribulato]

This looks like another inconsistency of Kubernetes, I can create a standard resource without the need to provide apiVersion and kind, but it seems that for custom resources these attributes are required..
I guess this is something lightkube could set explicitly before serializing if they are not provided.