Xen Orchestra Container Storage Interface (CSI) for Kubernetes
-
@Cyrille Hi. For what functionality does this plugin require XO? VDI operations are well covered with XAPI alone.
-
XO is meant to be the "middleware" for you entire XCP-ng infrastructure. Most of our plugins are using the XO API (Terraform, Pulumi…), as it's a single point to connect, regardless the number of pools you have.
-
@olivierlambert That's all fine and understandable but my question is more on the technical side of things... and still not answered
-
I'm not sure to get the question then
It's not a technical requirement, it's a design decision. -
@bvitnik As Olivier said, it's more of a design decision than a technical requirement. The idea behind using XO is to have a single point of entry, regardless of the number of pools, etc.
For example, this allows the mapping of Kubernetes regions to Xen Orchestra pools and Kubernetes zones to Xen Orchestra hosts with a single entry point and credentials.
-
@Cyrille My concern is that you are closing the door for people that do not need (or do not want) XO in their stack. Maybe they are using other ways to manage the stack, possibly custom developed, and XO would just be one more point of failure, another security concern etc.
From what I can gather, XO effectively acts as an API proxy here, plus as a list of pools. That's a rather insignificant (and forced?) role, from a technical point of view, considering XO has much much more functionality outside of what XCP-ng and XAPI offer themselves. All of that unused and not required for this integration.
-
Actually, it's not a closed door; it's more a door that is opening for people who are already using both Xen Orchestra and Kubernetes.
From a technical point of view, it makes more sense for us to use XO, because its API is easier to use, especially with the new REST API. For the application side itself, it does many thing that we don't have to deal with. For VDIs, perhaps it's not so much. But for other things such as backups, live migrations, templates and VM creation... it's easier. Moreover, using a unique SDK to develop tools makes sense for our small DevOps team in terms of development speed, stability and security.
-
Again, XCP-ng and Xen Orchestra are really meant to work together: that’s by design. Our goal is to offer a unified stack with one consistent REST API to manage everything, across any number of pools.
XO already handles a ton of things: auth (with oidc, SAML etc.), multi-pool aggregation, RBAC/ACLs, task tracking, templates, backups, live migrations, etc. By building on top of XO, we can focus on adding real value instead of re-implementing all that logic again in any 3rd party program we maintain in full open source and for free.
And honestly, I don’t see any issue relying on XO: everything is fully open source, and all features are available for free from the sources, just like it’s always been. Nobody’s forcing you to use one or the other: if you’d rather build directly on XAPI, you absolutely can.
-
Great stuff, looking forward and will try the CSI in the next couple of weeks
@bvitnik There is an old CSI for xcp-ng (5 years old) which directly talks to the Xen-API, but I'd rather have a middleware which as @olivierlambert already stated has ACL's and security build-in.
Eventually you will end up in a broken xen cluster because you have a k8s node with cluster wide privileges to the XenAPI.@olivierlambert Is there any loose roadmap for the CSI?
Cheers,
Jan -
The roadmap depends a lot on the feedback we have on it
More demand/popular, faster we'll implement stuff
