implemented registration of CRDs

[dmitsh]

In the existing setup, each job submission requires us to define the resource's GVR (Group, Version, Resource), template, name format, and the format for pod names. These parameters remain constant.

Currently, if we have multiple "SubmitObj" tasks, we must repeat these parameters for each task.

I suggest we introduce a new task type called "RegisterObj." This task would store all the necessary parameters for a specific CRD in memory. When a job involving that CRD is submitted, the stored parameters would automatically be applied.

[lalitadithya]

@dmitsh , please correct me if I'm wrong, based on my understand and our older discussion, the reason why we need this change is because we cannot infer the schema.GroupVersionResource from the group, version, kind from the YAML. The reason being that the resource does not necessarily match the kind, i.e., the kind can be "Job", but the resource will be "jobs". Is this understanding correct?

I recently leant about kubectl's api-resources, and I think this might be helpful here. If we run kubectl api-resources --api-group=batch.volcano.sh -o wide, we get the following output from which we can get the resource (jobs) from the kind (Job).

NAME   SHORTNAMES   APIVERSION                  NAMESPACED   KIND   VERBS
                     CATEGORIES
jobs   vcjob,vj     batch.volcano.sh/v1alpha1   true         Job    delete,deletecollection,get,list,patch,create,update,watch

We can parse the YAML to fetch the group and version (split the api version by / to get the group and version) and then we can subsequently use this information along with the discovery package to fetch the required mapping. This would mean that the user will no longer have to specify the group version resource in the job submission schema.

What do you think?

[dmitsh]

@dmitsh , please correct me if I'm wrong, based on my understand and our older discussion, the reason why we need this change is because we cannot infer the schema.GroupVersionResource from the group, version, kind from the YAML. The reason being that the resource does not necessarily match the kind, i.e., the kind can be "Job", but the resource will be "jobs". Is this understanding correct?

I recently leant about kubectl's api-resources, and I think this might be helpful here. If we run kubectl api-resources --api-group=batch.volcano.sh -o wide, we get the following output from which we can get the resource (jobs) from the kind (Job).

NAME   SHORTNAMES   APIVERSION                  NAMESPACED   KIND   VERBS
                     CATEGORIES
jobs   vcjob,vj     batch.volcano.sh/v1alpha1   true         Job    delete,deletecollection,get,list,patch,create,update,watch

We can parse the YAML to fetch the group and version (split the api version by / to get the group and version) and then we can subsequently use this information along with the discovery package to fetch the required mapping. This would mean that the user will no longer have to specify the group version resource in the job submission schema.

What do you think?

Great suggestion, thanks! Let me give it a try.
Implemented as suggested.