LSF/MM/BPF BoF: pains / goods with automation with kdevops

LSF/MM/BPF BoF: pains / goods with automation with kdevops

[Luis Chamberlain]

More suitable towards a BoF as I don't *think* a larger audience would be
interested. At the last LSF during our talks about automation it was suggested
we could share a repo and go to town as we're all adults. That's been done:

https://github.com/linux-kdevops/kdevops

At ALPSS folks suggested maybe non-github, best we can do for now is
gitlab:

https://gitlab.com/linux-kdevops/kdevops

There's been quite a bit of development from folks on the To list. But
there's also bugs even on the upstream kernel now that can sometimes erk us.
One example is 9p is now used to be able to compile Linux on the host
instead of the guests. Well if you edit a file after boot on the host
for Linux, the guest won't see the update, so I guess 9p doesn't update
the guest's copy yet. Guests just have to reboot now. So we have to fix that
and I guess add 9p to fstests. Or now that we have NFS support thanks to
Jeff, maybe use that as an option? What's the overhead for automation Vs 9p?

We dicussed sharing more archive of results for fstests/blktests. Done.
What are the other developer's pain points? What would folks like? If
folks want demos for complex setups let me know and we can just do that
through zoom and record them / publish online to help as documentation
(please reply to this thread in private to me and I can set up a
session). Let's use the time at LSF more for figuring out what is needed
for the next year.

  Luis

Re: LSF/MM/BPF BoF: pains / goods with automation with kdevops

[Jeff Layton]

On Sat, 2023-01-28 at 21:34 -0800, Luis Chamberlain wrote:
> More suitable towards a BoF as I don't *think* a larger audience would be
> interested. At the last LSF during our talks about automation it was suggested
> we could share a repo and go to town as we're all adults. That's been done:
> 
> https://github.com/linux-kdevops/kdevops
> 
> At ALPSS folks suggested maybe non-github, best we can do for now is
> gitlab:
> 
> https://gitlab.com/linux-kdevops/kdevops
> 
> There's been quite a bit of development from folks on the To list. But
> there's also bugs even on the upstream kernel now that can sometimes erk us.
> One example is 9p is now used to be able to compile Linux on the host
> instead of the guests. Well if you edit a file after boot on the host
> for Linux, the guest won't see the update, so I guess 9p doesn't update
> the guest's copy yet. Guests just have to reboot now. So we have to fix that
> and I guess add 9p to fstests. Or now that we have NFS support thanks to
> Jeff, maybe use that as an option? What's the overhead for automation Vs 9p?
> 
> We dicussed sharing more archive of results for fstests/blktests. Done.
> What are the other developer's pain points? What would folks like? If
> folks want demos for complex setups let me know and we can just do that
> through zoom and record them / publish online to help as documentation
> (please reply to this thread in private to me and I can set up a
> session). Let's use the time at LSF more for figuring out what is needed
> for the next year.
> 
>   Luis

Luis mentioned that no one had replied to this expressing interest. I'm
definitely interested in discussing kdevops if the schedule's not
already full.
-- 
Jeff Layton <jlayton@kernel.org>

Re: LSF/MM/BPF BoF: pains / goods with automation with kdevops

[Adam Manzanares]

On Wed, May 03, 2023 at 04:02:26PM -0400, Jeff Layton wrote:
> On Sat, 2023-01-28 at 21:34 -0800, Luis Chamberlain wrote:
> > More suitable towards a BoF as I don't *think* a larger audience would be
> > interested. At the last LSF during our talks about automation it was suggested
> > we could share a repo and go to town as we're all adults. That's been done:
> > 
> > https://urldefense.com/v3/__https://protect2.fireeye.com/v1/url?k=a83af7a2-f7a1cec7-a83b7ced-000babff32e3-f8d68746f8f1175e&q=1&e=f2f6f708-e4a4-4976-bd4f-5faebd8f572c&u=https*3A*2F*2Fgithub.com*2Flinux-kdevops*2Fkdevops__;JSUlJSU!!EwVzqGoTKBqv-0DWAJBm!Ton7OdUx1HbmbleyTg_Qx_6ZjiVDqNkYaXn6cWoJHlqUeQpwcbBsUot5meY3ylHMj0cnj4kBWKKYM-Yq9ZOLLA$ 
> > 
> > At ALPSS folks suggested maybe non-github, best we can do for now is
> > gitlab:
> > 
> > https://urldefense.com/v3/__https://gitlab.com/linux-kdevops/kdevops__;!!EwVzqGoTKBqv-0DWAJBm!Ton7OdUx1HbmbleyTg_Qx_6ZjiVDqNkYaXn6cWoJHlqUeQpwcbBsUot5meY3ylHMj0cnj4kBWKKYM-a0CMLpjQ$ 
> > 
> > There's been quite a bit of development from folks on the To list. But
> > there's also bugs even on the upstream kernel now that can sometimes erk us.
> > One example is 9p is now used to be able to compile Linux on the host
> > instead of the guests. Well if you edit a file after boot on the host
> > for Linux, the guest won't see the update, so I guess 9p doesn't update
> > the guest's copy yet. Guests just have to reboot now. So we have to fix that
> > and I guess add 9p to fstests. Or now that we have NFS support thanks to
> > Jeff, maybe use that as an option? What's the overhead for automation Vs 9p?
> > 
> > We dicussed sharing more archive of results for fstests/blktests. Done.
> > What are the other developer's pain points? What would folks like? If
> > folks want demos for complex setups let me know and we can just do that
> > through zoom and record them / publish online to help as documentation
> > (please reply to this thread in private to me and I can set up a
> > session). Let's use the time at LSF more for figuring out what is needed
> > for the next year.
> > 
> >   Luis
> 
> Luis mentioned that no one had replied to this expressing interest. I'm
> definitely interested in discussing kdevops if the schedule's not
> already full.

+1 for me as well. 

> -- 
> Jeff Layton <jlayton@kernel.org>

Re: LSF/MM/BPF BoF: pains / goods with automation with kdevops

[Amir Goldstein]

On Wed, May 3, 2023 at 11:02 PM Jeff Layton <jlayton@kernel.org> wrote:
>
> On Sat, 2023-01-28 at 21:34 -0800, Luis Chamberlain wrote:
> > More suitable towards a BoF as I don't *think* a larger audience would be
> > interested. At the last LSF during our talks about automation it was suggested
> > we could share a repo and go to town as we're all adults. That's been done:
> >
> > https://github.com/linux-kdevops/kdevops
> >
> > At ALPSS folks suggested maybe non-github, best we can do for now is
> > gitlab:
> >
> > https://gitlab.com/linux-kdevops/kdevops
> >
> > There's been quite a bit of development from folks on the To list. But
> > there's also bugs even on the upstream kernel now that can sometimes erk us.
> > One example is 9p is now used to be able to compile Linux on the host
> > instead of the guests. Well if you edit a file after boot on the host
> > for Linux, the guest won't see the update, so I guess 9p doesn't update
> > the guest's copy yet. Guests just have to reboot now. So we have to fix that
> > and I guess add 9p to fstests. Or now that we have NFS support thanks to
> > Jeff, maybe use that as an option? What's the overhead for automation Vs 9p?
> >
> > We dicussed sharing more archive of results for fstests/blktests. Done.
> > What are the other developer's pain points? What would folks like? If
> > folks want demos for complex setups let me know and we can just do that
> > through zoom and record them / publish online to help as documentation
> > (please reply to this thread in private to me and I can set up a
> > session). Let's use the time at LSF more for figuring out what is needed
> > for the next year.
> >
> >   Luis
>
> Luis mentioned that no one had replied to this expressing interest. I'm
> definitely interested in discussing kdevops if the schedule's not
> already full.

No worries.
It's already on the schedule, which btw, is now available on the website:
https://events.linuxfoundation.org/lsfmm/

It's a cross FS-IO session, but I see that MM also left this slot clean.
Not sure if they have interest in kdevops as well?
If so, I can make it official FS-IO-MM.

Thanks,
Amir.