- Devel - oVirt List Archives

Proposal: moving to building oVirt RPMs via containers
by Yaniv Kaul 06 Dec '21

06 Dec '21

With the move to Github, I think we have an opportunity to move to building oVirt packages via containers. You may want to look at https://github.com/gluster/Gluster-Builds - building Gluster RPMs by running a container (the 'build container'), which has the required dependencies and is updated once a month, or when there's a new dependency. It fits nicely with Github actions or any other system that uses containers, from your laptop to K8S. What I personally really like about it is the fact that the Dockerfile becomes the self-describing build process. Thoughts? Y.

1 0

Updates on oVirt Node and oVirt appliance building outside Jenkins
by Sandro Bonazzola 04 Dec '21

04 Dec '21

Hi, just a quick update on current issues in trying to build oVirt Node and the engine appliance outside Jenkins. 1) Using GitHub Actions: an attempt to build it is in progress here: https://github.com/sandrobonazzola/ovirt-appliance/pull/1 it's currently failing due to lorax not being able to perform the build. It kind of make sense as we are trying to do a virt-install within a container without the needed virtualization hardware exposed. I'm currently investigating how to make use of software virtualization in order to drop the requirement on missing hardware / nested virtualization. Also investigating on how to use self hosted runners for providing a build system with usable virtualization hardware. 2) Using COPR: we have basically the same issue: lorax fails not having access to the virtualization hardware 3) Using CentOS Community Build System This is a fully fledged Koji instance and it allows to build using the image-build variant. It has a completely different configuration system and it is more similar to what we are doing within the downstream build of oVirt Node. An attempt of providing the configuration started here: https://gerrit.ovirt.org/c/ovirt-appliance/+/117801 The issue there is that all the packages needed to be included within Node and Appliance must be built within CentOS Community Build System build root. The system has no external access to the internet so everything we need it needs to come from CentOS infra. I haven't started digging into oVirt Node but the build flow is very similar to the appliance one, so once one is solved, the other should be simple. -- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://www.redhat.com/> *Red Hat respects your work life balance. Therefore there is no need to answer this email out of your office hours.*

2 2

oVirt Community - open discussion around repositories and workflows
by Sandro Bonazzola 03 Dec '21

03 Dec '21

Dear community members, We would like to take some next steps in improving usability and general decision making for our community and are interested in your thoughts and suggestions. The first step is a decision regarding our version control and workflows associated with it. Contributions to new features and general improvements for oVirt outside of Red Hat have been rare and we would like to hear from you if we could simplify this process for you. One suggestion we have is that we could simplify the contribution process and improve the contributor experience by moving our repositories to GitHub or GitLab. Currently, our Gerrit (gerrit.ovirt.org) instance is mirrored to GitHub and we already have several repositories that are exclusively developed there, including their CI running on GitHub Actions, for example: * https://github.com/oVirt/go-ovirt-client * https://github.com/oVirt/512-byte-vm There are also various related projects that run on GitLab, such as: * https://gitlab.com/qemu-project * https://gitlab.com/libvirt One recent project that moved from Gerrit to GitLab with a very similar discussion is mediawiki: https://www.mediawiki.org/wiki/GitLab_consultation/Discussion_summary Once we hear more of your thoughts around this and if the decision falls on moving to either GitHub or GitLab, our plan would be to start changing existing workflows and CI project by project as it makes sense. Both platforms offer similar features. Two key points that stand out for us are that: * GitLab is open source while GitHub isn't * GitHub is more visible which allows contributors to amplify their contributions and raise their profile by contributing to various big projects, including oVirt We are looking forward to hearing your thoughts, -- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://www.redhat.com/> *Red Hat respects your work life balance. Therefore there is no need to answer this email out of your office hours.*

4 10

Integrating OST with artifacts built in github
by Nir Soffer 02 Dec '21

02 Dec '21

Looking this very helpful document https://ovirt.org/develop/developer-guide/migrating_to_github.html The suggested solution is to create artifacts.zip with all the rpms for a project. But to use the rpms in OST, we need to create a yum repository before uploading the artifacts, so we can pass a URL of a zip file with a yum repository. Here is what we have now in ovirt-imageio: 1. We build for multiple distros: https://github.com/nirs/ovirt-imageio/blob/790e6b79e756de24ef5134aa583bea46… 2. Every build creates a repo in exported-artifacts https://github.com/nirs/ovirt-imageio/blob/790e6b79e756de24ef5134aa583bea46… 3. Every build uploads the exported artifacts to rpm-{distro}.zip https://github.com/nirs/ovirt-imageio/blob/790e6b79e756de24ef5134aa583bea46… An example build: https://github.com/nirs/ovirt-imageio/actions/runs/1531658722 To start OST manually, developer can copy a link the right zip file (e.g for centos stream 8): https://github.com/nirs/ovirt-imageio/suites/4535392764/artifacts/121520882 And pass the link to OST build with parameters job. In this solution, OST side gets a repo that can be included in the build without any additional code or logic - just unzip and use the repo from the directory. I think this is the minimal solution to allow running OST with built artifacts from github. For triggering jobs automatically, we will need a way to find the right artifacts for a build, or use some convention for naming the artifacts in all projects. I started with the simple convention of jobname-containername since it is easy to integrate with the infrastructure we already have in the project. Nir

2 1

Another CI failure
by Milan Zamazal 02 Dec '21

02 Dec '21

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? Thanks, Milan

3 4

IPV6 on github actions container
by Nir Soffer 02 Dec '21

02 Dec '21

I'm trying to add a github action workflow for ovirt-imageio. The yml file is simple: https://github.com/nirs/ovirt-imageio/commit/21da91274b7b4722167c2415d1c1b5… 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 = <object object at 0x7f2cb7d16270> 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.… Run before starting the job: https://github.com/oVirt/ovirt-imageio/blob/61f023bf1e45da4e98593278451030f… 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

2 3

COPR's ovirt-master-snapshot replacing resources.ovirt.org's "tested" repo
by Michal Skrivanek 02 Dec '21

02 Dec '21

Hi all, COPR[1] is effectively replacing the "tested" repo - the one that gets all built artifacts after a patch is merged (and is actually not tested:) Sandro started to move projects to COPR for merged patches some time ago and we believe it's complete except appliance and node. So we can all start switching to it as it is currently more up to date anyway Please start modifying your CI setup, other automation, your own updates, wherever really, and just switch from [2] to [3] (adjust the platform/arch accordingly as well, so e.g. [4]) Thanks, michal [1] https://copr.fedorainfracloud.org/coprs/ovirt/ovirt-master-snapshot/ [2] https://resources.ovirt.org/repos/ovirt/tested/master/rpm/ [3] https://download.copr.fedorainfracloud.org/results/ovirt/ovirt-master-snaps… [4] https://download.copr.fedorainfracloud.org/results/ovirt/ovirt-master-snaps…

1 1

Failed CI for engine patches - java-client-kubevirt otopi
by Shani Leviim 01 Dec '21

01 Dec '21

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/conso… The engine patches: https://gerrit.ovirt.org/q/topic:%22copy-template-mbs-disk%22+(status:open%… Can someone assist, please? *Regards,* *Shani Leviim*

7 11

Opened PRs in ovirt-engine Github
by Saif Abu Saleh 30 Nov '21

30 Nov '21

Hi, I noticed there is this pull requests: https://github.com/oVirt/ovirt-engine/pull/29 https://github.com/oVirt/ovirt-engine/pull/31 That opened to ovirt-engine Github repository, is anyone looking into them? Thanks, Saif

2 1

COPR: How add new project as ovirt-master-snapshots package
by Artur Socha 29 Nov '21

29 Nov '21

Hi Sandro, (** I have included dev@ovirt in CC because the answer might be useful to others as well **) I have created a new gerrit project / package 'ovirt-engine-keycloak' [1] and I would like to somehow enable the COPR build. I saw there is 'ovirt-master-snapshot' [2] that has multiple packages configured ie. vdsm-jsonrpc-java that I searched for reference. What is the process to add a new package there (ie. some patch somewhere, ticket or just pinging relevant people, any special setup in GH repo besides .copr/Makefile)? [1] https://gerrit.ovirt.org/#/q/project:ovirt-engine-keycloak [2] https://copr.fedorainfracloud.org/coprs/ovirt/ovirt-master-snapshot/package… thanks! -- Artur Socha Senior Software Engineer, RHV Red Hat

2 2