Update fabric8 kubernetes-client with support for TPR

[foxish]

Prerequisite for #126

cc @iyanuobidele

[iyanuobidele]

@foxish

Thanks for opening this up. I already whipped something up yesterday to complete the implementation of the high level thirdpartyresource. I will be spending cycles today looking into how to design/represent/implement the tpr instances themselves.

I would do some more thinking, and once I have something more concrete I will share with the group to get thoughts.

[foxish]

Sounds awesome. Thanks for the update!

[foxish]

I already whipped something up yesterday to complete the implementation of the high level thirdpartyresource.

Is this specific to SparkJob, or are you looking at the changes in the fabric8 client upstream as well?

[iyanuobidele]

I'm only looking to changes in the fabric8 client upstream

[iyanuobidele]

Like I said earlier, I completed the implementation of the top-level thirdPartyResources and wrote some test cases surrounding that. Based on the assumption that ThirdPartyResources are a non-namespaced object.

For the custom Objects (TPR instances) which we need to get this done, I can't seem to find any support for that from the kubernetes-api-model, so I need to make another PR into the kubernetes-api-model project. To support building it, and to add its base representation.

On that, I was thinking about adding a model for just the "SparkJob" since we have a clear idea of what that would look like. But I am leaning towards making it work for any arbitrary TPR instance. The problem with this - which IMO is not a big deal - is that all customObjects would be called that.

Also, look's like the PR dependencies are increasing. @foxish would you suggest opening issues on the different projects to track it all ?

[foxish]

On that, I was thinking about adding a model for just the "SparkJob" since we have a clear idea of what that would look like.

Are you referring to making a schema-aware model which lets us handle SparkJobs as though they are native objects but lives upstream?

[iyanuobidele]

Yes.

[iyanuobidele]

I will open a PR to put in the first change of the top-level tpr since it's a pre-req to adding customObjects.

[foxish]

The top-level TPR change SGTM.
TPR instances have no general notion of schema. I am thinking that it wouldn't be ideal for a SparkJob schema to live upstream. It would be out of place, and make it harder for us to change it or add new fields.
In terms of TPR instances, what the library should support is the ability to submit custom resources, of an arbitrary kind and apiVersion and custom fields within. The validation and schema enforcement should live in our spark fork. Does that make sense?

[iyanuobidele]

Right, yeah that's what I thought too. Cool.

[iyanuobidele]

Apologies. I'm trying to clear my plate, and planning to get back to this effort in the next week.

[foxish]

We have CRD support in the fabric8 client. We don't need TPRs anymore.