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

it. --- tests/qemuxml2argvtest.c | 24 ++++++++++++++++-------- 1 file changed, 16 insertions(+), 8 deletions(-)

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.

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:

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.

On 04/08/2014 07:06 AM, Guido Günther wrote: >>> 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. Your approach skips the test, which means less testsuite coverage. I'd rather poke into internals to make the testsuite independent of the environment while still maximizing coverage.

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 upfront but setting it later

so we skip the user/group existence check. This solution was suggested by Daniel P. Berrange and tested by Martin Kletzander. --- tests/qemuxml2argvtest.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)