Use k8s style YAML objects for job definition

[yuvipanda]

I really like what I consider the standard definition style for YAML objects in k8s, and it goes something like this:

kind: KBatchJob
apiVersion: <lets-you-move-things-around>
metadata:
  name: my-name
  labels: {}
  annotations: {}
spec:
  ...

It's a little more verbose, but I think the familiarity + extensibility is worth it. It also means this could become a proper Kubernetes CRD?

[TomAugspurger]

It's a little more verbose, but I think the familiarity + extensibility is worth it.

I think "familiarity" depends on the target audience :) I'm hoping that many of our users won't really know what a Kubernetes Job is.

Right now we have this non-standard YAML format (not documented, but an example at https://github.com/kbatch-dev/kbatch/blob/083ebb4ca6dca1b4ce9ce0d952c77eb36774e1e1/examples/ndvi-blob-storage/job.yaml) for providing options to the CLI. It's not standard (boo) but it's also relatively simple, just providing some CLI arguments. Would you hope to replace that with this KBatchJob file?

It also means this could become a proper Kubernetes CRD?

I know that "CRD" means "Custom Resource Definition", but I don't immediately see why we would want that. If you get a chance, can you expand on that? I'd guess it would have to do with minimizing the amount of work that kbatch-proxy does? Currently it's responsible for taking this semi-valid Kubernetes Job and patching it to a state where it's valid, so that the only thing Kubernetes ever sees is a valid Job.