Reconsider the use of linuxkit for cloud data providers

[davidcassany]

Currently we are using a fork of linuxkit in the shape of a yip plugin. We mostly have fork for two reasons:

• In our fork we include Add Azure metadata providers linuxkit/linuxkit#3585
• Our fork has the providers refactored in a package so other tools (aka yip) can use it as a library

The fork was meant to be a temporary fill the gap solution waiting for the azure support to be merged. Our intention was to wait for the azure support upstream merge and then one a PR with our refactor to make it accessible as a library. First step never happened and hence we are still using the fork and the upstream PR of our changes was never done.

This card is about reconsidering linuxkit use and situation. From one side the current fork is under my own user org (https://github.com/davidcassany/linuxkit) and this should not be the case. On an other side the linuxkit project does not seam to be very active and it is unclear if attempting to merge upstream our required changes is a real option.

• We could simply move our fork to rancher-sandbox and maintain our own
• We could attempt to open a PR with our refactor upstream and if merged move to upstream (no azure support though)
• We could explore other libraries or implementations (afterburn or similar ones)

[kkaempf]

While upstream linuxkit appears to be active, they're certainly overwhelmed with issue reports (302 open) and PRs (41 open) with no substantial change in sight.

Otoh, Elemental doesn't currently target Azure so we could live without the Azure provider for the time being (and thus just use upstream linuxkit).

I'd keep the current status quo for now, move from davidcassany/linuxkit to rancher-sandbox/linuxkit, and maintain our own fork.
At the end of the day, it's a yip problem and (yip) upstream might find a different solution.