public inbox for linux-nfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@redhat.com>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: Chuck Lever <chuck.lever@oracle.com>,
	steved@redhat.com, linux-nfs@vger.kernel.org
Subject: Re: [PATCH 0/3] nfs-utils: add testing infrastructure to nfs-utils (try #3)
Date: Thu, 7 Jan 2010 09:18:32 -0500	[thread overview]
Message-ID: <20100107091832.687cb7eb@barsoom.rdu.redhat.com> (raw)
In-Reply-To: <20100106203312.GL6612@fieldses.org>

On Wed, 6 Jan 2010 15:33:13 -0500
"J. Bruce Fields" <bfields@fieldses.org> wrote:

> On Wed, Jan 06, 2010 at 03:22:55PM -0500, Chuck Lever wrote:
> > My original idea was that this facility would be a set of smaller unit  
> > tests.  Since some of statd/sm-notify is now broken out into libraries, I 
> > think that makes it a little easier to craft targeted tests that don't 
> > require a full-blown statd running to carry out (Of course, that's 
> > speculation; I could be wrong, and Jeff has kindly set up the code for us 
> > to test this theory!).
> >
> > The old code has a statd simulator that doesn't require root, and uses  
> > its own RPC program number.  It might be reasonable to adopt that  
> > approach instead of using the real statd, for some test cases.
> 
> Like I say, it might be nice to be able to add even more intrusive tests
> (e.g. that modify the exports and then test the results over "lo" with
> the kernel client), so I'm actually happy Jeff says he's not bending
> over backwards to make the tests unprivileged.
> 

The root privs problem is definitely a valid concern.

After thinking about this problem I think the thing to do is
probably to create a "run as root" script that starts up statd (for
now) and other daemons (eventually). make check can then prompt the
user to inspect and run that script as root and then hit return when
it's ok to proceed.

That should allow someone to run most of the actual test code as an
unprivileged user. I'll plan to incorporate something like this in the
next respin.

> > Another way to set this up might be to use a container, or run it under a 
> > lightweight kvm.
> 
> Sounds ambitious for now.
> 

Agreed. That would be hard to implement across different distros (at
least until the virt stuff is more standardized).

-- 
Jeff Layton <jlayton@redhat.com>

  reply	other threads:[~2010-01-07 14:18 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-05 15:40 [PATCH 0/3] nfs-utils: add testing infrastructure to nfs-utils (try #3) Jeff Layton
2010-01-05 15:40 ` [PATCH 1/3] nfs-utils: introduce new statd testing simulator Jeff Layton
2010-01-05 15:40 ` [PATCH 2/3] nfs-utils: add statdb_dump utility Jeff Layton
2010-01-05 16:09   ` Chuck Lever
2010-01-05 19:17     ` Jeff Layton
     [not found]       ` <20100105141732.4590bcce-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
2010-01-05 19:25         ` Chuck Lever
2010-01-05 15:40 ` [PATCH 3/3] nfs-utils: add initial tests for statd that run via "make check" Jeff Layton
2010-01-05 16:37   ` Steve Dickson
     [not found]     ` <4B436AD3.2080107-AfCzQyP5zfLQT0dZR+AlfA@public.gmane.org>
2010-01-05 18:25       ` Jeff Layton
     [not found]         ` <20100105132519.02c3c76d-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
2010-01-05 21:29           ` Jeff Layton
2010-01-06 19:17 ` [PATCH 0/3] nfs-utils: add testing infrastructure to nfs-utils (try #3) J. Bruce Fields
2010-01-06 19:42   ` Jeff Layton
     [not found]     ` <20100106144247.18dc10de-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
2010-01-06 19:58       ` J. Bruce Fields
2010-01-06 20:10         ` Jeff Layton
2010-01-06 20:22         ` Chuck Lever
2010-01-06 20:33           ` J. Bruce Fields
2010-01-07 14:18             ` Jeff Layton [this message]
     [not found]               ` <20100107091832.687cb7eb-xSBYVWDuneFaJnirhKH9O4GKTjYczspe@public.gmane.org>
2010-01-08  5:05                 ` J. Bruce Fields
2010-01-08 12:03                   ` Jeff Layton
2010-01-08 14:51                   ` Jeff Layton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100107091832.687cb7eb@barsoom.rdu.redhat.com \
    --to=jlayton@redhat.com \
    --cc=bfields@fieldses.org \
    --cc=chuck.lever@oracle.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=steved@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox