kdevops.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Luis Chamberlain <mcgrof@kernel.org>
To: Frederick Lawler <fred@cloudflare.com>
Cc: Jeff Layton <jlayton@kernel.org>,
	kdevops@lists.linux.dev, kernel-team@cloudflare.com
Subject: Re: [RFC PATCH] fstests: Request inferred user
Date: Thu, 31 Aug 2023 12:30:16 -0700	[thread overview]
Message-ID: <ZPDqSGZJPM4/dJEZ@bombadil.infradead.org> (raw)
In-Reply-To: <ZPCa2jZi72hWKkwf@CMGLRV3>

On Thu, Aug 31, 2023 at 08:51:22AM -0500, Frederick Lawler wrote:
> On Thu, Aug 31, 2023 at 06:13:23AM -0400, Jeff Layton wrote:
> > On Wed, 2023-08-30 at 18:53 -0500, Frederick Lawler wrote:
> > > Currently when running make fstests for bare-metal setups, the data_user
> > > 'vagrant' is set for the /data partition. This is currently set as the default
> > > data_user. We have the option to edit this in extra_vars.yml.
> > > 
> > > make linux checks for an inferred user prior to setting the uid/gid for
> > > the /data partition.
> > > 
> > > In the situation where we don't add the 'vagrant' user to the
> > > bare-metal, we get a "user does not exist" on make fstests.
> > > 
> > > In both cases we do not want to switch users between the two targets,
> > > nor do we want to necessarily ensure that the 'vagrant' user exists on
> > > the metal. Therefore, request the inferred user on make fstests.
> > > 
> > > Signed-off-by: Frederick Lawler <fred@cloudflare.com>
> > > ---
> > > Since this is essentially in two places, I figure this should be more
> > > generic and then included in other make targets like cxl. But this is to
> > > get the discussion going if this or some other generic approach is
> > > preferred.
> > > ---
> > >  playbooks/roles/fstests/tasks/main.yml | 37 ++++++++++++++++++++++++++
> > >  1 file changed, 37 insertions(+)
> > > 
> > > diff --git a/playbooks/roles/fstests/tasks/main.yml b/playbooks/roles/fstests/tasks/main.yml
> > > index e2d7ce5295b7..2898833b0732 100644
> > > --- a/playbooks/roles/fstests/tasks/main.yml
> > > +++ b/playbooks/roles/fstests/tasks/main.yml
> > > @@ -10,6 +10,43 @@
> > >        skip: true
> > >    tags: vars
> > >  
> > > +- name: Get username we are using
> > > +  command:
> > > +    cmd: whoami
> > > +  register: username_on_target
> > > +  when:
> > > +    - infer_uid_and_group|bool
> > > +
> > > +- name: Set target user as a fact
> > > +  set_fact:
> > > +    target_user: "{{ username_on_target.stdout }}"
> > > +  when:
> > > +    - infer_uid_and_group|bool
> > > +
> > > +- name: Run getent against the inferred target user
> > > +  getent:
> > > +    database: passwd
> > > +    key: "{{ target_user }}"
> > > +  register: getent_running_user
> > > +  when:
> > > +    - infer_uid_and_group|bool
> > > +
> > > +- name: Run getent against the inferred target group
> > > +  getent:
> > > +    database: group
> > > +    key: "{{ target_user }}"
> > > +  register: getent_on_group
> > > +  when:
> > > +    - infer_uid_and_group|bool
> > > +
> > > +- name: Override user and group with inferred settings if feature is enabled
> > > +  set_fact:
> > > +    user: "hplip"
> > 
> > Why "hplip" here?
> 
> This was mostly copy/pasted from
> ./playbooks/roles/bootlinux/tasks/main.yml. I see it was introduced in commit
> f10add06446b ("kdevops: remove ansible galaxy dependency") for that file,
> but I'm unclear the use there. I'd like to know as well.

I recall fstets having odd user requirements but that was just for some
odd tests. I can't trace hplip down to anything so I say we just remove
it for both.

  Luis

  reply	other threads:[~2023-08-31 19:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-30 23:53 [RFC PATCH] fstests: Request inferred user Frederick Lawler
2023-08-31 10:13 ` Jeff Layton
2023-08-31 13:51   ` Frederick Lawler
2023-08-31 19:30     ` Luis Chamberlain [this message]
2023-08-31 19:35       ` Jeff Layton
2023-08-31 19:36         ` Luis Chamberlain
2023-08-31 19:35 ` Luis Chamberlain

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=ZPDqSGZJPM4/dJEZ@bombadil.infradead.org \
    --to=mcgrof@kernel.org \
    --cc=fred@cloudflare.com \
    --cc=jlayton@kernel.org \
    --cc=kdevops@lists.linux.dev \
    --cc=kernel-team@cloudflare.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;
as well as URLs for NNTP newsgroup(s).