Initial prop for custom resource definitions

[shawn-hurley]

Describe what this PR does and why we need it:
Proposal for using custom resource definitions.

[eriknelson]

Should we generate our own client or write our own. This is a nice overview of client generation. This is an example of client generation. This is an example of creating our own.

I would prefer to avoid code generation if we can help it.

We should discuss where this client lives. Should we create a new repo for this client so that other users could interact with our resources? This may eventually be a nice to have but could also cause headaches.

I'm not sure we should publicize the fact that these are accessible to normal users. The broker makes some assumptions that these are internal use only. It's never been designed for this.

Proposal though, +1. Great work @shawn-hurley.

[maleck13]

@shawn-hurley @eriknelson We use client generation for a CRD that we use with the CLI we are creating. In my experience it saves quite a lot of time (although the initial setup is a cost) as it generates a full client with a very similar API to the kubernetes go-client. It also generates all the fakes that you need to allow simple testing when using the client.
If you are interested here is our definition:
https://github.com/aerogear/mobile-cli/tree/master/pkg/apis/mobile
The client it generates lives here:
https://github.com/aerogear/mobile-cli/tree/master/pkg/client
And here is an example of the fakes that allow unit tests
https://github.com/aerogear/mobile-cli/blob/master/pkg/cmd/clients_test.go#L47
Finally here is the make target to generate the clients
https://github.com/aerogear/mobile-cli/blob/master/scripts/generate.sh

Edit wrong link

[shawn-hurley]

I am adding my two sense here because I realize I did not advocate for one way or the other in the proposal.

I agree that for the first pass that we need to keep these for internal use only. I think soon after we may have to start dealing with cases where things change underneath us.

The client I think is going to start easy with basic CRUD and get much more involved. I wouldn't mind taking this approach first and reevaluating latter if the maintenance of it becomes a pain.

I think that in the end, we will not want to create and manage listers/watchers and the rest when it comes to the client. A full client is actually pretty involved, and I think there might be a case for making a kube client look like other kube clients.

No matter where the client lives I think it makes sense to keep it isolated so that if we need to it should be easily ripped out.