Fix handling of resource management

[vefimova]

By default if resource limits are not set they will be set to zero:
https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/api/v1alpha1/runtime/api.pb.go#L1118

what causes a try to create VM with zero vcpu set:

libvirt_1  | 2016-10-05 08:47:48.169+0000: 5905: error : virDomainDefParseXML:15299 : internal error: CPU IDs in <numa> exceed the <vcpu> count

[jellonek]

Very good catch and the cause why my branch is failing after rebase :)
For dev purpose will hardcode some values there until You will provide PR with correct resolution.

[vefimova]

Committed fix is temporary workaround

[vefimova]

@jellonek @nhlfr

Want to share my considerations re cpu resource management:

So for resource management k8s have

• optional settings for CFS (Completely Fair Scheduler):
  • quotaPeriod
  • cpuPeriod
    These put limits for i/o bandwidth limits, not cpu resource usage itself.
• and sharesPerCPU - relative value to set weighted share of available cpu resources for VM
  which is set by default=2 (1 cpu = 1024)

So, then, for example nova has cpu overcommitment ratio set as 16:1 => VMsPerHost = vCPUs*16
But for virtlet wihout setting sharesPerCPU directly it would be as 512:1, which is obviously is not acceptable at all.

There could be added limits per namespace, then default will be set to limit if there is no request for pod, but we can't rely on that. Such low default is probably unexpectable for us, to have the same ratio
we need to have 64. Probably, we need to try to propose having kubelet option for that, WDYT?

So for now I'm going to prepare patch which will set all available vCPUs for each VM with defined CPU Tuning tag with specified shares. As long as nothing is set, cpu time will be, obviously, spreaded equally among VMs, there will be problems if we start to set "requests" for cpu for some of VMs and use defaults for others, and ofcource if we overload the host by amount of created VMs, but for now it's POC, right? :) Do you agree with that?

[jellonek]

Sorry for not answering earlier - idea looks great and I like your implementation of it :)

[jellonek]

As it's already merged - closing.