@olivierlambert thanks for that. Are you ok if I configure Github Actions as the CI for this repo?

@olivierlambert, coming back to this question:

edit: do you know where could we have an overview on the kind of "calls" that would be needed to be done from Kubernetes?

Every cloud provider is a Kubernetes controller. The basic initialisation creates a structure of type cloudprovider.Interface. Here you can see the initialisation of the vSphere cloud provider:

https://github.com/kubernetes/cloud-provider-vsphere/blob/de156a4200204bb23c3ad86683ea8530302b9850/cmd/vsphere-cloud-controller-manager/main.go#L195-L215

The Golang interface to implement has the following functions which needs to be implemented:

https://github.com/kubernetes/cloud-provider/blob/e0df2eeb11dbb85b96df07b5f3ee374cc9a6875b/cloud.go#L42-L69

I hope this helps.

I understand that more investigation is needed, but can we do this work together? I can, and want to, help out to bootstrap the basic project layout, build setup, etc in a new Git repository. A repository can always be renamed if the name is not 100% correct.

Ringo

@yctn or @olivierlambert, which Discord is this? I don't see it mentioned in the Community section of the website.

@olivierlambert I have no problem being it a Kubernetes component talking to Xen Orchestra. But that limits my contribution ability to the free features of XO. I only use XCP-ng for a personal homelab on a single machine setup.

@olivierlambert that would be great. I'm willing to contribute on this. While I wouldn't call myself an expert on Kubernetes development, I do know a thing or two.

The link that @yctn mentioned is the old approach, with in-tree cloud provider implementations. For completeness, in-tree means that all the cloud provider implementations were part of the main git code tree. In the old approach, a cloud provider took care of nodes (VMs), network and storage.

As you can expect, the approach today is to have out-of-tree cloud provider implementations, residing in separate Git repositories. In this approach, the storage aspect has been separated and you have two different integrations to write:

• Cloud Provider Interface (CPI): lets Kubernetes manage worker nodes and handles the network interfaces to the VMs.
• Container Storage Interface (CSI): lets Kubernetes manage Persistent Volumes (PVs) which maps on underlying storage technology.

As an example, here are the implementations of the above 2 components for vSphere:

• Kubernetes vSphere Cloud Provider (code)
• Kubernetes vSphere CSI Driver (code)

For XCP-ng, there is a CSI driver started by Arturro Guerra:

https://github.com/ArturoGuerra/xcpng-csi

It probably needs a refresher and some more testing but I guess we don't have to start from scratch here.

The cloud provider implementation for XCP-ng needs to be started. If you could create a repository named cloud-provider-xcp-ng (or similar) on your Github organization, initialized with a README and a LICENSE file (preferrably Apache License 2.0), then I can clone it and provide the initial code.

Ringo

Looking at Kubernetes these days, I guess we have to build a Cloud Controller Manager aimed at the XEN api.

This can be a standalone component which should be deployed to your Kubernetes cluster.

https://kubernetes.io/docs/tasks/administer-cluster/developing-cloud-controller-manager/

R.