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

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

[Viacheslav Dubeyko]

From: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>

Claude AI helped to make the first kdevops run successful
under Fedora Linux 42 (Workstation Edition). This patch
contains modifications suggested by Claude AI. It modifies
playbooks/roles/guestfs/tasks/bringup/extra-disks.yml and
playbooks/roles/guestfs/tasks/bringup/storage-pool-path.yml.

Generated-by: Claude AI
Signed-off-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
---
 playbooks/roles/guestfs/tasks/bringup/extra-disks.yml | 11 ++++++++++-
 .../roles/guestfs/tasks/bringup/storage-pool-path.yml |  1 +
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/playbooks/roles/guestfs/tasks/bringup/extra-disks.yml b/playbooks/roles/guestfs/tasks/bringup/extra-disks.yml
index 438b65e..a2a4f84 100644
--- a/playbooks/roles/guestfs/tasks/bringup/extra-disks.yml
+++ b/playbooks/roles/guestfs/tasks/bringup/extra-disks.yml
@@ -9,8 +9,17 @@
       - "{{ path }}"
       - "100G"
 
-- name: Update the permission settings of the drive image file
+- name: Update the permission settings of the drive image file (libvirt system uri)
   ansible.builtin.file:
     path: "{{ path }}"
     group: "{{ libvirt_qemu_group }}"
     mode: "g+rw,o-rw"
+  when:
+    - libvirt_uri_system|bool
+
+- name: Update the permission settings of the drive image file (libvirt session uri)
+  ansible.builtin.file:
+    path: "{{ path }}"
+    mode: "u+rw,g+r,o-rw"
+  when:
+    - not libvirt_uri_system|bool
diff --git a/playbooks/roles/guestfs/tasks/bringup/storage-pool-path.yml b/playbooks/roles/guestfs/tasks/bringup/storage-pool-path.yml
index 385b6cd..7a4bbbc 100644
--- a/playbooks/roles/guestfs/tasks/bringup/storage-pool-path.yml
+++ b/playbooks/roles/guestfs/tasks/bringup/storage-pool-path.yml
@@ -11,6 +11,7 @@
   ansible.builtin.fail:
     msg: "Ansible user is not part of the {{ libvirt_qemu_group }} group."
   when:
+    - libvirt_uri_system|bool
     - libvirt_qemu_group not in user_groups
 
 - name: Create storage pool path directory (libvirt session uri)
-- 
2.50.1

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

[Luis Chamberlain]

On Thu, Aug 14, 2025 at 12:09:19PM -0700, Viacheslav Dubeyko wrote:
> From: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
> 
> Claude AI helped to make the first kdevops run successful
> under Fedora Linux 42 (Workstation Edition). This patch
> contains modifications suggested by Claude AI. It modifies
> playbooks/roles/guestfs/tasks/bringup/extra-disks.yml and
> playbooks/roles/guestfs/tasks/bringup/storage-pool-path.yml.
> 
> Generated-by: Claude AI
> Signed-off-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>

Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>

Chuck since this was found on non-system session (likely Fedora), any
chance you can check to see if keeps things functional on your end?

  Luis

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

[Chuck Lever]

On 8/14/25 8:35 PM, Luis Chamberlain wrote:
> On Thu, Aug 14, 2025 at 12:09:19PM -0700, Viacheslav Dubeyko wrote:
>> From: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
>>
>> Claude AI helped to make the first kdevops run successful
>> under Fedora Linux 42 (Workstation Edition). This patch
>> contains modifications suggested by Claude AI. It modifies
>> playbooks/roles/guestfs/tasks/bringup/extra-disks.yml and
>> playbooks/roles/guestfs/tasks/bringup/storage-pool-path.yml.
>>
>> Generated-by: Claude AI
>> Signed-off-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
> 
> Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
> 
> Chuck since this was found on non-system session (likely Fedora), any
> chance you can check to see if keeps things functional on your end?
> 
>   Luis
> 

ATM I'm trying to convert all my individual LTS branches to use the
separate kernel builder, and I haven't sync'd up to upstream kdevops in
many weeks. (Once the conversion is done I will catch up).

I've been using Fedora 42 on occasion and there have certainly been some
changes in that distro that have de-stabilized things.

-- 
Chuck Lever

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

[Daniel Gomez]

On 14/08/2025 12.09, Viacheslav Dubeyko wrote:
> From: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
> 
> Claude AI helped to make the first kdevops run successful
> under Fedora Linux 42 (Workstation Edition). This patch
> contains modifications suggested by Claude AI. It modifies
> playbooks/roles/guestfs/tasks/bringup/extra-disks.yml and
> playbooks/roles/guestfs/tasks/bringup/storage-pool-path.yml.

Can you elaborate the commit message explaining why is this needed?

I can see the code below, but adding that to the commit message makes it easier
to follow. Also for git history I'd say it's "mandatory".

> 
> Generated-by: Claude AI
> Signed-off-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
> ---
>  playbooks/roles/guestfs/tasks/bringup/extra-disks.yml | 11 ++++++++++-
>  .../roles/guestfs/tasks/bringup/storage-pool-path.yml |  1 +
>  2 files changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/playbooks/roles/guestfs/tasks/bringup/extra-disks.yml b/playbooks/roles/guestfs/tasks/bringup/extra-disks.yml
> index 438b65e..a2a4f84 100644
> --- a/playbooks/roles/guestfs/tasks/bringup/extra-disks.yml
> +++ b/playbooks/roles/guestfs/tasks/bringup/extra-disks.yml
> @@ -9,8 +9,17 @@
>        - "{{ path }}"
>        - "100G"
>  
> -- name: Update the permission settings of the drive image file
> +- name: Update the permission settings of the drive image file (libvirt system uri)
>    ansible.builtin.file:
>      path: "{{ path }}"
>      group: "{{ libvirt_qemu_group }}"
>      mode: "g+rw,o-rw"
> +  when:
> +    - libvirt_uri_system|bool
> +
> +- name: Update the permission settings of the drive image file (libvirt session uri)
> +  ansible.builtin.file:
> +    path: "{{ path }}"
> +    mode: "u+rw,g+r,o-rw"
> +  when:
> +    - not libvirt_uri_system|bool

Do you need o-rw in session mode? And is the group field missing intentional
[1]?

Link: https://docs.ansible.com/ansible/latest/collections/ansible/builtin/file_module.html#parameter-group [1]


> diff --git a/playbooks/roles/guestfs/tasks/bringup/storage-pool-path.yml b/playbooks/roles/guestfs/tasks/bringup/storage-pool-path.yml
> index 385b6cd..7a4bbbc 100644
> --- a/playbooks/roles/guestfs/tasks/bringup/storage-pool-path.yml
> +++ b/playbooks/roles/guestfs/tasks/bringup/storage-pool-path.yml
> @@ -11,6 +11,7 @@
>    ansible.builtin.fail:
>      msg: "Ansible user is not part of the {{ libvirt_qemu_group }} group."
>    when:
> +    - libvirt_uri_system|bool
>      - libvirt_qemu_group not in user_groups
>  
>  - name: Create storage pool path directory (libvirt session uri)

LGTM. With the changes/questions addressed above.

Reviewed-by: Daniel Gomez <da.gomez@samsung.com>

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

[Daniel Gomez]

On 15/08/2025 01.47, Daniel Gomez wrote:
> On 14/08/2025 12.09, Viacheslav Dubeyko wrote:
>> From: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
>>
>> Claude AI helped to make the first kdevops run successful
>> under Fedora Linux 42 (Workstation Edition). This patch
>> contains modifications suggested by Claude AI. It modifies
>> playbooks/roles/guestfs/tasks/bringup/extra-disks.yml and
>> playbooks/roles/guestfs/tasks/bringup/storage-pool-path.yml.
> 
> Can you elaborate the commit message explaining why is this needed?
> 
> I can see the code below, but adding that to the commit message makes it easier
> to follow. Also for git history I'd say it's "mandatory".


I forgot to mention the commit header needs update as well. I'd do something
like:

guestfs: fix bringup libvirt uri permissions

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

[Viacheslav Dubeyko]

On Fri, 2025-08-15 at 10:47 +0200, Daniel Gomez wrote:
> On 14/08/2025 12.09, Viacheslav Dubeyko wrote:
> > From: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
> > 
> > Claude AI helped to make the first kdevops run successful
> > under Fedora Linux 42 (Workstation Edition). This patch
> > contains modifications suggested by Claude AI. It modifies
> > playbooks/roles/guestfs/tasks/bringup/extra-disks.yml and
> > playbooks/roles/guestfs/tasks/bringup/storage-pool-path.yml.
> 
> Can you elaborate the commit message explaining why is this needed?
> 
> I can see the code below, but adding that to the commit message makes
> it easier
> to follow. Also for git history I'd say it's "mandatory".
> 

I have no idea if this modification is necessary or not. :) If you say
that it's complete crap, then I will be completely agreed. :) I simply
tried to make the first run of kdevops during last 1.5 month without
any success. Then, I gave up and I decided to ask Claude to help me.
This stuff has made this modification and I can run kdevops now.

I have no idea what I can add to the commit message. If you would like
to reject the patch, I am completely OK. If you would like to see
another commit message, then I need some help. Because, I have no idea
what this modification is about. :) Welcome to the AI world. :)

Thanks,
Slava.

> > 
> > Generated-by: Claude AI
> > Signed-off-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
> > ---
> >  playbooks/roles/guestfs/tasks/bringup/extra-disks.yml | 11
> > ++++++++++-
> >  .../roles/guestfs/tasks/bringup/storage-pool-path.yml |  1 +
> >  2 files changed, 11 insertions(+), 1 deletion(-)
> > 
> > diff --git a/playbooks/roles/guestfs/tasks/bringup/extra-disks.yml
> > b/playbooks/roles/guestfs/tasks/bringup/extra-disks.yml
> > index 438b65e..a2a4f84 100644
> > --- a/playbooks/roles/guestfs/tasks/bringup/extra-disks.yml
> > +++ b/playbooks/roles/guestfs/tasks/bringup/extra-disks.yml
> > @@ -9,8 +9,17 @@
> >        - "{{ path }}"
> >        - "100G"
> >  
> > -- name: Update the permission settings of the drive image file
> > +- name: Update the permission settings of the drive image file
> > (libvirt system uri)
> >    ansible.builtin.file:
> >      path: "{{ path }}"
> >      group: "{{ libvirt_qemu_group }}"
> >      mode: "g+rw,o-rw"
> > +  when:
> > +    - libvirt_uri_system|bool
> > +
> > +- name: Update the permission settings of the drive image file
> > (libvirt session uri)
> > +  ansible.builtin.file:
> > +    path: "{{ path }}"
> > +    mode: "u+rw,g+r,o-rw"
> > +  when:
> > +    - not libvirt_uri_system|bool
> 
> Do you need o-rw in session mode? And is the group field missing
> intentional
> [1]?
> 
> Link:
> https://docs.ansible.com/ansible/latest/collections/ansible/builtin/file_module.html#parameter-group
>  [1]
> 
> 
> > diff --git a/playbooks/roles/guestfs/tasks/bringup/storage-pool-
> > path.yml b/playbooks/roles/guestfs/tasks/bringup/storage-pool-
> > path.yml
> > index 385b6cd..7a4bbbc 100644
> > --- a/playbooks/roles/guestfs/tasks/bringup/storage-pool-path.yml
> > +++ b/playbooks/roles/guestfs/tasks/bringup/storage-pool-path.yml
> > @@ -11,6 +11,7 @@
> >    ansible.builtin.fail:
> >      msg: "Ansible user is not part of the {{ libvirt_qemu_group }}
> > group."
> >    when:
> > +    - libvirt_uri_system|bool
> >      - libvirt_qemu_group not in user_groups
> >  
> >  - name: Create storage pool path directory (libvirt session uri)
> 
> LGTM. With the changes/questions addressed above.
> 
> Reviewed-by: Daniel Gomez <da.gomez@samsung.com>

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

[Chuck Lever]

On 8/15/25 1:28 PM, Viacheslav Dubeyko wrote:
> On Fri, 2025-08-15 at 10:47 +0200, Daniel Gomez wrote:
>> On 14/08/2025 12.09, Viacheslav Dubeyko wrote:
>>> From: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
>>>
>>> Claude AI helped to make the first kdevops run successful
>>> under Fedora Linux 42 (Workstation Edition). This patch
>>> contains modifications suggested by Claude AI. It modifies
>>> playbooks/roles/guestfs/tasks/bringup/extra-disks.yml and
>>> playbooks/roles/guestfs/tasks/bringup/storage-pool-path.yml.
>>
>> Can you elaborate the commit message explaining why is this needed?
>>
>> I can see the code below, but adding that to the commit message makes
>> it easier
>> to follow. Also for git history I'd say it's "mandatory".
>>
> 
> I have no idea if this modification is necessary or not. :) If you say
> that it's complete crap, then I will be completely agreed. :) I simply
> tried to make the first run of kdevops during last 1.5 month without
> any success. Then, I gave up and I decided to ask Claude to help me.
> This stuff has made this modification and I can run kdevops now.
> 
> I have no idea what I can add to the commit message. If you would like
> to reject the patch, I am completely OK. If you would like to see
> another commit message, then I need some help. Because, I have no idea
> what this modification is about. :) Welcome to the AI world. :)

Hi Viacheslav,

As I mentioned in an earlier response, it's totally possible there is
some incompatibility introduced in Fedora 42.

Although kdevops maintainers are open to taking LLM-generated code, I
think we want human patch submitters to take responsibility for
understanding what they are contributing. If you can't explain or step
up to help fix bugs in your submission, that's OK. A better approach
in that case might be to report the observed breakage here and let us
diagnose it first. When the humans have understood the problem, then we
can agree or disagree whether Claude found a good solution to it.


> Thanks,
> Slava.
> 
>>>
>>> Generated-by: Claude AI
>>> Signed-off-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
>>> ---
>>>  playbooks/roles/guestfs/tasks/bringup/extra-disks.yml | 11
>>> ++++++++++-
>>>  .../roles/guestfs/tasks/bringup/storage-pool-path.yml |  1 +
>>>  2 files changed, 11 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/playbooks/roles/guestfs/tasks/bringup/extra-disks.yml
>>> b/playbooks/roles/guestfs/tasks/bringup/extra-disks.yml
>>> index 438b65e..a2a4f84 100644
>>> --- a/playbooks/roles/guestfs/tasks/bringup/extra-disks.yml
>>> +++ b/playbooks/roles/guestfs/tasks/bringup/extra-disks.yml
>>> @@ -9,8 +9,17 @@
>>>        - "{{ path }}"
>>>        - "100G"
>>>  
>>> -- name: Update the permission settings of the drive image file
>>> +- name: Update the permission settings of the drive image file
>>> (libvirt system uri)
>>>    ansible.builtin.file:
>>>      path: "{{ path }}"
>>>      group: "{{ libvirt_qemu_group }}"
>>>      mode: "g+rw,o-rw"
>>> +  when:
>>> +    - libvirt_uri_system|bool
>>> +
>>> +- name: Update the permission settings of the drive image file
>>> (libvirt session uri)
>>> +  ansible.builtin.file:
>>> +    path: "{{ path }}"
>>> +    mode: "u+rw,g+r,o-rw"
>>> +  when:
>>> +    - not libvirt_uri_system|bool
>>
>> Do you need o-rw in session mode? And is the group field missing
>> intentional
>> [1]?
>>
>> Link:
>> https://docs.ansible.com/ansible/latest/collections/ansible/builtin/file_module.html#parameter-group
>>  [1]
>>
>>
>>> diff --git a/playbooks/roles/guestfs/tasks/bringup/storage-pool-
>>> path.yml b/playbooks/roles/guestfs/tasks/bringup/storage-pool-
>>> path.yml
>>> index 385b6cd..7a4bbbc 100644
>>> --- a/playbooks/roles/guestfs/tasks/bringup/storage-pool-path.yml
>>> +++ b/playbooks/roles/guestfs/tasks/bringup/storage-pool-path.yml
>>> @@ -11,6 +11,7 @@
>>>    ansible.builtin.fail:
>>>      msg: "Ansible user is not part of the {{ libvirt_qemu_group }}
>>> group."
>>>    when:
>>> +    - libvirt_uri_system|bool
>>>      - libvirt_qemu_group not in user_groups
>>>  
>>>  - name: Create storage pool path directory (libvirt session uri)
>>
>> LGTM. With the changes/questions addressed above.
>>
>> Reviewed-by: Daniel Gomez <da.gomez@samsung.com>
> 


-- 
Chuck Lever

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

[Viacheslav Dubeyko]

On Fri, 2025-08-15 at 13:40 -0400, Chuck Lever wrote:
> On 8/15/25 1:28 PM, Viacheslav Dubeyko wrote:
> > On Fri, 2025-08-15 at 10:47 +0200, Daniel Gomez wrote:
> > > On 14/08/2025 12.09, Viacheslav Dubeyko wrote:
> > > > From: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
> > > > 
> > > > Claude AI helped to make the first kdevops run successful
> > > > under Fedora Linux 42 (Workstation Edition). This patch
> > > > contains modifications suggested by Claude AI. It modifies
> > > > playbooks/roles/guestfs/tasks/bringup/extra-disks.yml and
> > > > playbooks/roles/guestfs/tasks/bringup/storage-pool-path.yml.
> > > 
> > > Can you elaborate the commit message explaining why is this needed?
> > > 
> > > I can see the code below, but adding that to the commit message makes
> > > it easier
> > > to follow. Also for git history I'd say it's "mandatory".
> > > 
> > 
> > I have no idea if this modification is necessary or not. :) If you say
> > that it's complete crap, then I will be completely agreed. :) I simply
> > tried to make the first run of kdevops during last 1.5 month without
> > any success. Then, I gave up and I decided to ask Claude to help me.
> > This stuff has made this modification and I can run kdevops now.
> > 
> > I have no idea what I can add to the commit message. If you would like
> > to reject the patch, I am completely OK. If you would like to see
> > another commit message, then I need some help. Because, I have no idea
> > what this modification is about. :) Welcome to the AI world. :)
> 
> Hi Viacheslav,
> 
> As I mentioned in an earlier response, it's totally possible there is
> some incompatibility introduced in Fedora 42.
> 
> Although kdevops maintainers are open to taking LLM-generated code, I
> think we want human patch submitters to take responsibility for
> understanding what they are contributing. If you can't explain or step
> up to help fix bugs in your submission, that's OK. A better approach
> in that case might be to report the observed breakage here and let us
> diagnose it first. When the humans have understood the problem, then we
> can agree or disagree whether Claude found a good solution to it.
> 
> > 

I totally see your point. But it was dozens of various errors that changed every
run. And I was ready to give up. Usually, any project should have some default
state that should work. I have tried Ubuntu, Debian, Fedora and nothing worked.
Does kdevops have very well tested distro version that will 100% work for the
first run. Currently, my impression is that nobody can start kdevops first time
without Claude AI help. :)

Thanks,
Slava.


> > 
> > > > 
> > > > Generated-by: Claude AI
> > > > Signed-off-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
> > > > ---
> > > >  playbooks/roles/guestfs/tasks/bringup/extra-disks.yml | 11
> > > > ++++++++++-
> > > >  .../roles/guestfs/tasks/bringup/storage-pool-path.yml |  1 +
> > > >  2 files changed, 11 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/playbooks/roles/guestfs/tasks/bringup/extra-disks.yml
> > > > b/playbooks/roles/guestfs/tasks/bringup/extra-disks.yml
> > > > index 438b65e..a2a4f84 100644
> > > > --- a/playbooks/roles/guestfs/tasks/bringup/extra-disks.yml
> > > > +++ b/playbooks/roles/guestfs/tasks/bringup/extra-disks.yml
> > > > @@ -9,8 +9,17 @@
> > > >        - "{{ path }}"
> > > >        - "100G"
> > > >  
> > > > -- name: Update the permission settings of the drive image file
> > > > +- name: Update the permission settings of the drive image file
> > > > (libvirt system uri)
> > > >    ansible.builtin.file:
> > > >      path: "{{ path }}"
> > > >      group: "{{ libvirt_qemu_group }}"
> > > >      mode: "g+rw,o-rw"
> > > > +  when:
> > > > +    - libvirt_uri_system|bool
> > > > +
> > > > +- name: Update the permission settings of the drive image file
> > > > (libvirt session uri)
> > > > +  ansible.builtin.file:
> > > > +    path: "{{ path }}"
> > > > +    mode: "u+rw,g+r,o-rw"
> > > > +  when:
> > > > +    - not libvirt_uri_system|bool
> > > 
> > > Do you need o-rw in session mode? And is the group field missing
> > > intentional
> > > [1]?
> > > 
> > > Link:
> > > https://docs.ansible.com/ansible/latest/collections/ansible/builtin/file_module.html#parameter-group  
> > >  [1]
> > > 
> > > 
> > > > diff --git a/playbooks/roles/guestfs/tasks/bringup/storage-pool-
> > > > path.yml b/playbooks/roles/guestfs/tasks/bringup/storage-pool-
> > > > path.yml
> > > > index 385b6cd..7a4bbbc 100644
> > > > --- a/playbooks/roles/guestfs/tasks/bringup/storage-pool-path.yml
> > > > +++ b/playbooks/roles/guestfs/tasks/bringup/storage-pool-path.yml
> > > > @@ -11,6 +11,7 @@
> > > >    ansible.builtin.fail:
> > > >      msg: "Ansible user is not part of the {{ libvirt_qemu_group }}
> > > > group."
> > > >    when:
> > > > +    - libvirt_uri_system|bool
> > > >      - libvirt_qemu_group not in user_groups
> > > >  
> > > >  - name: Create storage pool path directory (libvirt session uri)
> > > 
> > > LGTM. With the changes/questions addressed above.
> > > 
> > > Reviewed-by: Daniel Gomez <da.gomez@samsung.com>
> > 
> 

-- 
Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>

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

[Chuck Lever]

On 8/15/25 2:16 PM, Viacheslav Dubeyko wrote:
> On Fri, 2025-08-15 at 13:40 -0400, Chuck Lever wrote:
>> On 8/15/25 1:28 PM, Viacheslav Dubeyko wrote:
>>> On Fri, 2025-08-15 at 10:47 +0200, Daniel Gomez wrote:
>>>> On 14/08/2025 12.09, Viacheslav Dubeyko wrote:
>>>>> From: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
>>>>>
>>>>> Claude AI helped to make the first kdevops run successful
>>>>> under Fedora Linux 42 (Workstation Edition). This patch
>>>>> contains modifications suggested by Claude AI. It modifies
>>>>> playbooks/roles/guestfs/tasks/bringup/extra-disks.yml and
>>>>> playbooks/roles/guestfs/tasks/bringup/storage-pool-path.yml.
>>>>
>>>> Can you elaborate the commit message explaining why is this needed?
>>>>
>>>> I can see the code below, but adding that to the commit message makes
>>>> it easier
>>>> to follow. Also for git history I'd say it's "mandatory".
>>>>
>>>
>>> I have no idea if this modification is necessary or not. :) If you say
>>> that it's complete crap, then I will be completely agreed. :) I simply
>>> tried to make the first run of kdevops during last 1.5 month without
>>> any success. Then, I gave up and I decided to ask Claude to help me.
>>> This stuff has made this modification and I can run kdevops now.
>>>
>>> I have no idea what I can add to the commit message. If you would like
>>> to reject the patch, I am completely OK. If you would like to see
>>> another commit message, then I need some help. Because, I have no idea
>>> what this modification is about. :) Welcome to the AI world. :)
>>
>> Hi Viacheslav,
>>
>> As I mentioned in an earlier response, it's totally possible there is
>> some incompatibility introduced in Fedora 42.
>>
>> Although kdevops maintainers are open to taking LLM-generated code, I
>> think we want human patch submitters to take responsibility for
>> understanding what they are contributing. If you can't explain or step
>> up to help fix bugs in your submission, that's OK. A better approach
>> in that case might be to report the observed breakage here and let us
>> diagnose it first. When the humans have understood the problem, then we
>> can agree or disagree whether Claude found a good solution to it.
>>
>>>
> 
> I totally see your point. But it was dozens of various errors that changed every
> run. And I was ready to give up. Usually, any project should have some default
> state that should work. I have tried Ubuntu, Debian, Fedora and nothing worked.
> Does kdevops have very well tested distro version that will 100% work for the
> first run. Currently, my impression is that nobody can start kdevops first time
> without Claude AI help. :)

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.

There are a lot of moving parts and it has to work on a lot of different
distros. There's no packaged version of kdevops (yet). I agree that
would be most helpful to have.

Luis and Daniel have, over the past few months, set up a lot of CI for
ensuring that installing kdevops fresh (in some Debian configurations)
will work without a lot of fuss. Then Trixie was released :-(


> Thanks,
> Slava.
> 
> 
>>>
>>>>>
>>>>> Generated-by: Claude AI
>>>>> Signed-off-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
>>>>> ---
>>>>>  playbooks/roles/guestfs/tasks/bringup/extra-disks.yml | 11
>>>>> ++++++++++-
>>>>>  .../roles/guestfs/tasks/bringup/storage-pool-path.yml |  1 +
>>>>>  2 files changed, 11 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/playbooks/roles/guestfs/tasks/bringup/extra-disks.yml
>>>>> b/playbooks/roles/guestfs/tasks/bringup/extra-disks.yml
>>>>> index 438b65e..a2a4f84 100644
>>>>> --- a/playbooks/roles/guestfs/tasks/bringup/extra-disks.yml
>>>>> +++ b/playbooks/roles/guestfs/tasks/bringup/extra-disks.yml
>>>>> @@ -9,8 +9,17 @@
>>>>>        - "{{ path }}"
>>>>>        - "100G"
>>>>>  
>>>>> -- name: Update the permission settings of the drive image file
>>>>> +- name: Update the permission settings of the drive image file
>>>>> (libvirt system uri)
>>>>>    ansible.builtin.file:
>>>>>      path: "{{ path }}"
>>>>>      group: "{{ libvirt_qemu_group }}"
>>>>>      mode: "g+rw,o-rw"
>>>>> +  when:
>>>>> +    - libvirt_uri_system|bool
>>>>> +
>>>>> +- name: Update the permission settings of the drive image file
>>>>> (libvirt session uri)
>>>>> +  ansible.builtin.file:
>>>>> +    path: "{{ path }}"
>>>>> +    mode: "u+rw,g+r,o-rw"
>>>>> +  when:
>>>>> +    - not libvirt_uri_system|bool
>>>>
>>>> Do you need o-rw in session mode? And is the group field missing
>>>> intentional
>>>> [1]?
>>>>
>>>> Link:
>>>> https://docs.ansible.com/ansible/latest/collections/ansible/builtin/file_module.html#parameter-group  
>>>>  [1]
>>>>
>>>>
>>>>> diff --git a/playbooks/roles/guestfs/tasks/bringup/storage-pool-
>>>>> path.yml b/playbooks/roles/guestfs/tasks/bringup/storage-pool-
>>>>> path.yml
>>>>> index 385b6cd..7a4bbbc 100644
>>>>> --- a/playbooks/roles/guestfs/tasks/bringup/storage-pool-path.yml
>>>>> +++ b/playbooks/roles/guestfs/tasks/bringup/storage-pool-path.yml
>>>>> @@ -11,6 +11,7 @@
>>>>>    ansible.builtin.fail:
>>>>>      msg: "Ansible user is not part of the {{ libvirt_qemu_group }}
>>>>> group."
>>>>>    when:
>>>>> +    - libvirt_uri_system|bool
>>>>>      - libvirt_qemu_group not in user_groups
>>>>>  
>>>>>  - name: Create storage pool path directory (libvirt session uri)
>>>>
>>>> LGTM. With the changes/questions addressed above.
>>>>
>>>> Reviewed-by: Daniel Gomez <da.gomez@samsung.com>
>>>
>>
> 


-- 
Chuck Lever

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

[Viacheslav Dubeyko]

On Fri, 2025-08-15 at 14:29 -0400, Chuck Lever wrote:
> On 8/15/25 2:16 PM, Viacheslav Dubeyko wrote:
> > On Fri, 2025-08-15 at 13:40 -0400, Chuck Lever wrote:
> > > On 8/15/25 1:28 PM, Viacheslav Dubeyko wrote:
> > > > On Fri, 2025-08-15 at 10:47 +0200, Daniel Gomez wrote:
> > > > > On 14/08/2025 12.09, Viacheslav Dubeyko wrote:
> > > > > > From: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
> > > > > > 
> > > > > > Claude AI helped to make the first kdevops run successful
> > > > > > under Fedora Linux 42 (Workstation Edition). This patch
> > > > > > contains modifications suggested by Claude AI. It modifies
> > > > > > playbooks/roles/guestfs/tasks/bringup/extra-disks.yml and
> > > > > > playbooks/roles/guestfs/tasks/bringup/storage-pool-path.yml.
> > > > > 
> > > > > Can you elaborate the commit message explaining why is this needed?
> > > > > 
> > > > > I can see the code below, but adding that to the commit message makes
> > > > > it easier
> > > > > to follow. Also for git history I'd say it's "mandatory".
> > > > > 
> > > > 
> > > > I have no idea if this modification is necessary or not. :) If you say
> > > > that it's complete crap, then I will be completely agreed. :) I simply
> > > > tried to make the first run of kdevops during last 1.5 month without
> > > > any success. Then, I gave up and I decided to ask Claude to help me.
> > > > This stuff has made this modification and I can run kdevops now.
> > > > 
> > > > I have no idea what I can add to the commit message. If you would like
> > > > to reject the patch, I am completely OK. If you would like to see
> > > > another commit message, then I need some help. Because, I have no idea
> > > > what this modification is about. :) Welcome to the AI world. :)
> > > 
> > > Hi Viacheslav,
> > > 
> > > As I mentioned in an earlier response, it's totally possible there is
> > > some incompatibility introduced in Fedora 42.
> > > 
> > > Although kdevops maintainers are open to taking LLM-generated code, I
> > > think we want human patch submitters to take responsibility for
> > > understanding what they are contributing. If you can't explain or step
> > > up to help fix bugs in your submission, that's OK. A better approach
> > > in that case might be to report the observed breakage here and let us
> > > diagnose it first. When the humans have understood the problem, then we
> > > can agree or disagree whether Claude found a good solution to it.
> > > 
> > > > 
> > 
> > I totally see your point. But it was dozens of various errors that changed every
> > run. And I was ready to give up. Usually, any project should have some default
> > state that should work. I have tried Ubuntu, Debian, Fedora and nothing worked.
> > Does kdevops have very well tested distro version that will 100% work for the
> > first run. Currently, my impression is that nobody can start kdevops first time
> > without Claude AI help. :)
> 
> 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.
> 
> There are a lot of moving parts and it has to work on a lot of different
> distros. There's no packaged version of kdevops (yet). I agree that
> would be most helpful to have.
> 
> Luis and Daniel have, over the past few months, set up a lot of CI for
> ensuring that installing kdevops fresh (in some Debian configurations)
> will work without a lot of fuss. Then Trixie was released :-(
> 

OK. I see. :)

So, could we make a conclusion does this change makes sense or not? If it makes
sense somehow, then I simply need some help to change the commit message. If we
are not sure about this change, then I am OK to keep this change on my side.
Because, it doesn't look to me like a trivial bug that I can reproduce multiple
times and to check the fix. Probably, I can try but I am still not experienced
user and I am learning how to use the kdevops yet.

Thanks,
Slava.

> > 
> > 
> > > > 
> > > > > > 
> > > > > > Generated-by: Claude AI
> > > > > > Signed-off-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
> > > > > > ---
> > > > > >  playbooks/roles/guestfs/tasks/bringup/extra-disks.yml | 11
> > > > > > ++++++++++-
> > > > > >  .../roles/guestfs/tasks/bringup/storage-pool-path.yml |  1 +
> > > > > >  2 files changed, 11 insertions(+), 1 deletion(-)
> > > > > > 
> > > > > > diff --git a/playbooks/roles/guestfs/tasks/bringup/extra-disks.yml
> > > > > > b/playbooks/roles/guestfs/tasks/bringup/extra-disks.yml
> > > > > > index 438b65e..a2a4f84 100644
> > > > > > --- a/playbooks/roles/guestfs/tasks/bringup/extra-disks.yml
> > > > > > +++ b/playbooks/roles/guestfs/tasks/bringup/extra-disks.yml
> > > > > > @@ -9,8 +9,17 @@
> > > > > >        - "{{ path }}"
> > > > > >        - "100G"
> > > > > >  
> > > > > > -- name: Update the permission settings of the drive image file
> > > > > > +- name: Update the permission settings of the drive image file
> > > > > > (libvirt system uri)
> > > > > >    ansible.builtin.file:
> > > > > >      path: "{{ path }}"
> > > > > >      group: "{{ libvirt_qemu_group }}"
> > > > > >      mode: "g+rw,o-rw"
> > > > > > +  when:
> > > > > > +    - libvirt_uri_system|bool
> > > > > > +
> > > > > > +- name: Update the permission settings of the drive image file
> > > > > > (libvirt session uri)
> > > > > > +  ansible.builtin.file:
> > > > > > +    path: "{{ path }}"
> > > > > > +    mode: "u+rw,g+r,o-rw"
> > > > > > +  when:
> > > > > > +    - not libvirt_uri_system|bool
> > > > > 
> > > > > Do you need o-rw in session mode? And is the group field missing
> > > > > intentional
> > > > > [1]?
> > > > > 
> > > > > Link:
> > > > > https://docs.ansible.com/ansible/latest/collections/ansible/builtin/file_module.html#parameter-group    
> > > > >  [1]
> > > > > 
> > > > > 
> > > > > > diff --git a/playbooks/roles/guestfs/tasks/bringup/storage-pool-
> > > > > > path.yml b/playbooks/roles/guestfs/tasks/bringup/storage-pool-
> > > > > > path.yml
> > > > > > index 385b6cd..7a4bbbc 100644
> > > > > > --- a/playbooks/roles/guestfs/tasks/bringup/storage-pool-path.yml
> > > > > > +++ b/playbooks/roles/guestfs/tasks/bringup/storage-pool-path.yml
> > > > > > @@ -11,6 +11,7 @@
> > > > > >    ansible.builtin.fail:
> > > > > >      msg: "Ansible user is not part of the {{ libvirt_qemu_group }}
> > > > > > group."
> > > > > >    when:
> > > > > > +    - libvirt_uri_system|bool
> > > > > >      - libvirt_qemu_group not in user_groups
> > > > > >  
> > > > > >  - name: Create storage pool path directory (libvirt session uri)
> > > > > 
> > > > > LGTM. With the changes/questions addressed above.
> > > > > 
> > > > > Reviewed-by: Daniel Gomez <da.gomez@samsung.com>
> > > > 
> > > 
> > 
> 

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

[Chuck Lever]

On 8/15/25 2:39 PM, Viacheslav Dubeyko wrote:
> On Fri, 2025-08-15 at 14:29 -0400, Chuck Lever wrote:
>> On 8/15/25 2:16 PM, Viacheslav Dubeyko wrote:
>>> On Fri, 2025-08-15 at 13:40 -0400, Chuck Lever wrote:
>>>> On 8/15/25 1:28 PM, Viacheslav Dubeyko wrote:
>>>>> On Fri, 2025-08-15 at 10:47 +0200, Daniel Gomez wrote:
>>>>>> On 14/08/2025 12.09, Viacheslav Dubeyko wrote:
>>>>>>> From: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
>>>>>>>
>>>>>>> Claude AI helped to make the first kdevops run successful
>>>>>>> under Fedora Linux 42 (Workstation Edition). This patch
>>>>>>> contains modifications suggested by Claude AI. It modifies
>>>>>>> playbooks/roles/guestfs/tasks/bringup/extra-disks.yml and
>>>>>>> playbooks/roles/guestfs/tasks/bringup/storage-pool-path.yml.
>>>>>>
>>>>>> Can you elaborate the commit message explaining why is this needed?
>>>>>>
>>>>>> I can see the code below, but adding that to the commit message makes
>>>>>> it easier
>>>>>> to follow. Also for git history I'd say it's "mandatory".
>>>>>>
>>>>>
>>>>> I have no idea if this modification is necessary or not. :) If you say
>>>>> that it's complete crap, then I will be completely agreed. :) I simply
>>>>> tried to make the first run of kdevops during last 1.5 month without
>>>>> any success. Then, I gave up and I decided to ask Claude to help me.
>>>>> This stuff has made this modification and I can run kdevops now.
>>>>>
>>>>> I have no idea what I can add to the commit message. If you would like
>>>>> to reject the patch, I am completely OK. If you would like to see
>>>>> another commit message, then I need some help. Because, I have no idea
>>>>> what this modification is about. :) Welcome to the AI world. :)
>>>>
>>>> Hi Viacheslav,
>>>>
>>>> As I mentioned in an earlier response, it's totally possible there is
>>>> some incompatibility introduced in Fedora 42.
>>>>
>>>> Although kdevops maintainers are open to taking LLM-generated code, I
>>>> think we want human patch submitters to take responsibility for
>>>> understanding what they are contributing. If you can't explain or step
>>>> up to help fix bugs in your submission, that's OK. A better approach
>>>> in that case might be to report the observed breakage here and let us
>>>> diagnose it first. When the humans have understood the problem, then we
>>>> can agree or disagree whether Claude found a good solution to it.
>>>>
>>>>>
>>>
>>> I totally see your point. But it was dozens of various errors that changed every
>>> run. And I was ready to give up. Usually, any project should have some default
>>> state that should work. I have tried Ubuntu, Debian, Fedora and nothing worked.
>>> Does kdevops have very well tested distro version that will 100% work for the
>>> first run. Currently, my impression is that nobody can start kdevops first time
>>> without Claude AI help. :)
>>
>> 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.
>>
>> There are a lot of moving parts and it has to work on a lot of different
>> distros. There's no packaged version of kdevops (yet). I agree that
>> would be most helpful to have.
>>
>> Luis and Daniel have, over the past few months, set up a lot of CI for
>> ensuring that installing kdevops fresh (in some Debian configurations)
>> will work without a lot of fuss. Then Trixie was released :-(
>>
> 
> OK. I see. :)
> 
> So, could we make a conclusion does this change makes sense or not? If it makes
> sense somehow, then I simply need some help to change the commit message. If we
> are not sure about this change, then I am OK to keep this change on my side.

Until we have a clear problem statement and one of us can try your
patch on a Fedora 42 system, you should keep it private (or simply
wait for us).

I'm hoping to catch up to linux-kdevops/kdevops:main in a week or two.


> Because, it doesn't look to me like a trivial bug that I can reproduce multiple
> times and to check the fix. Probably, I can try but I am still not experienced
> user and I am learning how to use the kdevops yet.
> 
> Thanks,
> Slava.
> 
>>>
>>>
>>>>>
>>>>>>>
>>>>>>> Generated-by: Claude AI
>>>>>>> Signed-off-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
>>>>>>> ---
>>>>>>>  playbooks/roles/guestfs/tasks/bringup/extra-disks.yml | 11
>>>>>>> ++++++++++-
>>>>>>>  .../roles/guestfs/tasks/bringup/storage-pool-path.yml |  1 +
>>>>>>>  2 files changed, 11 insertions(+), 1 deletion(-)
>>>>>>>
>>>>>>> diff --git a/playbooks/roles/guestfs/tasks/bringup/extra-disks.yml
>>>>>>> b/playbooks/roles/guestfs/tasks/bringup/extra-disks.yml
>>>>>>> index 438b65e..a2a4f84 100644
>>>>>>> --- a/playbooks/roles/guestfs/tasks/bringup/extra-disks.yml
>>>>>>> +++ b/playbooks/roles/guestfs/tasks/bringup/extra-disks.yml
>>>>>>> @@ -9,8 +9,17 @@
>>>>>>>        - "{{ path }}"
>>>>>>>        - "100G"
>>>>>>>  
>>>>>>> -- name: Update the permission settings of the drive image file
>>>>>>> +- name: Update the permission settings of the drive image file
>>>>>>> (libvirt system uri)
>>>>>>>    ansible.builtin.file:
>>>>>>>      path: "{{ path }}"
>>>>>>>      group: "{{ libvirt_qemu_group }}"
>>>>>>>      mode: "g+rw,o-rw"
>>>>>>> +  when:
>>>>>>> +    - libvirt_uri_system|bool
>>>>>>> +
>>>>>>> +- name: Update the permission settings of the drive image file
>>>>>>> (libvirt session uri)
>>>>>>> +  ansible.builtin.file:
>>>>>>> +    path: "{{ path }}"
>>>>>>> +    mode: "u+rw,g+r,o-rw"
>>>>>>> +  when:
>>>>>>> +    - not libvirt_uri_system|bool
>>>>>>
>>>>>> Do you need o-rw in session mode? And is the group field missing
>>>>>> intentional
>>>>>> [1]?
>>>>>>
>>>>>> Link:
>>>>>> https://docs.ansible.com/ansible/latest/collections/ansible/builtin/file_module.html#parameter-group    
>>>>>>  [1]
>>>>>>
>>>>>>
>>>>>>> diff --git a/playbooks/roles/guestfs/tasks/bringup/storage-pool-
>>>>>>> path.yml b/playbooks/roles/guestfs/tasks/bringup/storage-pool-
>>>>>>> path.yml
>>>>>>> index 385b6cd..7a4bbbc 100644
>>>>>>> --- a/playbooks/roles/guestfs/tasks/bringup/storage-pool-path.yml
>>>>>>> +++ b/playbooks/roles/guestfs/tasks/bringup/storage-pool-path.yml
>>>>>>> @@ -11,6 +11,7 @@
>>>>>>>    ansible.builtin.fail:
>>>>>>>      msg: "Ansible user is not part of the {{ libvirt_qemu_group }}
>>>>>>> group."
>>>>>>>    when:
>>>>>>> +    - libvirt_uri_system|bool
>>>>>>>      - libvirt_qemu_group not in user_groups
>>>>>>>  
>>>>>>>  - name: Create storage pool path directory (libvirt session uri)
>>>>>>
>>>>>> LGTM. With the changes/questions addressed above.
>>>>>>
>>>>>> Reviewed-by: Daniel Gomez <da.gomez@samsung.com>
>>>>>
>>>>
>>>
>>


-- 
Chuck Lever

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

[Luis Chamberlain]

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?

  Luis

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

[Daniel Gomez]

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

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

[Chuck Lever]

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

+1 (or more). A sleeker security profile would do wonders for kdevops
adoption.

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.


> * Remove/optional wide host configuration: basically sandboxing kdevops
> 	* systemd services
> 	* SSH configurations
> 	* libvirt configs

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.

ssh is a whole different problem ;-/


-- 
Chuck Lever

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

[Luis Chamberlain]

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.

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

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

What about ssh configurations do we need to review? Perhaps to not
require passwordless sudo?

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

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

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

[Daniel Gomez]

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

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

[Luis Chamberlain]

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?

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

> > 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? I think such a thing could optional.
Or is it just that cloud needs to move over to use that too?

  Luis

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

[Daniel Gomez]

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

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

[Luis Chamberlain]

On Mon, Aug 25, 2025 at 02:16:31PM +0200, Daniel Gomez wrote:
> 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.

I suspect disabled is best for simplcity, its still the enabling that's hard.

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

I think I like the below better because not everyone will want the mirror.

> or:
> kdevops-systemd-mirror

This I think is mostly a user thing, but NFS mirroring is not.

> kdevops-systemd-timesyncd

Not sure how this can be user based.

> ...

Did we miss any other? Oh yeah the systemd remote journal. I think that
can't be user based either.

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

I am not sure if we have any systemd user service we can use?

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

At least my Lambda labs implementation uses something like the above,
but I could not sure of the other clouds.

  Luis

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

[Chuck Lever]

On 8/23/25 8:33 AM, Daniel Gomez wrote:
> 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?

I'm going to explain with RPM here because I'm a Red Hat junkie.

The idea would be that much of the FIRST_RUN stuff could be handled by
scriptlets in an RPM. A post_install scriptlet could manufacture a
.config and run "make" (as long as no human interaction is required).

Then ensure that installation of distro-packaged dependencies on the
controller host that are needed for controller activities is done by the
RPM rather than being pulled in as needed via Ansible playbooks. (But
let's continue to use Ansible to install on target nodes).

We can automate the construction of the RPM by including spec files in
the kdevops source tree, and then have a GitHub Action (perhaps written
by an AI) that whips up the RPM on every push to "main".

Packaging means we can take some of the per-distribution configuration
problem areas and handle them with RPM scriptlets instead of cluttering
the kdevops Ansible playbooks.

"rpm -ivh kdevops.rpm" is done by root, so that would eliminate some of
the need to boost privilege on the controller during normal operation.
Plus I feel that packaged installation can be tested with automation
more easily.

For example, the fstests_prep_localhost playbook might be one area that
could be moved to an RPM scriptlet. (I haven't looked closely at what
that playbook does; I just know it needs sudo).

So then installing kdevops for users would look more like the usual
process:

 # download kdevops.rpm
 # rpm -ivh kdevops.rpm

And then we hopefully have something that is more reliable for those
who are not kdevops developers


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

What might be an option for some services is to create additional
guests that handle these services instead of instantiating them on
the controller host. This would also enable those services to be
provisioned in the cloud the same way they are provisioned for
guestfs-based kdevops deployments.


-- 
Chuck Lever

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

[Luis Chamberlain]

On Sun, Aug 24, 2025 at 01:00:31PM -0400, Chuck Lever wrote:
> On 8/23/25 8:33 AM, Daniel Gomez wrote:
> > I'm not sure what would be packed in that
> > RPM/deb file. Just the runtime dependencies kdevops depends on?
> 
> I'm going to explain with RPM here because I'm a Red Hat junkie.
> 
> The idea would be that much of the FIRST_RUN stuff could be handled by
> scriptlets in an RPM. A post_install scriptlet could manufacture a
> .config and run "make" (as long as no human interaction is required).
> 
> Then ensure that installation of distro-packaged dependencies on the
> controller host that are needed for controller activities is done by the
> RPM rather than being pulled in as needed via Ansible playbooks. (But
> let's continue to use Ansible to install on target nodes).
> 
> We can automate the construction of the RPM by including spec files in
> the kdevops source tree, and then have a GitHub Action (perhaps written
> by an AI) that whips up the RPM on every push to "main".
> 
> Packaging means we can take some of the per-distribution configuration
> problem areas and handle them with RPM scriptlets instead of cluttering
> the kdevops Ansible playbooks.

The more I think about this, the more I think this solves ths issues
with FIRST_RUN bussines. It just becomes:

apt-get install kdevops
yum install kdevops

Then if they want to run the bleeding edge, its all ready anyway.

That puts the onus on us to do defatult security vetting / apparmor
work. But that's all doable, now with AI.

> What might be an option for some services is to create additional
> guests that handle these services instead of instantiating them on
> the controller host. This would also enable those services to be
> provisioned in the cloud the same way they are provisioned for
> guestfs-based kdevops deployments.

This sounds *super* attractive from an architectural perspective.
So I'm in agreemen it would be nice. But from a practical perspective
kdevops instances to me are specific to directories / workspaces I work
with and I simply destroy them after I'm done with a subject. That would
mean I'd have to share guests between workloads and that complicates
things for virtualization. Also, for low end devices like a laptop, spawning
an extra guest just for services is a bit too high price to pay.

So I think this isn't practical for virtualization solutions.

I think its more reasoanble to just advocate we disable these systemd
services by default. And those who have an extra ~/.config/kdevops/fragments/all 
can simply reap the merge_config benefits of always having them on.

Thoughts?

  Luis