Kubernetes autoscaler xen api/XO api

ringods

@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

Xen Orchestra is fully open source You can build it with all XO features, it's even explaining in our doc: https://xen-orchestra.com/docs/installation.html#from-the-sources

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

yctn

@ringods maby you can join IRC or Discord if thats possible for you. cause i think there are still a few things that need to be discussed on how it should be implemented. for example. what about DHCP? since XO/xcp-ng to me knowledge has no DHCP component.
what about type loadBalancer call? since xcp-ng does not offer that.

in my DIY k8s setup i just made 2 vm's with keepalived and haproxy that are able to send proxy protocol traffic to my haproxy ingress controller in k8s using nodePort.

but DHCP i have not found a sollution. but it would be great if xcp-ng can offer like a managed/ha DHCP sollution for the future.

olivierlambert

That's why XO is relevant. All you ask can be managed at XO level, adding a simple abstraction layer

That's also why we got a load balanced in XO already BTW. We should probably study how it's done on VMware (as the link given) before taking any decision.

ringods

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

yctn

@ringods https://discord.gg/aNCR3yPaPn

ringods

@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

olivierlambert

Sure.

Do you know if it's our responsibility to create the repo or if it's within "upstream" in k8s?
That will be probably named "cloud-provider-xo" or "cloud-provider-xenorchestra". What do you think?

ddelnano

@olivierlambert

it would be our responsibility to create the repo and users would likely install it with Helm (from my reading of the cloud-provider-vsphere docs
I think either is fine. My personal vote would be for the latter (cloud-provider-xenorchestra).

olivierlambert

Great, let's do this then! On creating the repo, and will invite you Dom. @ringods what's your Github handle?

olivierlambert

Done. Both of you added!

https://github.com/vatesfr/cloud-provider-xenorchestra

ringods

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

olivierlambert

Sure go ahead you should be able to do it in terms of permissions. If not, let me know