From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2F07E2153E7 for ; Mon, 31 Mar 2025 20:49:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1743454183; cv=none; b=Jrd89rsirMdng/NZ0RSJj/NqeSGMd++w+1oJzVQBnI8ZwDLzqq98UVwSDSDc9FYfdHyJ6eK6ZsPGLpDZkfAgvTf9XOMb80nEPKayk6KLI5anppZepPkeelPr3UDwcszsxNitT46tftaAqVg03ei8j4MmB6c8amBK785iu9LWrOY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1743454183; c=relaxed/simple; bh=kD+3Pttz/E3mAqI5uMF3UJvYQjDF6KTHNVXiDuiYsco=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: In-Reply-To:Content-Type:Content-Disposition; b=oFXbuIUiLs9IJm6CXjlE6RdacGf/RZfQ2H+IAp9PpPkGXXBU34g2nhN5wyUpJ90BjyTabZJr22j3EY0h7HR/6pnpbSHsHU3eQh94HJCLyYMoeao1diVn0kCtmeKKWQ4dbr9PCjYDHJhxBRmNafUQfiYiy8HvEmbyt1T2QNybNa8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=SWnelEPR; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="SWnelEPR" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1743454181; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=qrrgRlrxsll36TKM7mN1GxOfEu4jwv3MiS4Cl+tt31g=; b=SWnelEPR5+hDyYi9kQrXe48+zu9bYP1V3RoFWD3XfxC6Kb8fgQaZmbBN9hzJOTqTDCKSqi KzrQgNqYCSG+WTUKFS5DbPuqNy4Tij+qkdmSOhboQyjaANLtVojNxcr3dXBrKd0vQVMg4+ 8fgquv97rhrbog8p54c171Vr48bX9CE= Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-173-EVW8f81CMJCmL5Y2DlEhOQ-1; Mon, 31 Mar 2025 16:49:37 -0400 X-MC-Unique: EVW8f81CMJCmL5Y2DlEhOQ-1 X-Mimecast-MFC-AGG-ID: EVW8f81CMJCmL5Y2DlEhOQ_1743454175 Received: from mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.93]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 8F0D8195608F; Mon, 31 Mar 2025 20:49:35 +0000 (UTC) Received: from aion.redhat.com (unknown [10.22.88.143]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 225AF180B488; Mon, 31 Mar 2025 20:49:35 +0000 (UTC) Received: by aion.redhat.com (Postfix, from userid 1000) id A3E9033D78C; Mon, 31 Mar 2025 16:49:32 -0400 (EDT) Date: Mon, 31 Mar 2025 16:49:32 -0400 From: Scott Mayhew To: Luis Chamberlain Cc: kdevops@lists.linux.dev Subject: Re: [PATCH 6/6] gen_nodes: ensure kdevops prefix has no dashes Message-ID: References: <20250329230141.3718282-1-mcgrof@kernel.org> <20250329230141.3718282-7-mcgrof@kernel.org> Precedence: bulk X-Mailing-List: kdevops@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.93 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: nKxWe1z1DKfsS0CzmTpwwBmzTmlqTAL_Wy4TgizEDmk_1743454175 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, 31 Mar 2025, Luis Chamberlain wrote: > On Mon, Mar 31, 2025 at 03:14:28PM -0400, Scott Mayhew wrote: > > On Mon, 31 Mar 2025, Luis Chamberlain wrote: > > > > > On Mon, Mar 31, 2025 at 01:35:41PM -0400, Scott Mayhew wrote: > > > > On Sat, 29 Mar 2025, Luis Chamberlain wrote: > > > > > > > > > Folks trying to use kdevops and testing with fstests will quickly > > > > > find out a surprise that their config is not being parsed correctly > > > > > until later. > > > > > > > > > > Fix this by preventing bringup if the prefix has a dash. > > > > > > > > > > We use the dash to help parallelize testing filesystem profiles and > > > > > so the host prefix goes before the filesystem name and test profile. > > > > > > > > Where does that happen? All of my kdevops setups use multiple dashes in > > > > the host prefix (e.g. "kdevops-nfs-fstests-rhel-10-nightly"), so this > > > > breaks my setup, and I'd imagine it breaks Chuck's too. > > > > > > Oh crap, sorry, does the NFS use of fstset not rely on the hostname to > > > infer the target test section? If not then how about this: > > > > No, it still maps the hostname to the test section, and unless I'm > > missing something there's no special handling. I use the same naming > > scheme for SMB as well, although I don't have nearly as many SMB workflows > > running as NFS. > > > > Unfortunately I'm using dedicated workflows for all my stuff so this > > patch won't work. Maybe just add a KDEVOPS_HOSTS_PREFIX_ALLOW_DASHES > > config option to allow this check to be bypassed? > > Yeah sure we can add KDEVOPS_HOSTS_PREFIX_ALLOW_DASHES, at least now > we have a TODO item to review if in fact prefixes with dashes may > break some existing heuristics for nfs/smb workoads. > > How is the configuration for fstests inferred for these workloads then? > The exisitng 'make fstests-baseline' will use the hostname and extract > the first part up to to the first dash, and then replace remaining Maybe we're not looking at the same stuff. Where are you seeing "the first part up to the first dash"? I'm looking at this bit which starts on line 1241 in playbooks/roles/fstests/tasks/main.yml: ---8<--- - name: Run fstests using ./oscheck.sh --print-start --journal {{ fstests_journal }} --print-done --test-section {{ fstests_section }} {{ oscheck_extra_args }} {{ all_limit_tests }} vars: fstests_section: "{{ ansible_host | regex_replace(kdevops_host_prefix + '-') | regex_replace('-dev') | regex_replace('-', '_') }}" ---8<--- I see that as 1. strip off the entire host prefix *and* the first dash 2. strip off the '-dev' suffix 3. replace the remaining dashes with underscores If I boil that down to a simple test, that appears to be exactly what it does: $ cat test.yml --- - name: Just a test hosts: all tasks: - name: Import extra_vars.yaml include_vars: extra_vars.yaml - name: Just a task vars: fstests_section: "{{ ansible_host | regex_replace(kdevops_host_prefix + '-') | regex_replace('-dev') | regex_replace('-', '_') }}" ansible.builtin.debug: var: fstests_section $ ansible-playbook -i hosts test.yml ---8<--- TASK [Just a task] *************************************************************************************************************************************************************************************************************************** ok: [kdevops-nfs-fstests-rhel-10-nightly-nfs-tls] => { "fstests_section": "nfs_tls" } ok: [kdevops-nfs-fstests-rhel-10-nightly-nfs-v42] => { "fstests_section": "nfs_v42" } ok: [kdevops-nfs-fstests-rhel-10-nightly-nfs-v40] => { "fstests_section": "nfs_v40" } ok: [kdevops-nfs-fstests-rhel-10-nightly-nfs-v3] => { "fstests_section": "nfs_v3" } ok: [kdevops-nfs-fstests-rhel-10-nightly-nfsd] => { "fstests_section": "nfsd" } ---8<--- Those match the sections in playbooks/roles/fstests/templates/nfs/nfs.config -Scott > "-" with "_", and we use that to infer what test section we will use > from the /var/lib/xfstests/config/*.config file used. > > So for example, my extrafluff-ext4-4k host will use ext4_4k test section > for its test when run. How is the test section inferred for NFS? > > Luis >