Allow standard CRD YAML in customResourceDefinition in pod_spec_set

[Kenneth Koski]

The current implementation of passing in `customResourceDefinition` in `pod_spec_set` is kind of tricky, as `pod_spec_set` has a different notion of how that YAML should look, and the property names don't all line up. There's also no error reporting if an invalid property is included (see https://github.com/juju-solutions/layer-caas-base/issues/17), which makes it difficult to know coming in how to use `customResourceDefinition` in `pod_spec_set`.

Would it be possible to introspect the passed-in YAML and if it looks like regular K8S CRD YAML, just pass it straight through to K8S?

[Kenneth Koski (knkski)]

See the CRD YAML here:

https://github.com/juju-solutions/charm-kubeflow-pytorch-operator/blob/master/files/crd-v1beta1.yaml

And what we have to pass to pod_spec_set here:

https://github.com/juju-solutions/charm-kubeflow-pytorch-operator/blob/master/reactive/kubeflow_pytorch_operator.py#L75

[Ian Booth (wallyworld)]

The yaml sent by the charm to specify crd is now something like this:

is a map of specs keyed on name

customResourceDefinitions:
  pytorchjobs.kubeflow.org:
    group: kubeflow.org
    version: v1beta1
    names:
      kind: PyTorchJob
      plural: pytorchjobs
      singular: pytorchjob
    scope: Namespaced
    validation:
      openAPIV3Schema:
        properties:
          spec:
            properties:
              pytorchReplicaSpecs:
                properties:
                  Master:
                    properties:
                      replicas:
                        maximum: 1
                        minimum: 1
                        type: integer
                  Worker:
                    properties:
                      replicas:
                        minimum: 1
                        type: integer

[Ian Booth (wallyworld)]

And here's how I changed the kubeflow-tf-job-operator charm's kubeflow_tf_job_operator.py for example: https://pastebin.ubuntu.com/p/R5spCXjnHk/