Test case for cpupools

Hey,

This is v3 of my cpupools OSSTest test case. I know, quite a few time passed... Sorry for that, I've been sidetracked. In fact, v2 was here:

http://xen-devel.narkive.com/x8VxgO3c/osstest-patch-v2-0-2-test-case-for-cpupools

Since then, I reworked the patch quite a bit. Of course, I did consider and address the comments I got with v2.

The test case tries to create one cpupool, and then plays a bit with it, e.g., by moving pCPUs and domains around. It does so for all the schedulers we support, i.e., it creates one cpupool with one scheduler, plays with it as said above, then destroys it and goes ahead with the next scheduler, etc.

A git branch is available here:

git://xenbits.xen.org/people/dariof/osstest.git tests/cpupools-v3
http://xenbits.xen.org/gitweb/?p=people/dariof/osstest.git;a=shortlog;h=refs/heads/tests/cpupools-v3

There are some host related considerations. In fact, this test case requires that an host with at least 2 pCPUs is used. v2 was failing the test, if that was not the case. Now, I'm just skipping doing pretty much everything, but I'm not reporting failure. In any case, while reviewing v2, IanC said:

"The proper fix would be a property in the hostdb which was used to
constrain which hosts the jobs containing this test could run on. (e.g. we have pcipassthrough-nic).

Maybe this way is OK until we find we are commissioning a machine with a single CPU, at which point this failure will seem pretty obvious. Ian?"

I do like this. I, actually, even started to do this already, for other reasons, and I am fine continuing working to make this happen, but I'd need some help, or at least some pointers.

I've never interacted with the hostdb, so I'd appreciate pointers for knowing where to look.

What I drafted was right that kind (or so it looks to me) of host properties, but meant at standalone mode, and I did it like in the attached patch... Any thoughts on this?

What I also miss, in both the cases of standalone mode config file defined properties, and hostdb ones, it the logic for telling the host allocator to consider such properties when choosing the host to be used for a job. I'll go studying how to do it, but if anyone feels the irresistible need of advising, feel free to go ahead... :-)

Thanks and Regards,
Dario
---
Dario Faggioli (3):
ts-cpupools: new test script
Testing cpupools: recipe for it and job definition
ts-logs-capture: include some cpupools info in the captured logs.

 make-flight     |   12 +++++
 sg-run-job      |    7 +++
 ts-cpupools     |  121 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 ts-logs-capture |    2 +
 4 files changed, 142 insertions(+)
 create mode 100755 ts-cpupools

--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)