Description
Add multi-cluster scheduling support to OneKS by exposing deployment scheduling configuration. OneKS should allow users to select the target OpenNebula cluster where the OneKS cluster VMs will be deployed, as well as define a basic placement strategy for those VMs.
This would make it possible to control whether VMs should be placed in a specific OpenNebula cluster, kept together on the same host, spread across different hosts, or scheduled according to other supported placement policies.
The feature should also validate that the resources required by the deployment are compatible with the selected OpenNebula cluster. This includes checking that the selected virtual networks are available in that cluster and that the OneKS appliance image is present in an image datastore accessible by the target cluster.
Use case
When starting a OneKS deployment, users should be able to choose where the cluster resources will be placed. This is useful for environments with multiple OpenNebula clusters and policies.
Before provisioning starts, OneKS should verify that:
- The selected OpenNebula cluster exists and is accessible.
- The selected virtual networks are available in the target cluster.
- The OneKS appliance image is available in an image datastore accessible by that cluster.
If any of these checks fail, OneKS should return a clear validation error BEFORE starting the deployment.
Interface Changes
OneKS should expose deployment-related configuration as part of the cluster deployment input:
deployment:
cluster:
id: 0
networks:
public:
id: 100
private:
id: 101The existing network definition could also be moved under the deployment section, since the selected networks are part of the placement and deployment context.
Additional Context
The implementation should integrate with the OneKS provisioning flow so that scheduling configuration is applied when creating the seed VM, control-plane VM, and worker node VMs. A first implementation could define scheduling globally at cluster level, with all node groups inheriting the same configuration. More advanced per-node-group scheduling could be added later if needed.
Possible implementation points:
- Extend the OneKS cluster model with scheduling configuration.
- Validate the target OpenNebula cluster before provisioning.
- Validate that required resources are available from the selected cluster.
- Apply the selected scheduling constraints when instantiating OneKS VMs.
- Return clear validation errors when the requested placement cannot be satisfied.
Progress Status
Description
Add multi-cluster scheduling support to OneKS by exposing deployment scheduling configuration. OneKS should allow users to select the target OpenNebula cluster where the OneKS cluster VMs will be deployed, as well as define a basic placement strategy for those VMs.
This would make it possible to control whether VMs should be placed in a specific OpenNebula cluster, kept together on the same host, spread across different hosts, or scheduled according to other supported placement policies.
The feature should also validate that the resources required by the deployment are compatible with the selected OpenNebula cluster. This includes checking that the selected virtual networks are available in that cluster and that the OneKS appliance image is present in an image datastore accessible by the target cluster.
Use case
When starting a OneKS deployment, users should be able to choose where the cluster resources will be placed. This is useful for environments with multiple OpenNebula clusters and policies.
Before provisioning starts, OneKS should verify that:
If any of these checks fail, OneKS should return a clear validation error BEFORE starting the deployment.
Interface Changes
OneKS should expose deployment-related configuration as part of the cluster deployment input:
The existing network definition could also be moved under the deployment section, since the selected networks are part of the placement and deployment context.
Additional Context
The implementation should integrate with the OneKS provisioning flow so that scheduling configuration is applied when creating the seed VM, control-plane VM, and worker node VMs. A first implementation could define scheduling globally at cluster level, with all node groups inheriting the same configuration. More advanced per-node-group scheduling could be added later if needed.
Possible implementation points:
Progress Status