On Tue, Apr 08, 2014 at 03:03:55PM +0200, Martin Kletzander wrote:
On Tue, Apr 08, 2014 at 12:52:36PM +0100, Daniel P. Berrange wrote:
On Tue, Apr 08, 2014 at 01:47:14PM +0200, Martin Kletzander wrote:
On Tue, Apr 08, 2014 at 12:49:25PM +0200, Guido Günther wrote:
On Tue, Apr 08, 2014 at 10:09:59AM +0100, Daniel P. Berrange wrote:
On Mon, Apr 07, 2014 at 04:40:24PM -0600, Eric Blake wrote:
On 04/07/2014 02:02 AM, Guido Günther wrote: > When building packages in a clean chroot the QEMU_USER and QEMU_GROUP > don't exist making VirQemuDriverConfigNew fail with privileged=true. > > Avoid that by not requiring priviliged mode and skipping tests that need
s/priviliged/privileged/
> it. > --- > tests/qemuxml2argvtest.c | 24 ++++++++++++++++-------- > 1 file changed, 16 insertions(+), 8 deletions(-)
Seems like this is what avoids the fail pointed out in 1/3. It still feels fishy that our testsuite is that dependent on the system (ideally, we'd provide a way to mock things up so that creating the config file NEVER fails when run from the testsuite, even if the uid doesn't exist - because we shouldn't be probing the live system, only our mockups). I'd wait for a second opinion on whether this patch is papering over a bigger problem of depending on the current system state, or whether it is an acceptable way to avoid the issue without investing the effort to tackle at the uid lookup level.
IMHO we should be passing privileged == false unconditionally, so that we always skip any magic username lookups.
I would have done that but Martin's 29151830e468f1a9d8006a62702591958a4e3481 did the opposite, so o.k. to revert that?
Reverting that will make *tune tests fail. We could, however, create our own test config instead of virQEMUDriverConfigNew() or add a parameter to it which will decide on what to do, the least being:
What about passing 'false' to ConfigNew() but then manually set 'cfg->privileged = true' on the object we get back.
That could work. All tests passed on my setup like that. And it doesn't seem weird since we're playing with the config a lot in the tests.
I do wonder if my approach wouldn't be cleaner since it doesn't poke into the objects internals. Cheers, -- Guido