Hello,
I’m looking for any VM Open Nebula Scheduler configurable that will stop trying to schedule a VM within a “Service Template” from “oneflow-template instantiate”. I did search for answers to this question, but only found years old post and specific to a single VM deployment.
Here we have a Service template with many VM Roles defined. At times, there is not enough resources. Cannot dispatch VM: No host with enough capacity to deploy the VM
All VMs are required for the Service to work properly.
We see that the Template state will stay in “Deploying” forever. This is tough for our automated infra triggering these template launches. Is there any way to get a different State on the oneflow API or automatically fail the deployment after a given time period?
We can workaround this by walking through all the VM for there status, but would prefer a status update from oneflow if that’s possible.
There are states for the oneflow instances and states for each of the role of the instances. If there are VMs managed by the service that have still not reported READY, then it will remain in that state until the VMs report back.
We see that the Template state will stay in “Deploying” forever. This is tough for our automated infra triggering these template launches. Is there any way to get a different State on the oneflow API or automatically fail the deployment after a given time period?
Could you elaborate a bit on what you mean by getting a different state ? There is a state for failures during deployment, but that only happens provided that a VM fails to deploy.
What I meant by “getting different state” was is there any way for this to Fail based on not enough resources vs staying in “deploying” forever.
For example if there isn’t enough IPs in the network, it doesn’t wait. It immediately returns “Failed_Deploying”. This is nice from an automated API perspective. It also returns a nice clear log as to why it failed. (Screen shot#1 below)
However when it is short on Host Memory/CPU (I assume also for datastore, but haven’t tested that). Then the service profile will stay in “deploying” forever waiting from Host resources. I realize the job has been sent to the scheduler and it continuously attempt to find resources. There is certainly a use-case where that is desirable. In my case, I’d rather it fail and let our automation decide what to do next. (see 2nd and 3rd Screen shot below)
Hi Ken, could you open an issue requesting this as a feature ? In this case you’d need something like a TIMEOUT for a PENDING VM. This is a change on the scheduler that could have a lot of implications so it needs to be reviewed to check if it makes sense.
