Kubernetes autoscaler xen api/XO api
-
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.
-
@yctn or @olivierlambert, which Discord is this? I don't see it mentioned in the Community section of the website.
-
-
@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:The Golang interface to implement has the following functions which needs to be implemented:
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
-
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?
-
- 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).
-
Great, let's do this then! On creating the repo, and will invite you Dom. @ringods what's your Github handle?
-
Done. Both of you added!
-
@olivierlambert thanks for that. Are you ok if I configure Github Actions as the CI for this repo?
-
Sure go ahead you should be able to do it in terms of permissions. If not, let me know
