From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 663C11DDF7 for ; Mon, 25 Aug 2025 12:16:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756124194; cv=none; b=qOCsAQ9WP6XqS9NTOGZkxcYShHobuW3an6q24MawEMQerBMwFCUVK0/WFhYD1GynHtw7RP02xYm3TGMmD6wCDXrfljHE9vcjzjEN8VmZBl1VFTWQthucajl61KzMZP+5Et0kth5ML5fNmRvrwGKt6+3Eeo0KMMGr9z+T6xt+bYE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756124194; c=relaxed/simple; bh=5cmA0PFUBKPN1wh/QQNtajZs7d69cRK5sbYpnWL6zLA=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=OLiIl92KT7LIBOHTqFhDcN6WLhyiH9Ws5Y9T0KAx8yeVLwYRUzErOQIAvhTRo4eJeFDF+eAKNkDhfcOwrMHVI4fAtStukCsI2vFO7YuscE3l2+eD2vajTJjhI/u+hKpzTbzm8pdpD1al6hGrxEIz+4iglB9tUx2+1u2WUatRrRY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=NRNb3U60; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="NRNb3U60" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 50916C4CEED; Mon, 25 Aug 2025 12:16:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1756124194; bh=5cmA0PFUBKPN1wh/QQNtajZs7d69cRK5sbYpnWL6zLA=; h=Date:Reply-To:Subject:To:Cc:References:From:In-Reply-To:From; b=NRNb3U60uu3B06ajOj4vZceo4yKFGvj2fkRizEfeHo2TPWVkhH9Lb1f74aTh02Ibt ODpk4svkYD07rCwwm5O/Gqn+jDj6WukX4yCSe2CCKAZA1j5VvSyB9z/1rQvVSQ8FPR m/26pQpYfD+wbxdC1ZB+SBZ35cfXFGGXGY9HpylAGcvaui/ClxR51D/3hhPXB0Dx+b aCvQIXSOPa60lyGD821nbekLirsoJHe0ou/EEIQUX1zyn/Bk+OjNN/8nS7EApDcIvb P0yExUn0qs+X67CFlkAgWs5209Yxl+gRXdGl3hWclmOzTQptg9rD6TvyatblC3d2ZC mucnfWaLkP/9A== Message-ID: <30cd0793-18ce-435b-a6c1-94ddad1ea6ed@kernel.org> Date: Mon, 25 Aug 2025 14:16:31 +0200 Precedence: bulk X-Mailing-List: kdevops@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Reply-To: Daniel Gomez Subject: Re: [RFC PATCH] storage-subsystem: correct playbooks for Fedora distro To: Luis Chamberlain Cc: Chuck Lever , Viacheslav Dubeyko , "slava@dubeyko.com" , "kdevops@lists.linux.dev" References: <33316fc7-74b9-4243-b717-42ed6a69347e@kernel.org> <0b3d5de7-4cd9-480f-b3e0-f134485660af@oracle.com> <7fb0a977fb2434d39d57da501b85fd6023774a3a.camel@ibm.com> <0ac0fc76-317f-4d77-9107-31b456d81f78@oracle.com> <340e60e4-096a-432a-801d-69d51a1fd426@kernel.org> Content-Language: en-US From: Daniel Gomez Organization: kernel.org In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 23/08/2025 23.21, Luis Chamberlain wrote: > On Sat, Aug 23, 2025 at 02:33:26PM +0200, Daniel Gomez wrote: >> On 23/08/2025 01.14, Luis Chamberlain wrote: >>> So let's order our priorities and see who is willing to help tackle >>> some of these challenges: >>> >>> * nixos -- I have a branch now, seems to work but I gotta debug ssh >> >> That's good! Can you clarify if you refer to controller node NixOS support? or >> guest support? > > Guest support. I'm also adding mirroring support. > >>> BTW I'm curious about the goal of making systemd services optional, >>> did you mean things like systemd-journal and things like that? And >>> mirroring? >> >> Yes, all these services we depend on. But I don't think we can sandbox systemd >> services. But ensuring they all can run as user services allows us to remove >> sudo. > > I am not sure some of them can be run as user services. Like: > > * systemd-timesyncd.service > * systemd-journal-remote.service > > So we'd have to figure out a way to support that. Optional, and by > default we don't use them? I think they need to be enabled by default in user mode. Optionally disabled and/or system wide installed. > >> For system systemd services, should they be part of the RPM/deb package? > > Indeed this is what makes this complex. > > Think about the bug reports. What is the path of least bugs. That is > what we'd need to settle with I think to move forward. In theory this > will be nixos and each distro's version of libvirt, and no exta systemd > stuff or mirroring. The user would have to set that up themselves if > they want it? Then we can have multiple kdevops packages like: kdevops kdevops-systemd (all) or: kdevops-systemd-mirror kdevops-systemd-timesyncd ... Where the package manager recommends to install them but not force the users to do it so. I think for systemd user services in ~/.config/systemd/user we can keep them inside Ansible/kdevops playbook. > >>> What about ssh configurations do we need to review? Perhaps to not >>> require passwordless sudo? >> >> I also meant sandboxing. I think Chuck prefers using ssh instead of >> ssh -F , which makes sense. But some users may >> not want kdevops settings scattered across their system. >> >> What about a kdevopsctl thing? e.g. kdevopsctl ssh vm. > > We already use a custom ssh config which we include. > Is that really so terrible? Absolutely not! I think is hard to have idempotency on files that the user may update themselves like the .ssh/config. We already have support for it and never fail to me: cat ~/.ssh/config # Automatically added by kdevops # kdevops_version: 5.0.2-g5258e41 Include ~/.ssh/config_kdevops_* > I think such a thing could optional. Agreed. That's all. > Or is it just that cloud needs to move over to use that too? Not AFAIK. > > Luis