Re: [RFC PATCH] storage-subsystem: correct playbooks for Fedora distro

[Daniel Gomez <da.gomez@kernel.org>]

On 23/08/2025 01.14, Luis Chamberlain wrote:
> On Fri, Aug 22, 2025 at 09:50:14AM -0400, Chuck Lever wrote:
>> On 8/22/25 4:34 AM, Daniel Gomez wrote:
>>> 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
> 
> Yes, that would be good.
> 
>> +1 (or more). A sleeker security profile would do wonders for kdevops
>> adoption.
> 
> It seems we're all in agreement.
> 
>> Another thought would be to construct a GitHub Action that builds a
>> kdevops RPM (or .deb) for us. Stick all the control host dependencies
>> in that. Privilege would then be needed only when kdevops is installed.

What do you mean? Can you elaborate? I'm not sure what would be packed in that
RPM/deb file. Just the runtime dependencies kdevops depends on?

> 
> All the above sounds like weekend kdevops claude code projects, but my
> experience is showing that the hard part with claude is not the
> generation but the curation / review of the code it generates, so that
> adds an extra amount of time. But despite all that, I suspect we can

Agree.

> get all this done in about two months. The ordering is important, ie
> it would not make sense to build rpms / debs until we have selinux and
> appramore thing resolved, and making the sudo on localhost stuff optional
> as well.

Agree.

> 
> 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?


>   * apparmor / selinux: I can take this on next
> 
> Left on the TODO path towards shiny goals, any takers?
> 
>   * make sudo optional for localhost
>   * make libvirt user session work on debian based systems, and once
>     that works, ensure that system session still works. Once that
>     is done we flip the switch to make user session default
>   * Decide on if we want to remove FIRST_RUN or do we use that for
>     future deb / rpm installation
>   * Make optional:
>     - systemd services
>     - SSH configurations
>   * debian/control / rpm spec file. Maybe nix packaging too?
> 
> 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.

For system systemd services, should they be part of the RPM/deb package?

> 
> 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 <kdevops-vm> instead of
ssh -F <kdevops-vm-config> <kdevops-vm>, 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.

> 
>> Don't forget Ansible. I have a patch that adds a requirements.yml file;
>> it pulls the latest collections and installs them under the Ansible
>> user's home directory. Will post soon.

I'm curious about this too. Why is that needed? My understanding from this
thread [1] is that we should stride to have distro packages.

Link: https://lore.kernel.org/kdevops/ZrUGoziFf2WSSUVs@bombadil.infradead.org/ [1]

> 
> Curious more about this. A very long time ago I had used ansible-galaxy
> to move tons of thing out to it, but in the end it turned out to be an
> extreme hassle to manage all things. So the project ended up converging
> brining all roles into the project.
> 
> But if this is for roles out side of kdevops, I think it makes sense.
> 
>   Luis