From: Daniel Gomez <da.gomez@kernel.org>
To: Luis Chamberlain <mcgrof@kernel.org>,
Chuck Lever <chuck.lever@oracle.com>
Cc: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>,
"slava@dubeyko.com" <slava@dubeyko.com>,
"kdevops@lists.linux.dev" <kdevops@lists.linux.dev>
Subject: Re: [RFC PATCH] storage-subsystem: correct playbooks for Fedora distro
Date: Fri, 22 Aug 2025 10:34:07 +0200 [thread overview]
Message-ID: <340e60e4-096a-432a-801d-69d51a1fd426@kernel.org> (raw)
In-Reply-To: <aKfThB5tqDTi8y-K@bombadil.infradead.org>
On 22/08/2025 04.18, Luis Chamberlain wrote:
> On Fri, Aug 15, 2025 at 02:29:33PM -0400, Chuck Lever wrote:
>> Unfortunately your experience is typical of first time kdevops users. It
>> took me several months of swearing to get it working the first time, but
>> I was a total newbie to Ansible and libvirt when I started.
>
> I think we can make things better with NixOs as a default for future
> ramp ups, but this is *theoretical*. So here's what I think we should do:
>
> 1) Add NixOS
> 2) Evaluate if we should just require user session
>
> We can test 1) without making it a default for a while and see if really
> a lot of the distro pains are overcome.
>
> 2) Would affect debian based users, and requires more review from others.
>
> What else can we do?
>
> Maybe just get claude to support selinux / apparmor?
Besides selinux/apparmor and libvirt user uri session support, I'd add:
* Remove sudo privilege escalation for the localhost (controller node)
* This implies manual user configuration for running kdevops: user/group
configuration, package installation, etc
* Review/update kdevops docs regarding how to set up the controller node to
be kdevops-ready
* Note: We don't need to remove it entirely, just make this path optional
* Remove/optional wide host configuration: basically sandboxing kdevops
* systemd services
* SSH configurations
* libvirt configs
next prev parent reply other threads:[~2025-08-22 8:34 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-14 19:09 [RFC PATCH] storage-subsystem: correct playbooks for Fedora distro Viacheslav Dubeyko
2025-08-15 0:35 ` Luis Chamberlain
2025-08-15 13:48 ` Chuck Lever
2025-08-15 8:47 ` Daniel Gomez
2025-08-15 11:18 ` Daniel Gomez
2025-08-15 17:28 ` Viacheslav Dubeyko
2025-08-15 17:40 ` Chuck Lever
2025-08-15 18:16 ` Viacheslav Dubeyko
2025-08-15 18:29 ` Chuck Lever
2025-08-15 18:39 ` Viacheslav Dubeyko
2025-08-15 18:46 ` Chuck Lever
2025-08-22 2:18 ` Luis Chamberlain
2025-08-22 8:34 ` Daniel Gomez [this message]
2025-08-22 13:50 ` Chuck Lever
2025-08-22 23:14 ` Luis Chamberlain
2025-08-23 12:33 ` Daniel Gomez
2025-08-23 21:21 ` Luis Chamberlain
2025-08-25 12:16 ` Daniel Gomez
2025-08-27 21:21 ` Luis Chamberlain
2025-08-24 17:00 ` Chuck Lever
2025-08-25 7:21 ` 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=340e60e4-096a-432a-801d-69d51a1fd426@kernel.org \
--to=da.gomez@kernel.org \
--cc=Slava.Dubeyko@ibm.com \
--cc=chuck.lever@oracle.com \
--cc=kdevops@lists.linux.dev \
--cc=mcgrof@kernel.org \
--cc=slava@dubeyko.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