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

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

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