Odo: Implement a kclient package for interacting with Kubernetes clusters

[johnmcollier]

As we work to make odo more Kube-generic and have it function on non-OpenShift clusters, we'll need a library to interact with those clusters, much like how occlient functions today. This would be a standalone library from occlient that would interface with client-go to interact with resources on a Kubernetes cluster.

• [ ] Determine which client-go library to use
  
  
  
  • Right now odo is pulling down OpenShift's fork of client-go for Kube 1.11 and is still needed for certain OpenShift packages it seems, so we can't get rid of it
  
  
  • Dual maintenance of multiple client-go's seems messy at best, so probably best to just keep using the OpenShift fork of client-go (it _should_ work on other Kubes for what we need)
  
  
• [ ] Implement a kclient library
  
  
  
  • See what / if any functions can be moved over from occlient
  
  
  • Best to keep things simple and modularized, rather than having a huge single file like there is for occlient.go
  
  
• [ ] Implement tests for kclient

[johnmcollier]

Per the earlier odo-dev call this week, I can take a look at this.

[kadel]

I would add to this is that the main point why we want to implement kclient is to use it as we start implementing devfile support.

I wouldn't start with moving functions from occlient. Devfile flow will be quite different from what we are doing right now with s2i. I would rather start with a clean slate, make it as you say, simpler and modularized and add functions only as we need them for devfile support.

[rajivnathan]

We can start real small with kclient, maybe just these 2 functions:
WaitAndGetPod
ExecCMDInContainer

Once we have the file created and the plumbing in place we can add to it as needed.

[johnmcollier]

@rajivnathan @kadel That sounds like a good approach. I'll get to work on it.

Here's what I'm thinking in terms of structure. Separate out kclient into subpackages for different resources (i.e. interacting with pods, services, etc):

pkg/kclient
├── pods
|   ├── pods.go
|   └── pods_test.go
├── services
|   ├── services.go
|   └── services_test.go
├── kclient.go

So in this case, WaitAndGetPod and ExecCMDInContainer would both go under the pods subpackage in kclient.

[rajivnathan]

@girishramnani @kadel Should this one have the devfile label as well? Do we need a kubernetes label as well or is just devfile label good enough? Just want to make sure I track the right issues.

[johnmcollier]

/assign @johnmcollier

[rajivnathan]

/area devfile