Moving providers out of tree


Brian Goff
 

Hello!

A couple of weeks ago I opened an issue to discuss “What to do with providers”.

The main question was “should provider code continue to live in tree?”

The reasoning behind this question is we are working hard to make VK more of a framework that providers can go and build their own implementation on top of with a cleaner UX that integrates more tightly with the backend. Meanwhile in-tree providers add a lot of provider specific code that is not shared anywhere in the project.

Today provider code is pretty well split out in terms of not needing to import providers you don’t want. Providers are fully initialized in the daemon implementation and not in the VK core (vkubelet package). Of course building a daemon with only the provider you want is a bit of a mess, where build tags are used to explicitly omit providers.

— Personal opinion from here on — 

I think as a whole I would like to pull these providers out, treat the virtual-kubelet daemon as a reference implementation, and expect providers to pretty much build their own integrations.
This makes it a bit more clear as to ownership (n terms of code) for providers, where to file issues, etc.

I do like the suggestion to keep providers in tree while we are re-evaluating the provider interface to be a bit more flexible. This allows us to quickly update providers and more easily test things out while iterating (of course we must update all the providers) and makes sure we are easily able to get a more diverse view of the API’s available so we don’t unintentionally exclude some provider by requiring an interface that just doesn’t make sense. (There will be a follow-up email to discuss interface changes)

Chris (from CNCF) also suggested that we can put provider code into sub-projects in the virtual-kubelet org, which I think is fine. It would probably help with discoverability of this code. Ultimately I think this is up to each provider to decide what they would like to do. I’m fine with hosting these in the VK org, but it’s also not necessary.

So, just to get everyone in sync, are we ok to make a plan to move providers out of tree? Should we wait for provider interface changes? Does the plan to have providers build their own implementations make sense (don’t want to create a bunch of extra work for folks)?

Please don’t hesitate to raise any objections.

Thanks for reading the long emai!l :)

- Brian Goff