[ovirt-devel] Re: IPV6 on github actions container

[Ales Musil]

On Wed, Dec 1, 2021 at 11:28 PM Nir Soffer  wrote:

> On Wed, Dec 1, 2021 at 11:11 PM Nir Soffer  wrote:
> >
> > I'm trying to add a github action workflow for ovirt-imageio.
> >
> > The yml file is simple:
> >
> https://github.com/nirs/ovirt-imageio/commit/21da91274b7b4722167c2415d1c1b5db08c5e88b
> >
> > And all the jobs run, but tons of tests are failing:
> > https://github.com/nirs/ovirt-imageio/actions/runs/1527728851
>
> Solved by not using github "container" option. Instead, just run
> docker manually like we did in travis.
>
>
> https://github.com/nirs/ovirt-imageio/commit/6fb94e9423c1642af716e3327038835fc09d225c
>
> Notes for others that my have the same issue:
>
> docker run -it ...
>
> fails in github action with:
>
> "the input device is not a TTY"
>
> Removing the "-it" options solves this problem. The output of the command
> running in the container logged to stdout. I don't know why we always run
> the container with -it.
>
> So we have working github CI for ovirt-imageio:
> https://github.com/nirs/ovirt-imageio/actions/runs/1528026365
>
> Running tests on centos stream 8, centos stream 9, and fedora 34 in 4
> minutes.
>
> I think the only thing missing to move to github, is to build the rpms in
> a way
> that can be used by OST.
>
> Nir
>
>
AFAIK enabling ipv6 can be done inside the container by running:
sysctl -w net.ipv6.conf.all.disable_ipv6=0

Might be worth doing this instead of the additional docker configuration
and restarting the whole service.

Regards,
Ales


-- 

Ales Musil

Software Engineer - RHV Network

Red Hat EMEA 

amu...@redhat.comIM: amusil

___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/T4LJFGMTPUPSV3XKFEPBRSFBPSMJLWDV/

[ovirt-devel] Re: IPV6 on github actions container

[Nir Soffer]

On Wed, Dec 1, 2021 at 11:11 PM Nir Soffer  wrote:
>
> I'm trying to add a github action workflow for ovirt-imageio.
>
> The yml file is simple:
> https://github.com/nirs/ovirt-imageio/commit/21da91274b7b4722167c2415d1c1b5db08c5e88b
>
> And all the jobs run, but tons of tests are failing:
> https://github.com/nirs/ovirt-imageio/actions/runs/1527728851

Solved by not using github "container" option. Instead, just run
docker manually like we did in travis.

https://github.com/nirs/ovirt-imageio/commit/6fb94e9423c1642af716e3327038835fc09d225c

Notes for others that my have the same issue:

docker run -it ...

fails in github action with:

"the input device is not a TTY"

Removing the "-it" options solves this problem. The output of the command
running in the container logged to stdout. I don't know why we always run
the container with -it.

So we have working github CI for ovirt-imageio:
https://github.com/nirs/ovirt-imageio/actions/runs/1528026365

Running tests on centos stream 8, centos stream 9, and fedora 34 in 4 minutes.

I think the only thing missing to move to github, is to build the rpms in a way
that can be used by OST.

Nir
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/7CSZL3PO3CCQK67S47DX2OKTIECNPDEV/

[ovirt-devel] IPV6 on github actions container

[Nir Soffer]

I'm trying to add a github action workflow for ovirt-imageio.

The yml file is simple:
https://github.com/nirs/ovirt-imageio/commit/21da91274b7b4722167c2415d1c1b5db08c5e88b

And all the jobs run, but tons of tests are failing:
https://github.com/nirs/ovirt-imageio/actions/runs/1527728851

The typical failure is:

2021-12-01T20:50:07.6424921Z address = ('::', 43001), timeout =

2021-12-01T20:50:07.6425749Z source_address = None
2021-12-01T20:50:07.6425985Z
2021-12-01T20:50:07.6426421Z def create_connection(address,
timeout=_GLOBAL_DEFAULT_TIMEOUT,
2021-12-01T20:50:07.6426954Z   source_address=None):
...
2021-12-01T20:50:07.6435579Z host, port = address
2021-12-01T20:50:07.6435942Z err = None
2021-12-01T20:50:07.6436563Z for res in getaddrinfo(host,
port, 0, SOCK_STREAM):
2021-12-01T20:50:07.6437402Z af, socktype, proto,
canonname, sa = res
2021-12-01T20:50:07.6437834Z sock = None
2021-12-01T20:50:07.6438146Z try:
2021-12-01T20:50:07.6438522Z sock = socket(af, socktype, proto)
2021-12-01T20:50:07.6439032Z if timeout is not
_GLOBAL_DEFAULT_TIMEOUT:
2021-12-01T20:50:07.6439538Z sock.settimeout(timeout)
2021-12-01T20:50:07.6440109Z if source_address:
2021-12-01T20:50:07.6440522Z sock.bind(source_address)
2021-12-01T20:50:07.6440916Z >   sock.connect(sa)
2021-12-01T20:50:07.6441573Z E   OSError: [Errno 99]
Cannot assign requested address

I guess that ipv6 is disabled, and google confirms that github actions
and ipv6 is
an issue.

In travis we enabled ipv6 in docker using this script:
https://github.com/oVirt/ovirt-imageio/blob/master/travis/configure-docker.py

Run before starting the job:
https://github.com/oVirt/ovirt-imageio/blob/61f023bf1e45da4e98593278451030f433080ab0/.travis.yml#L15

I did not try to run this script yet, since I'm not sure we have a way
to run stuff *before*
the container runs in github actions.

I hope someone has some insight on a way to solve this.

Nir
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/467GFY5UP67PTCRNTHZWWIHA3H5YRIZ7/

[ovirt-devel] Re: oVirt Community - open discussion around repositories and workflows

[Nir Soffer]

On Wed, Dec 1, 2021 at 11:38 AM Milan Zamazal  wrote:
>
> Michal Skrivanek  writes:
>
> > Hi all,
> > so far we haven't encounter any blocking issue with this effort, I
> > wanted to propose to decide on oVirt development moving to GitHub,
> > COPR and CBS. Recent issue with decommissioning of our CI datacenter
> > is a good reminder why we are doing that...
> > What do we want to do?
> > 1) move "ovirt-master-snapshot" compose to COPR
> >   it is feasible for all projects except ovirt-node and
> > appliance due to COPR limitations, for these two we plan to use a
> > self-hosted runner in github env.
> >   it replaces the "build-artifacts" stdci stage
> > 2) move release to CentOS Community Build System to simplify our oVirt 
> > releases
> >   replaces our custom releng-tools process and aligns us better
> > with CentOS that is our main (and only) platform we support.
> > 3) move development from Gerrit to GitHub
> >   this is a very visible change and affects every oVirt
> > developer. We need a way how to test posted patches and the current
> > stdci "check-patch" stage is overly complex and slow to run, we lack
> > people for stdci maintenance in general (bluntly, it's a dead
> > project). Out of the various options that exist we ended up converging
> > to Github. Why? Just because it's the most simple thing to do for us,
> > with least amount of effort, least amount of additional people and hw
> > resources, with a manageable learning curve. It comes at a price - it
> > only works if we switch our primary development from Gerrit to Github
> > for all the remaining projects. It is a big change to our processes,
> > but I believe we have to go through that transition in order to solve
> > our CI troubles for good.  We started preparing guide and templates to
> > use so that we keep a uniform "look and feel" for all sub-projects, is
> > shall be ready soon.
> >
> > I'd like us to move from "POC" stage to "production", and actively
> > start working on the above, start moving project after project.
> > Let me ask for a final round of thoughts, comments, objections, we are 
> > ready to go ahead.
>
> Hi,
>
> the Vdsm maintainers have discussed the possibility of moving Vdsm
> development to GitHub and we consider it a reasonable and feasible
> option.  Although GitHub is not on par with Gerrit as for code reviews,
> having a more reliable common development platform outweighs the
> disadvantages.  There is already an ongoing work on having a fully
> usable Vdsm CI on GitHub.
>
> One thing related to the move is that we would like to retain the
> history of code reviews from Gerrit.  The comments there contain
> valuable information that we wouldn't like to lose.  Is there a way to
> export the public Gerrit contents, once we make a switch to GitHub for
> each particular project, to something that could be reasonably used for
> patch archaeology when needed?

I think keeping a readonly instance would be best, one all projects
migrated to github.

I hope there is a way to export the data to static html so it will be
available forever without running an actual gerrit instance.

Nir

>
> > It's not going to be easy, but I firmly believe it will greatly
> > improve maintainability of oVirt and reduce overhead that we all
> > struggle with for years.
> >
> > Thanks,
> > michal
> >
> >> On 10. 11. 2021, at 9:17, Sandro Bonazzola  wrote:
> >>
> >> Hi, here's an update on what has been done so far and how it is going.
> >>
> >> COPR
> >> All the oVirt active subprojects are now built on COPR except oVirt
> >> Engine Appliance and oVirt Node: I'm still looking into how to build
> >> them on COPR.
> >>
> >> Of those subprojects only the following are not yet built
> >> automatically on patch merge event as they have pending patches for
> >> enabling the automation:
> >> - ovirt-engine-nodejs-modules:
> >> https://gerrit.ovirt.org/c/ovirt-engine-nodejs-modules/+/117506
> >> -
> >> ovirt-engine-ui-extensions:
> >> https://gerrit.ovirt.org/c/ovirt-engine-ui-extensions/+/117512
> >> 
> >> - ovirt-web-ui: https://github.com/oVirt/ovirt-web-ui/pull/1532
> >> 
> >>
> >> You can see the build status for the whole project here:
> >> https://copr.fedorainfracloud.org/coprs/ovirt/ovirt-master-snapshot/monitor/
> >> 
> >> If you are maintaining an oVirt project and you want to enable
> >> builds for CentOS Stream 9 or other architectures supported by copr
> >> please let me know.
> >>
> >> So far, the COPR infrastructure seems reliable and working well.
> >>
> >> GitHub
> >> The following projects are developed on GitHub only:
> >> - ovirt-ansible-collection
> >> - ovirt-cockpit-sso
> >> - ovirt-web-ui
> >> - python-ovirt-engine-sdk4
> >> - ovirt-engine-sdk-go

[ovirt-devel] Re: oVirt Community - open discussion around repositories and workflows

[Nir Soffer]

On Wed, Dec 1, 2021 at 11:11 AM Michal Skrivanek <
michal.skriva...@redhat.com> wrote:

> Hi all,
> so far we haven't encounter any blocking issue with this effort, I wanted
> to propose to decide on oVirt development moving  to GitHub, COPR and CBS.
> Recent issue with decommissioning of our CI datacenter is a good reminder
> why we are doing that...
> What do we want to do?
> 1) move "ovirt-master-snapshot" compose to COPR
> it is feasible for all projects except ovirt-node and appliance due to
> COPR limitations, for these two we plan to use a self-hosted runner in
> github env.
> it replaces the "build-artifacts" stdci stage
> 2) move release to CentOS Community Build System to simplify our oVirt
> releases
> replaces our custom releng-tools process and aligns us better with CentOS
> that is our main (and only) platform we support.
> 3) move development from Gerrit to GitHub
> this is a very visible change and affects every oVirt developer. We need a
> way how to test posted patches and the current stdci "check-patch" stage is
> overly complex and slow to run, we lack people for stdci maintenance in
> general (bluntly, it's a dead project). Out of the various options that
> exist we ended up converging to Github. Why? Just because it's the most
> simple thing to do for us, with least amount of effort, least amount of
> additional people and hw resources, with a manageable learning curve. It
> comes at a price - it only works if we switch our primary development from
> Gerrit to Github for all the remaining projects. It is a big change to our
> processes, but I believe we have to go through that transition in order to
> solve our CI troubles for good.  We started preparing guide and templates
> to use so that we keep a uniform "look and feel" for all sub-projects, is
> shall be ready soon.
>
> I'd like us to move from "POC" stage to "production", and actively start
> working on the above, start moving project after project.
> Let me ask for a final round of thoughts, comments, objections, we are
> ready to go ahead.
>
> It's not going to be easy, but I firmly believe it will greatly improve
> maintainability of oVirt and reduce overhead that we all struggle with for
> years.
>

This is actually pretty easy. We start to work on this last week, and we
have
partial CI in place on github and gitlab.

- lint: merged!
https://github.com/oVirt/vdsm/actions/runs/1526187734

- storage tests:
https://gerrit.ovirt.org/c/vdsm/+/117882/
https://github.com/oVirt/vdsm/actions/runs/1526489399

We don't accept pull requests on github yet, but you can open
pull request for testing, like this:
https://github.com/oVirt/vdsm/pull/25
The new CI runs for the pull request.

I also added the same CI pipeline to gitlab:
https://gitlab.com/nirs/vdsm/-/pipelines/420340180

This will help to avoid locking to github, or backup if github has
an outage (just happened last week).

The new CI is based on containers, and should be usable locally
using podman, see:
https://github.com/oVirt/vdsm/blob/master/tests/start-container

The only thing missing to move to github is a way to trigger OST
and add OST results when it is done.

Nir


> Thanks,
> michal
>
> On 10. 11. 2021, at 9:17, Sandro Bonazzola  wrote:
>
> Hi, here's an update on what has been done so far and how it is going.
>
> *COPR*
> All the oVirt active subprojects are now built on COPR except oVirt Engine
> Appliance and oVirt Node: I'm still looking into how to build them on COPR.
>
> Of those subprojects only the following are not yet built automatically on
> patch merge event as they have pending patches for enabling the automation:
> - ovirt-engine-nodejs-modules:
> https://gerrit.ovirt.org/c/ovirt-engine-nodejs-modules/+/117506
> - ovirt-engine-ui-extensions:
> https://gerrit.ovirt.org/c/ovirt-engine-ui-extensions/+/117512
> - ovirt-web-ui: https://github.com/oVirt/ovirt-web-ui/pull/1532
>
> You can see the build status for the whole project here:
> https://copr.fedorainfracloud.org/coprs/ovirt/ovirt-master-snapshot/monitor/
> If you are maintaining an oVirt project and you want to enable builds for
> CentOS Stream 9 or other architectures supported by copr please let me know.
>
> So far, the COPR infrastructure seems reliable and working well.
>
> *GitHub*
> The following projects are developed on GitHub only:
> - ovirt-ansible-collection
> - ovirt-cockpit-sso
> - ovirt-web-ui
> - python-ovirt-engine-sdk4
> - ovirt-engine-sdk-go
>
> Within this list:
> - ovirt-engine-sdk-go is not being built in COPR as the rpm is not needed
> for developing with go and the automation is already handled on GitHub
> actions only.
> - ovirt-cockpit-sso is still triggering jenkins jobs but it's ready to
> drop them as PR are now tested with github actions too and builds are
> handled in COPR.
>
> So far, moving the development to GitHub only seems to be working well and
> I would suggest the maintainers of the oVirt subprojects to consider moving
> to GitHub only as well.
> +Sanja Bonic  

[ovirt-devel] Re: Failed CI for engine patches - java-client-kubevirt otopi

[Benny Zlotnik]

I can confirm using this repo works[1], do we want to merge this
workaround to unblock CI or the migration to the new repos is expected
soon?



[1] 
https://gerrit.ovirt.org/c/ovirt-engine/+/117873/3/automation/build-artifacts.repos

On Thu, Nov 25, 2021 at 9:47 PM Ehud Yonasi  wrote:
>
> Indeed Martin, I can see it now.
> We have an issue reflecting the new resources server, probably dns or 
> something related.
>
> Meanwhile Shani, I suggest that you change the resources server in your 
> automation/*.repos file to:
> https://resources02.phx.ovirt.org/repos/ovirt/tested/master/rpm/el8
>
> We have someone already looking into it already and we hope CI will be fixed 
> soon.
> Apologies.
>
> On 25 Nov 2021, at 18:03, Martin Perina  wrote:
>
>
>
> On Thu, Nov 25, 2021 at 2:04 PM Ehud Yonasi  wrote:
>>
>> So I am not sure where the dependency came from, but as I can see from otopi 
>> repo it is only realsing to ovirt-4.3 on resources at the moment.
>
>
> Not true, otopi is configured correctly:
>
> master -> ovirt-master
> https://github.com/oVirt/otopi/blob/master/.ovirtci.yaml
>
> otopi-1..9 -> ovirt-4.4
> https://github.com/oVirt/otopi/blob/otopi-1.9/.ovirtci.yaml
>
> Similar situation is with java-client-kubevirt, which should also be 
> correctly setup:
>
> master -> ovirt-master, ovirt-4.4
> https://github.com/oVirt/java-client-kubevirt/blob/master/.stdci.yaml
>
> And I had to mention that similar situation we had for 
> ovirt-jboss-modules-maven-plugin, which magically disappeared from tested 
> repo cca 2 weeks ago and I needed to re-merge last patch to get the build 
> there again. And also here everything seems correct to me:
>
> https://github.com/oVirt/ovirt-jboss-modules-maven-plugin/blob/master/automation.yaml
>
>
> All of those packages are included in oVirt project for quite long time, so 
> the issue is somewhere in the Jenkins CI
>
>>
>> Maybe Sandro can help with that?
>>
>> On Thu, Nov 25, 2021 at 2:46 PM Shani Leviim  wrote:
>>>
>>> Hi Ehud,
>>> Honestly - I have no idea.
>>> This failure is from today, but in the patches, there is a series of CI 
>>> failures while trying to build the patch - all failures while trying to 
>>> build the engine.
>>>
>>> Regards,
>>> Shani Leviim
>>>
>>>
>>> On Thu, Nov 25, 2021 at 2:19 PM Ehud Yonasi  wrote:

 Hi Shani and Artur,

 I didn't find otopi and that java-client-kubevirt package in the repos 
 listed inside the run. was it there in the first place?

 Artur, It seems the centos mirrors were not available during the time of 
 the build, could you please re-trigger it and update if it's working for 
 you now?

 Thanks,
 Ehud.

 On Thu, Nov 25, 2021 at 1:28 PM Artur Socha  wrote:
>
> I could also add that I am currently having an issue with accessing 
> Centos stream 8 AppStream repo (timed out). See [1] . Perhaps that 
> somehow related?
>
> [1] 
> https://jenkins.ovirt.org/job/vdsm-jsonrpc-java_standard-check-patch/187/console
>
> Artur
>
> On Thu, Nov 25, 2021 at 11:50 AM Shani Leviim  wrote:
>>
>> Hi,
>> I have a series of engine patches that keep failing although the chain 
>> is rebased on the latest master.
>> I ran 'ci build' a couple of minutes ago and it failed with this one:
>> 11:08:45 No match for argument: otopi
>> 11:08:45 Error: Unable to find a match: java-client-kubevirt otopi
>> https://jenkins.ovirt.org/job/ovirt-engine_standard-check-patch/15286/console
>>
>> The engine patches:
>> https://gerrit.ovirt.org/q/topic:%22copy-template-mbs-disk%22+(status:open%20OR%20status:merged)
>>
>> Can someone assist, please?
>>
>> Regards,
>> Shani Leviim
>> ___
>> Devel mailing list -- devel@ovirt.org
>> To unsubscribe send an email to devel-le...@ovirt.org
>> Privacy Statement: https://www.ovirt.org/privacy-policy.html
>> oVirt Code of Conduct: 
>> https://www.ovirt.org/community/about/community-guidelines/
>> List Archives: 
>> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/VUYJRGNY6X7UYZ6PQBQGVENE5LVFGN3O/
>
>
>
> --
> Artur Socha
> Senior Software Engineer, RHV
> Red Hat
> ___
> Devel mailing list -- devel@ovirt.org
> To unsubscribe send an email to devel-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct: 
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives: 
> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/M6XM7FS4PD4E6USDK433IQDYIS7LJLQ2/
>>
>> ___
>> Devel mailing list -- devel@ovirt.org
>> To unsubscribe send an email to devel-le...@ovirt.org
>> Privacy Statement: https://www.ovirt.org/privacy-policy.html
>> oVirt Code of Conduct: 
>> 

[ovirt-devel] Re: oVirt Community - open discussion around repositories and workflows

[Milan Zamazal]

Michal Skrivanek  writes:

> Hi all,
> so far we haven't encounter any blocking issue with this effort, I
> wanted to propose to decide on oVirt development moving to GitHub,
> COPR and CBS. Recent issue with decommissioning of our CI datacenter
> is a good reminder why we are doing that...
> What do we want to do?
> 1) move "ovirt-master-snapshot" compose to COPR
>   it is feasible for all projects except ovirt-node and
> appliance due to COPR limitations, for these two we plan to use a
> self-hosted runner in github env.
>   it replaces the "build-artifacts" stdci stage
> 2) move release to CentOS Community Build System to simplify our oVirt 
> releases
>   replaces our custom releng-tools process and aligns us better
> with CentOS that is our main (and only) platform we support.
> 3) move development from Gerrit to GitHub
>   this is a very visible change and affects every oVirt
> developer. We need a way how to test posted patches and the current
> stdci "check-patch" stage is overly complex and slow to run, we lack
> people for stdci maintenance in general (bluntly, it's a dead
> project). Out of the various options that exist we ended up converging
> to Github. Why? Just because it's the most simple thing to do for us,
> with least amount of effort, least amount of additional people and hw
> resources, with a manageable learning curve. It comes at a price - it
> only works if we switch our primary development from Gerrit to Github
> for all the remaining projects. It is a big change to our processes,
> but I believe we have to go through that transition in order to solve
> our CI troubles for good.  We started preparing guide and templates to
> use so that we keep a uniform "look and feel" for all sub-projects, is
> shall be ready soon.
>
> I'd like us to move from "POC" stage to "production", and actively
> start working on the above, start moving project after project.
> Let me ask for a final round of thoughts, comments, objections, we are ready 
> to go ahead.

Hi,

the Vdsm maintainers have discussed the possibility of moving Vdsm
development to GitHub and we consider it a reasonable and feasible
option.  Although GitHub is not on par with Gerrit as for code reviews,
having a more reliable common development platform outweighs the
disadvantages.  There is already an ongoing work on having a fully
usable Vdsm CI on GitHub.

One thing related to the move is that we would like to retain the
history of code reviews from Gerrit.  The comments there contain
valuable information that we wouldn't like to lose.  Is there a way to
export the public Gerrit contents, once we make a switch to GitHub for
each particular project, to something that could be reasonably used for
patch archaeology when needed?

> It's not going to be easy, but I firmly believe it will greatly
> improve maintainability of oVirt and reduce overhead that we all
> struggle with for years.
>
> Thanks,
> michal
>
>> On 10. 11. 2021, at 9:17, Sandro Bonazzola  wrote:
>> 
>> Hi, here's an update on what has been done so far and how it is going.
>> 
>> COPR
>> All the oVirt active subprojects are now built on COPR except oVirt
>> Engine Appliance and oVirt Node: I'm still looking into how to build
>> them on COPR.
>> 
>> Of those subprojects only the following are not yet built
>> automatically on patch merge event as they have pending patches for
>> enabling the automation:
>> - ovirt-engine-nodejs-modules:
>> https://gerrit.ovirt.org/c/ovirt-engine-nodejs-modules/+/117506
>> -
>> ovirt-engine-ui-extensions:
>> https://gerrit.ovirt.org/c/ovirt-engine-ui-extensions/+/117512
>> 
>> - ovirt-web-ui: https://github.com/oVirt/ovirt-web-ui/pull/1532
>> 
>> 
>> You can see the build status for the whole project here:
>> https://copr.fedorainfracloud.org/coprs/ovirt/ovirt-master-snapshot/monitor/
>> 
>> If you are maintaining an oVirt project and you want to enable
>> builds for CentOS Stream 9 or other architectures supported by copr
>> please let me know.
>> 
>> So far, the COPR infrastructure seems reliable and working well.
>> 
>> GitHub
>> The following projects are developed on GitHub only:
>> - ovirt-ansible-collection
>> - ovirt-cockpit-sso
>> - ovirt-web-ui
>> - python-ovirt-engine-sdk4
>> - ovirt-engine-sdk-go
>> 
>> Within this list:
>> - ovirt-engine-sdk-go is not being built in COPR as the rpm is not
>> needed for developing with go and the automation is already handled
>> on GitHub actions only.
>> - ovirt-cockpit-sso is still triggering jenkins jobs but it's ready
>> to drop them as PR are now tested with github actions too and builds
>> are handled in COPR.
>> 
>> So far, moving the development to GitHub only seems to be working
>> well and I would suggest the 

[ovirt-devel] Re: oVirt Community - open discussion around repositories and workflows

[Michal Skrivanek]

Hi all,
so far we haven't encounter any blocking issue with this effort, I wanted to 
propose to decide on oVirt development moving  to GitHub, COPR and CBS. Recent 
issue with decommissioning of our CI datacenter is a good reminder why we are 
doing that...
What do we want to do?
1) move "ovirt-master-snapshot" compose to COPR
it is feasible for all projects except ovirt-node and appliance due to 
COPR limitations, for these two we plan to use a self-hosted runner in github 
env.
it replaces the "build-artifacts" stdci stage
2) move release to CentOS Community Build System to simplify our oVirt releases
replaces our custom releng-tools process and aligns us better with 
CentOS that is our main (and only) platform we support.
3) move development from Gerrit to GitHub
this is a very visible change and affects every oVirt developer. We 
need a way how to test posted patches and the current stdci "check-patch" stage 
is overly complex and slow to run, we lack people for stdci maintenance in 
general (bluntly, it's a dead project). Out of the various options that exist 
we ended up converging to Github. Why? Just because it's the most simple thing 
to do for us, with least amount of effort, least amount of additional people 
and hw resources, with a manageable learning curve. It comes at a price - it 
only works if we switch our primary development from Gerrit to Github for all 
the remaining projects. It is a big change to our processes, but I believe we 
have to go through that transition in order to solve our CI troubles for good.  
We started preparing guide and templates to use so that we keep a uniform "look 
and feel" for all sub-projects, is shall be ready soon.

I'd like us to move from "POC" stage to "production", and actively start 
working on the above, start moving project after project.
Let me ask for a final round of thoughts, comments, objections, we are ready to 
go ahead.

It's not going to be easy, but I firmly believe it will greatly improve 
maintainability of oVirt and reduce overhead that we all struggle with for 
years.

Thanks,
michal

> On 10. 11. 2021, at 9:17, Sandro Bonazzola  wrote:
> 
> Hi, here's an update on what has been done so far and how it is going.
> 
> COPR
> All the oVirt active subprojects are now built on COPR except oVirt Engine 
> Appliance and oVirt Node: I'm still looking into how to build them on COPR.
> 
> Of those subprojects only the following are not yet built automatically on 
> patch merge event as they have pending patches for enabling the automation:
> - ovirt-engine-nodejs-modules: 
> https://gerrit.ovirt.org/c/ovirt-engine-nodejs-modules/+/117506 
> - 
> ovirt-engine-ui-extensions: 
> https://gerrit.ovirt.org/c/ovirt-engine-ui-extensions/+/117512 
> 
> - ovirt-web-ui: https://github.com/oVirt/ovirt-web-ui/pull/1532 
> 
> 
> You can see the build status for the whole project here: 
> https://copr.fedorainfracloud.org/coprs/ovirt/ovirt-master-snapshot/monitor/ 
> 
> If you are maintaining an oVirt project and you want to enable builds for 
> CentOS Stream 9 or other architectures supported by copr please let me know.
> 
> So far, the COPR infrastructure seems reliable and working well.
> 
> GitHub
> The following projects are developed on GitHub only:
> - ovirt-ansible-collection
> - ovirt-cockpit-sso
> - ovirt-web-ui
> - python-ovirt-engine-sdk4
> - ovirt-engine-sdk-go
> 
> Within this list:
> - ovirt-engine-sdk-go is not being built in COPR as the rpm is not needed for 
> developing with go and the automation is already handled on GitHub actions 
> only.
> - ovirt-cockpit-sso is still triggering jenkins jobs but it's ready to drop 
> them as PR are now tested with github actions too and builds are handled in 
> COPR.
> 
> So far, moving the development to GitHub only seems to be working well and I 
> would suggest the maintainers of the oVirt subprojects to consider moving to 
> GitHub only as well.
> +Sanja Bonic  can help you enabling GitHub actions 
> for your oVirt projects so please ping her if you need help.
> 
> CentOS Community Build
> 
> I'm going to try building the same projects currently being built in COPR 
> also within the CentOS Community Build system in the coming weeks.
> If you are already a CentOS Virtualization SIG member and you want to help 
> with this effort please let me know what you are going to build there so we 
> won't duplicate the work.
> If you are an oVirt project maintainer I would recommend you to join CentOS 
> Virtualization SIG so you'll be independent releasing your package builds.
> 
> 
> 
> 
> Il giorno mar 2 nov 2021 alle ore 12:06 Sandro Bonazzola  > ha scritto:
> Hi, 

[ovirt-devel] Re: Another CI failure

[Milan Zamazal]

Ehud Yonasi  writes:

> It was a problem with global setup with el9 node - there was a missing 
> package and it was removed in:
> https://gerrit.ovirt.org/c/jenkins/+/117867 
> 

Thank you!

Unfortunately, there is another problem, on an el8 node:
https://jenkins.ovirt.org/job/vdsm_standard-check-patch/31165/

Apparently this:

  Error: Unable to find a match: python-pyyaml python-jinja2 python-six 
python-pyxdg

>> On 30 Nov 2021, at 22:14, Michal Skrivanek  
>> wrote:
>> 
>> 
>> 
>>> On 30. 11. 2021, at 14:37, Milan Zamazal  wrote:
>>> 
>>> Hi,
>>> 
>>> as demonstrated in
>>> https://jenkins.ovirt.org/job/vdsm_standard-check-patch/31133/, OST
>>> builds can at least start now but still fail, apparently due to the
>>> following:
>>> 
>>> + sudo -n usermod -a -G jenkins qemu
>>> usermod: user 'qemu' does not exist
>>> + log ERROR 'Failed to add user qemu to group jenkins'
>>> + local level=ERROR
>>> + shift
>>> + local 'message=Failed to add user qemu to group jenkins'
>>> + local prefix
>>> + [[ 4 -gt 1 ]]
>>> + prefix='global_setup[lago_setup]'
>>> + echo 'global_setup[lago_setup] ERROR: Failed to add user qemu to group 
>>> jenkins'
>>> global_setup[lago_setup] ERROR: Failed to add user qemu to group jenkins
>>> + return 1
>>> + failed=true
>>> 
>>> What can be done about it?
>> 
>> it passed the next time, perhaps a faulty jenkins node that doesn't build?
>> 
>>> 
>>> Thanks,
>>> Milan
>>> ___
>>> Devel mailing list -- devel@ovirt.org 
>>> To unsubscribe send an email to devel-le...@ovirt.org 
>>> 
>>> Privacy Statement: https://www.ovirt.org/privacy-policy.html
>>> 
>>> oVirt Code of Conduct:
>>> https://www.ovirt.org/community/about/community-guidelines/
>>> 
>>> List Archives:
>>> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/KLQU6KMMORGVDSENBY4COFQZFHAPBS7R/
>>> 
>> ___
>> Infra mailing list -- in...@ovirt.org 
>> To unsubscribe send an email to infra-le...@ovirt.org 
>> 
>> Privacy Statement: https://www.ovirt.org/privacy-policy.html
>> 
>> oVirt Code of Conduct:
>> https://www.ovirt.org/community/about/community-guidelines/
>> 
>> List Archives:
>> https://lists.ovirt.org/archives/list/in...@ovirt.org/message/AAUUN64LO5JJRXDI2CL4DBGYX3AZTJN2/
>> 
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/XAJBU57YVUUVNFFWQLPY3W3H5FMAB2FX/