[OSSTEST PATCH v3 0/3] Test case for cpupools

[Dario Faggioli <dario.faggioli@citrix.com>]

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)