Moving lava-docker out of the KernelCI GitHub organisation

Moving lava-docker out of the KernelCI GitHub organisation

[Guillaume Tucker]

Hello,

The idea of adding BayLibre's lava-healthchecks-binary[1]
repository to the KernelCI GitHub organisation was brought up
during a KernelCI weekly meeting last month.  This appears to be
related to the lava-docker[2] project which is currently in the
KernelCI organisation, to bring the two repositories together.

It seems to me that lava-docker and anything related to providing
LAVA support is not something that KernelCI should be responsible
for as a project.  In fact, the lava-docker repository has been
managed entirely autonomously since the beginning by different
maintainers than the core KernelCI repositories, and I believe it
was originally added to the KernelCI org by Kevin as it was an
easy thing to do that made sense at the time.

Rather than having one more LAVA-related project under this org,
how about either creating a dedicated GitHub organisation for
lava-docker and related repositories, or adding lava-docker and
the healthchecks to the LAVA GitLab instance on
https://git.lavasoftware.org/?

Having a dedicated org on GitHub would give the actual
maintainers of the project full control over it, to add and move
repositories, manage members, permissions etc. as they wish.

However, if the LAVA maintainers think that lava-docker could
become the main solution for running LAVA in Docker, then maybe
it should be merged with some existing project on
git.lavasoftware.org or added as a new project there.  That would
give it more visibility and potentially remove duplicated
efforts.

I'm not sure I'm aware of all the implications for each of these
options so I thought I would bring it up for discussion here.
What do you think?


Thanks,
Guillaume

[1] https://github.com/BayLibre/lava-healthchecks-binary
[2] https://github.com/kernelci/lava-docker

Re: Moving lava-docker out of the KernelCI GitHub organisation

[Alice Ferrazzi]

Hello Guillaume,

On Thu, Aug 25, 2022 at 11:05 PM Guillaume Tucker
<guillaume.tucker@collabora.com> wrote:
>
> Hello,
>
> The idea of adding BayLibre's lava-healthchecks-binary[1]
> repository to the KernelCI GitHub organisation was brought up
> during a KernelCI weekly meeting last month.  This appears to be
> related to the lava-docker[2] project which is currently in the
> KernelCI organisation, to bring the two repositories together.

That's was because I was trying to solve a problem with
lava-healthckecks-binary,
by creating a new format for managing multiple healthcheck binary
automatically instead of statically
moving such binary from the Dockerfile one by one.
Done by the following pull request (
https://github.com/kernelci/lava-docker/pull/154 ) that is creating a
new healthcheck-binary repository format that can give the possibility
to easily manage multiple lava-healthckecks-binary binary and giving
the possibility to easily fork the repository with new binaries but
still keeping the compatibility with lava-docker.
I also sended a pull request to lava-healthckecks-binary
https://github.com/BayLibre/lava-healthchecks-binary/pull/1
but as lava-healthckecks-binary looks only partially maintained, that
was the reason of why I asked if we could maintain
lava-healthckecks-binary under kernelci, togheter with lava-docker for
better maintaining and keeping maintained lava-docker and lava-docker
related repositories.

>
> It seems to me that lava-docker and anything related to providing
> LAVA support is not something that KernelCI should be responsible
> for as a project.  In fact, the lava-docker repository has been
> managed entirely autonomously since the beginning by different
> maintainers than the core KernelCI repositories, and I believe it
> was originally added to the KernelCI org by Kevin as it was an
> easy thing to do that made sense at the time.

lava-docker is still documented in the KernelCI TSC documentation
https://kernelci.org/docs/org/tsc/#lava-docker and currently lava is
the only documented working laboratory in the KernelCI documentation.
https://kernelci.org/docs/labs/
That would suggest to me that is currently to early for making
KernelCI currently main laboratory system easy orchestration
implementation (lava-docker) depart from KernelCI organization. As
discussed during the recent KernelCI weekly meeting.

>
> Rather than having one more LAVA-related project under this org,
> how about either creating a dedicated GitHub organisation for
> lava-docker and related repositories, or adding lava-docker and
> the healthchecks to the LAVA GitLab instance on
> https://git.lavasoftware.org/?
>
> Having a dedicated org on GitHub would give the actual
> maintainers of the project full control over it, to add and move
> repositories, manage members, permissions etc. as they wish.
>
> However, if the LAVA maintainers think that lava-docker could
> become the main solution for running LAVA in Docker, then maybe
> it should be merged with some existing project on
> git.lavasoftware.org or added as a new project there.  That would
> give it more visibility and potentially remove duplicated
> efforts.
>
> I'm not sure I'm aware of all the implications for each of these
> options so I thought I would bring it up for discussion here.
> What do you think?

if we decide to move lava-docker to is own organization or to
git.lavasoftware.org,
I would like to propose to having KernelCI writing a news about the
decision for enabling the currently users of lava-docker to move to
the new upstream version and make it clear that lava-docker will be
still maintained under the new organization and suggested by KernelCI.
As discussed during the recent KernelCI weekly meeting.

Thanks,
Alice
-- 
======================================
Cybertrust Japan Co.,Ltd.
Alice Ferrazzi
alice.ferrazzi@miraclelinux.com
======================================

Re: Moving lava-docker out of the KernelCI GitHub organisation

[Antonio Terceiro]

[-- Attachment #1: Type: text/plain, Size: 2477 bytes --]

On Thu, Aug 25, 2022 at 04:05:47PM +0200, Guillaume Tucker wrote:
> Hello,
> 
> The idea of adding BayLibre's lava-healthchecks-binary[1]
> repository to the KernelCI GitHub organisation was brought up
> during a KernelCI weekly meeting last month.  This appears to be
> related to the lava-docker[2] project which is currently in the
> KernelCI organisation, to bring the two repositories together.
> 
> It seems to me that lava-docker and anything related to providing
> LAVA support is not something that KernelCI should be responsible
> for as a project.  In fact, the lava-docker repository has been
> managed entirely autonomously since the beginning by different
> maintainers than the core KernelCI repositories, and I believe it
> was originally added to the KernelCI org by Kevin as it was an
> easy thing to do that made sense at the time.
> 
> Rather than having one more LAVA-related project under this org,
> how about either creating a dedicated GitHub organisation for
> lava-docker and related repositories, or adding lava-docker and
> the healthchecks to the LAVA GitLab instance on
> https://git.lavasoftware.org/?
> 
> Having a dedicated org on GitHub would give the actual
> maintainers of the project full control over it, to add and move
> repositories, manage members, permissions etc. as they wish.
> 
> However, if the LAVA maintainers think that lava-docker could
> become the main solution for running LAVA in Docker, then maybe
> it should be merged with some existing project on
> git.lavasoftware.org or added as a new project there.  That would
> give it more visibility and potentially remove duplicated
> efforts.

FWIW, there is also
https://git.lavasoftware.org/lava/pkg/docker-compose which seems
similar, but not the same, as kernelci's lava-docker (e.g. there is no
autogeneration of config files AFAICT). That's used by a few people, but
mostly for development purposes I think.

> I'm not sure I'm aware of all the implications for each of these
> options so I thought I would bring it up for discussion here.
> What do you think?

I don't really have an opinion on what to do with lava-docker. In
principle, consolidation and collaboration is good, but we would need to
agree on the details. Also, moving it around must be done in a way that
the current maintainers still have the necessary access to keep
maintaining it (because the move won't make new maintainers magically
appear).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Moving lava-docker out of the KernelCI GitHub organisation

[Alice Ferrazzi]

Hello Antonio,

On Sat, Aug 27, 2022 at 3:40 AM Antonio Terceiro
<antonio.terceiro@linaro.org> wrote:
>
> On Thu, Aug 25, 2022 at 04:05:47PM +0200, Guillaume Tucker wrote:
> > Hello,
> >
> > The idea of adding BayLibre's lava-healthchecks-binary[1]
> > repository to the KernelCI GitHub organisation was brought up
> > during a KernelCI weekly meeting last month.  This appears to be
> > related to the lava-docker[2] project which is currently in the
> > KernelCI organisation, to bring the two repositories together.
> >
> > It seems to me that lava-docker and anything related to providing
> > LAVA support is not something that KernelCI should be responsible
> > for as a project.  In fact, the lava-docker repository has been
> > managed entirely autonomously since the beginning by different
> > maintainers than the core KernelCI repositories, and I believe it
> > was originally added to the KernelCI org by Kevin as it was an
> > easy thing to do that made sense at the time.
> >
> > Rather than having one more LAVA-related project under this org,
> > how about either creating a dedicated GitHub organisation for
> > lava-docker and related repositories, or adding lava-docker and
> > the healthchecks to the LAVA GitLab instance on
> > https://git.lavasoftware.org/?
> >
> > Having a dedicated org on GitHub would give the actual
> > maintainers of the project full control over it, to add and move
> > repositories, manage members, permissions etc. as they wish.
> >
> > However, if the LAVA maintainers think that lava-docker could
> > become the main solution for running LAVA in Docker, then maybe
> > it should be merged with some existing project on
> > git.lavasoftware.org or added as a new project there.  That would
> > give it more visibility and potentially remove duplicated
> > efforts.
>
> FWIW, there is also
> https://git.lavasoftware.org/lava/pkg/docker-compose which seems
> similar, but not the same, as kernelci's lava-docker (e.g. there is no
> autogeneration of config files AFAICT). That's used by a few people, but
> mostly for development purposes I think.
>

yes, from what I could see is a different approach.
We are offering a orchestration system that is generated
programmatically by a yaml file (boards.yaml)
that is creating the necessary docker-compose settings and unloading
the already set up lava
files and folders.

> > I'm not sure I'm aware of all the implications for each of these
> > options so I thought I would bring it up for discussion here.
> > What do you think?
>
> I don't really have an opinion on what to do with lava-docker. In
> principle, consolidation and collaboration is good, but we would need to
> agree on the details. Also, moving it around must be done in a way that
> the current maintainers still have the necessary access to keep
> maintaining it (because the move won't make new maintainers magically
> appear).

I agree on doing it in a way that the current maintainers have still
the necessary access rights for continue
the development,
I also would like to do it in a way that the current lava-docker users
don't get confused on
where the upstream repository moved to.

Thanks,
Alice
-- 
======================================
Cybertrust Japan Co.,Ltd.
Alice Ferrazzi
alice.ferrazzi@miraclelinux.com
======================================

Re: Moving lava-docker out of the KernelCI GitHub organisation

[Remi Duraffort]

Hello,

Le lun. 29 août 2022 à 08:18, Alice Ferrazzi <
alice.ferrazzi@miraclelinux.com> a écrit :

> Hello Antonio,
>
> On Sat, Aug 27, 2022 at 3:40 AM Antonio Terceiro
> <antonio.terceiro@linaro.org> wrote:
> >
> > On Thu, Aug 25, 2022 at 04:05:47PM +0200, Guillaume Tucker wrote:
> > > Hello,
> > >
> > > The idea of adding BayLibre's lava-healthchecks-binary[1]
> > > repository to the KernelCI GitHub organisation was brought up
> > > during a KernelCI weekly meeting last month.  This appears to be
> > > related to the lava-docker[2] project which is currently in the
> > > KernelCI organisation, to bring the two repositories together.
> > >
> > > It seems to me that lava-docker and anything related to providing
> > > LAVA support is not something that KernelCI should be responsible
> > > for as a project.  In fact, the lava-docker repository has been
> > > managed entirely autonomously since the beginning by different
> > > maintainers than the core KernelCI repositories, and I believe it
> > > was originally added to the KernelCI org by Kevin as it was an
> > > easy thing to do that made sense at the time.
> > >
> > > Rather than having one more LAVA-related project under this org,
> > > how about either creating a dedicated GitHub organisation for
> > > lava-docker and related repositories, or adding lava-docker and
> > > the healthchecks to the LAVA GitLab instance on
> > > https://git.lavasoftware.org/?
> > >
> > > Having a dedicated org on GitHub would give the actual
> > > maintainers of the project full control over it, to add and move
> > > repositories, manage members, permissions etc. as they wish.
> > >
> > > However, if the LAVA maintainers think that lava-docker could
> > > become the main solution for running LAVA in Docker, then maybe
> > > it should be merged with some existing project on
> > > git.lavasoftware.org or added as a new project there.  That would
> > > give it more visibility and potentially remove duplicated
> > > efforts.
> >
> > FWIW, there is also
> > https://git.lavasoftware.org/lava/pkg/docker-compose which seems
> > similar, but not the same, as kernelci's lava-docker (e.g. there is no
> > autogeneration of config files AFAICT). That's used by a few people, but
> > mostly for development purposes I think.
> >
>
> yes, from what I could see is a different approach.
> We are offering a orchestration system that is generated
> programmatically by a yaml file (boards.yaml)
> that is creating the necessary docker-compose settings and unloading
> the already set up lava
> files and folders.
>
> > > I'm not sure I'm aware of all the implications for each of these
> > > options so I thought I would bring it up for discussion here.
> > > What do you think?
> >
> > I don't really have an opinion on what to do with lava-docker. In
> > principle, consolidation and collaboration is good, but we would need to
> > agree on the details. Also, moving it around must be done in a way that
> > the current maintainers still have the necessary access to keep
> > maintaining it (because the move won't make new maintainers magically
> > appear).
>
> I agree on doing it in a way that the current maintainers have still
> the necessary access rights for continue
> the development,
> I also would like to do it in a way that the current lava-docker users
> don't get confused on
> where the upstream repository moved to.
>
> Thanks,
> Alice
> --
> ======================================
> Cybertrust Japan Co.,Ltd.
> Alice Ferrazzi
> alice.ferrazzi@miraclelinux.com
> ======================================
>

With Antonio we agreed that we can host the lava-docker project along with
lava if that's what the maintainers want.
But keep in mind that we (Antonio and myself) don't have time to make any
changes/maintenance on this project. If lava-docker is moved into the lava
namespace, maybe the project should be documented into the lava official
documentation.

We are planning to migrate the lava project from a self-hosted gitlab
instance to the gitlab.com instance soon. If lava-docker is moved into the
lava namespace it would be better to wait for the migration to gitlab.com
(to avoid two migrations).


Rgds

-- 
Rémi Duraffort
LAVA and Tux Architect
Linaro

Re: Moving lava-docker out of the KernelCI GitHub organisation

[Alice Ferrazzi]

On Thu, Sep 1, 2022 at 11:56 PM Remi Duraffort <remi.duraffort@linaro.org>
wrote:
>
> Hello,
>
> Le lun. 29 août 2022 à 08:18, Alice Ferrazzi <
alice.ferrazzi@miraclelinux.com> a écrit :
>>
>> Hello Antonio,
>>
>> On Sat, Aug 27, 2022 at 3:40 AM Antonio Terceiro
>> <antonio.terceiro@linaro.org> wrote:
>> >
>> > On Thu, Aug 25, 2022 at 04:05:47PM +0200, Guillaume Tucker wrote:
>> > > Hello,
>> > >
>> > > The idea of adding BayLibre's lava-healthchecks-binary[1]
>> > > repository to the KernelCI GitHub organisation was brought up
>> > > during a KernelCI weekly meeting last month.  This appears to be
>> > > related to the lava-docker[2] project which is currently in the
>> > > KernelCI organisation, to bring the two repositories together.
>> > >
>> > > It seems to me that lava-docker and anything related to providing
>> > > LAVA support is not something that KernelCI should be responsible
>> > > for as a project.  In fact, the lava-docker repository has been
>> > > managed entirely autonomously since the beginning by different
>> > > maintainers than the core KernelCI repositories, and I believe it
>> > > was originally added to the KernelCI org by Kevin as it was an
>> > > easy thing to do that made sense at the time.
>> > >
>> > > Rather than having one more LAVA-related project under this org,
>> > > how about either creating a dedicated GitHub organisation for
>> > > lava-docker and related repositories, or adding lava-docker and
>> > > the healthchecks to the LAVA GitLab instance on
>> > > https://git.lavasoftware.org/?
>> > >
>> > > Having a dedicated org on GitHub would give the actual
>> > > maintainers of the project full control over it, to add and move
>> > > repositories, manage members, permissions etc. as they wish.
>> > >
>> > > However, if the LAVA maintainers think that lava-docker could
>> > > become the main solution for running LAVA in Docker, then maybe
>> > > it should be merged with some existing project on
>> > > git.lavasoftware.org or added as a new project there.  That would
>> > > give it more visibility and potentially remove duplicated
>> > > efforts.
>> >
>> > FWIW, there is also
>> > https://git.lavasoftware.org/lava/pkg/docker-compose which seems
>> > similar, but not the same, as kernelci's lava-docker (e.g. there is no
>> > autogeneration of config files AFAICT). That's used by a few people,
but
>> > mostly for development purposes I think.
>> >
>>
>> yes, from what I could see is a different approach.
>> We are offering a orchestration system that is generated
>> programmatically by a yaml file (boards.yaml)
>> that is creating the necessary docker-compose settings and unloading
>> the already set up lava
>> files and folders.
>>
>> > > I'm not sure I'm aware of all the implications for each of these
>> > > options so I thought I would bring it up for discussion here.
>> > > What do you think?
>> >
>> > I don't really have an opinion on what to do with lava-docker. In
>> > principle, consolidation and collaboration is good, but we would need
to
>> > agree on the details. Also, moving it around must be done in a way that
>> > the current maintainers still have the necessary access to keep
>> > maintaining it (because the move won't make new maintainers magically
>> > appear).
>>
>> I agree on doing it in a way that the current maintainers have still
>> the necessary access rights for continue
>> the development,
>> I also would like to do it in a way that the current lava-docker users
>> don't get confused on
>> where the upstream repository moved to.
>>
>> Thanks,
>> Alice
>> --
>> ======================================
>> Cybertrust Japan Co.,Ltd.
>> Alice Ferrazzi
>> alice.ferrazzi@miraclelinux.com
>> ======================================
>
>
> With Antonio we agreed that we can host the lava-docker project along
with lava if that's what the maintainers want.
> But keep in mind that we (Antonio and myself) don't have time to make any
changes/maintenance on this project. If lava-docker is moved into the lava
namespace, maybe the project should be documented into the lava official
documentation.
>
> We are planning to migrate the lava project from a self-hosted gitlab
instance to the gitlab.com instance soon. If lava-docker is moved into the
lava namespace it would be better to wait for the migration to gitlab.com
(to avoid two migrations).
>

I think is good to keep the current lava-docker KernelCI TSC maintainer as
main maintainer of the new repository (me and montjoie).
https://kernelci.org/docs/org/tsc/#lava-docker
I will help on the maintenance of lava-docker repository if you add me to
the lava-docker repository under lava namespace.
My gitlab username is https://gitlab.com/alice.ferrazzi it have enabled 2FA
for security.
We need to move also lava-healthchecks-binary repository that is currently
hosted under https://github.com/BayLibre/lava-healthchecks-binary as is
part of the lava-docker selfhosted healthcheck system.

Thanks,
Alice

-- 
======================================
Cybertrust Japan Co.,Ltd.
Alice Ferrazzi
alice.ferrazzi@miraclelinux.com
======================================

Re: Moving lava-docker out of the KernelCI GitHub organisation

[Corentin Labbe]

Le Fri, Sep 02, 2022 at 01:33:37PM +0900, Alice Ferrazzi a écrit :
> On Thu, Sep 1, 2022 at 11:56 PM Remi Duraffort <remi.duraffort@linaro.org>
> wrote:
> >
> > Hello,
> >
> > Le lun. 29 août 2022 à 08:18, Alice Ferrazzi <
> alice.ferrazzi@miraclelinux.com> a écrit :
> >>
> >> Hello Antonio,
> >>
> >> On Sat, Aug 27, 2022 at 3:40 AM Antonio Terceiro
> >> <antonio.terceiro@linaro.org> wrote:
> >> >
> >> > On Thu, Aug 25, 2022 at 04:05:47PM +0200, Guillaume Tucker wrote:
> >> > > Hello,
> >> > >
> >> > > The idea of adding BayLibre's lava-healthchecks-binary[1]
> >> > > repository to the KernelCI GitHub organisation was brought up
> >> > > during a KernelCI weekly meeting last month.  This appears to be
> >> > > related to the lava-docker[2] project which is currently in the
> >> > > KernelCI organisation, to bring the two repositories together.
> >> > >
> >> > > It seems to me that lava-docker and anything related to providing
> >> > > LAVA support is not something that KernelCI should be responsible
> >> > > for as a project.  In fact, the lava-docker repository has been
> >> > > managed entirely autonomously since the beginning by different
> >> > > maintainers than the core KernelCI repositories, and I believe it
> >> > > was originally added to the KernelCI org by Kevin as it was an
> >> > > easy thing to do that made sense at the time.
> >> > >
> >> > > Rather than having one more LAVA-related project under this org,
> >> > > how about either creating a dedicated GitHub organisation for
> >> > > lava-docker and related repositories, or adding lava-docker and
> >> > > the healthchecks to the LAVA GitLab instance on
> >> > > https://git.lavasoftware.org/?
> >> > >
> >> > > Having a dedicated org on GitHub would give the actual
> >> > > maintainers of the project full control over it, to add and move
> >> > > repositories, manage members, permissions etc. as they wish.
> >> > >
> >> > > However, if the LAVA maintainers think that lava-docker could
> >> > > become the main solution for running LAVA in Docker, then maybe
> >> > > it should be merged with some existing project on
> >> > > git.lavasoftware.org or added as a new project there.  That would
> >> > > give it more visibility and potentially remove duplicated
> >> > > efforts.
> >> >
> >> > FWIW, there is also
> >> > https://git.lavasoftware.org/lava/pkg/docker-compose which seems
> >> > similar, but not the same, as kernelci's lava-docker (e.g. there is no
> >> > autogeneration of config files AFAICT). That's used by a few people,
> but
> >> > mostly for development purposes I think.
> >> >
> >>
> >> yes, from what I could see is a different approach.
> >> We are offering a orchestration system that is generated
> >> programmatically by a yaml file (boards.yaml)
> >> that is creating the necessary docker-compose settings and unloading
> >> the already set up lava
> >> files and folders.
> >>
> >> > > I'm not sure I'm aware of all the implications for each of these
> >> > > options so I thought I would bring it up for discussion here.
> >> > > What do you think?
> >> >
> >> > I don't really have an opinion on what to do with lava-docker. In
> >> > principle, consolidation and collaboration is good, but we would need
> to
> >> > agree on the details. Also, moving it around must be done in a way that
> >> > the current maintainers still have the necessary access to keep
> >> > maintaining it (because the move won't make new maintainers magically
> >> > appear).
> >>
> >> I agree on doing it in a way that the current maintainers have still
> >> the necessary access rights for continue
> >> the development,
> >> I also would like to do it in a way that the current lava-docker users
> >> don't get confused on
> >> where the upstream repository moved to.
> >>
> >> Thanks,
> >> Alice

Hello

Sorry I am late to came in conversation.

I agree that lava-docker is probably not hosted in the right place now.
The only relation between the 2 project was that lava-docker was designed to help doing a LAVA lab for people wanting to join kernelCI
So I agree to move it out of kernelCI if it si necessary.

lava-docker has few users, so it will be easy to warn them. (I know AGL, GkernelCI, Baylibre, lab-broonie as real users, not sure if the other still use it).

For the moment I am the only maintainer, but if Alice want to step in, it will be good.

I will wait for Khilman to said the final words.

Re: Moving lava-docker out of the KernelCI GitHub organisation

[Kevin Hilman]

Remi Duraffort <remi.duraffort@linaro.org> writes:

[...]

> With Antonio we agreed that we can host the lava-docker project along with
> lava if that's what the maintainers want.

I think it makes sense to be under the LAVA as long as it's OK with
whoever maintains that.

> But keep in mind that we (Antonio and myself) don't have time to make any
> changes/maintenance on this project.

That's OK.  BayLibre will continue to maintain it.  If you don't want it
under the main lava org, we can put it under ours too.

> If lava-docker is moved into the lava namespace, maybe the project
> should be documented into the lava official documentation.

OK.  lava-docker is already using the base images provided by your team
already, we just build on that to make configuing a full LAVA env easier.

> We are planning to migrate the lava project from a self-hosted gitlab
> instance to the gitlab.com instance soon. If lava-docker is moved into the
> lava namespace it would be better to wait for the migration to gitlab.com
> (to avoid two migrations).

That makes sense,

Kevin