On 22/01/2021 15:56, Ian Jackson wrote: > Previously, we let the Xen build system and startup scripts choose > which xenstored to use. Before we upgraded to Debian buster, that > gave us C xentored tests on ARM. Since then, armhf and arm64 have > both had enough ocaml support and we haven't been testing C xenstored > at all ! > > Change this, by selecting between C xenstored and Ocaml xenstored > "at random". Actually, this is based on the job name. So the same > job in different branches will use the same xenstored - which helps > avoid confusion. > > I have diffed the output of standalone-generate-dump-flight-runvars. > As expected, this addes a variable all_host_xenstored to every job. > > To make sure we have enough diversity, I eyeballed the results. In > particular: > * The smoke tests now have 2 C and 2 Ocaml, one of each on > ARM and x86. > * XTF tests have 2 oxenstored and 3 C xenstored. > * The ovmf flight has one of each > * The seabios and libvirt flights look reasonably mixed. > > Most other flights have enough jobs that I think things are diverse > enough without looking at them all in detail. > > I think this lack of testing needs fixing for the Xen 4.15 release. > So after review I intend to push this to osstest pretest, and may > force push it even if shows regressions.
Sounds good. A couple of quick questions/observations. Does this cope in a sensible way if, for whatever reason, the chosen daemon isn't present? How hard would it be to add the 3rd option, stub-cxenstored into this mix? It is just one other key in xencommons to tweak. SUPPORT.md doesn't appear to make any statements about the disposition of xenstoreds, but stub-cxenstored is used by at least two major downstreams so is obviously has security support in practice, and ought to be tested. ~Andrew
