You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One of the customers reached to us and asked for this feature.
The use-case is that each worker can have different specs, and the user wants to maximize the amount of resources used in the presence of 2 VMs per host limitation imposed by Apple.
We could probably extend the v1.Worker structure and add an option to orchard worker run that will update two new fields in that structure: CPUDefault and MemoryDefault. These values will be per-VM.
Afterwards, when the VM is scheduled, its actual CPU and memory values will be updated in case none were explicitly specified at the moment of creation.
In v1.VM we probably need to add something like CPUActual and MemoryActual to avoid overwriting the original values so that when the VM is re-scheduled, we'd be able to know whether the original values indicated by the user were unset.
The text was updated successfully, but these errors were encountered:
One of the customers reached to us and asked for this feature.
The use-case is that each worker can have different specs, and the user wants to maximize the amount of resources used in the presence of 2 VMs per host limitation imposed by Apple.
We could probably extend the
v1.Worker
structure and add an option toorchard worker run
that will update two new fields in that structure:CPUDefault
andMemoryDefault
. These values will be per-VM.Afterwards, when the VM is scheduled, its actual CPU and memory values will be updated in case none were explicitly specified at the moment of creation.
In
v1.VM
we probably need to add something likeCPUActual
andMemoryActual
to avoid overwriting the original values so that when the VM is re-scheduled, we'd be able to know whether the original values indicated by the user were unset.The text was updated successfully, but these errors were encountered: