- Infra - oVirt List Archives

[JIRA] (OVIRT-874) Move github project to gerrit
by eyal edri [Administrator] (oVirt JIRA) 28 Nov '16

28 Nov '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-874?page=com.atlassian.jira.p… ] eyal edri [Administrator] reassigned OVIRT-874: ----------------------------------------------- Assignee: Shlomo Ben David (was: infra) Can you please help with this ? Lets make sure adding a new project has the new permisisons for all projects we have and its mirrored to GitHub > Move github project to gerrit > ----------------------------- > > Key: OVIRT-874 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-874 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Marek Libra > Assignee: Shlomo Ben David > > Hi, > please move following github project > https://github.com/mareklibra/userportal > to gerrit as 'ovirt-web-ui' project. > Please keep git history. > What is needed for automatic read-only syncing the gerrit back to the github? > Thanks, > Marek -- This message was sent by Atlassian JIRA (v1000.571.2#100021)

1 0

[JIRA] (OVIRT-874) Move github project to gerrit
by Marek Libra (oVirt JIRA) 28 Nov '16

28 Nov '16

Marek Libra created OVIRT-874: --------------------------------- Summary: Move github project to gerrit Key: OVIRT-874 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-874 Project: oVirt - virtualization made easy Issue Type: By-EMAIL Reporter: Marek Libra Assignee: infra Hi, please move following github project https://github.com/mareklibra/userportal to gerrit as 'ovirt-web-ui' project. Please keep git history. What is needed for automatic read-only syncing the gerrit back to the github? Thanks, Marek -- This message was sent by Atlassian JIRA (v1000.571.2#100021)

1 0

[JIRA] (OVIRT-758) Vdsm docker testing images
by eyal edri [Administrator] (oVirt JIRA) 28 Nov '16

28 Nov '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-758?page=com.atlassian.jira.p… ] eyal edri [Administrator] updated OVIRT-758: -------------------------------------------- Assignee: eyal edri [Administrator] (was: infra) Status: In Progress (was: To Do) > Vdsm docker testing images > -------------------------- > > Key: OVIRT-758 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-758 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Nir Soffer > Assignee: eyal edri [Administrator] > > Hi all, > Vdsm includes now 2 Dockerfiles, building CentOS 7 and Fedora 24 images. > See https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:d… > Currently I maintain the images in docker hub: > - https://hub.docker.com/r/nirs/vdsm-centos/ > - https://hub.docker.com/r/nirs/vdsm-fedora/ > I configured automatic build, so each time I push a change to this branch: > https://github.com/nirs/vdsm/tree/dockerfile > Docker go and rebuilds the images. > We want to move the images to docker hub ovirt account: > https://hub.docker.com/u/ovirt/ > And configure vdsm github project so docker will rebuild > the images when we push a changes to the dockerfile branch, > or another solution to allow easy update of the images by > merging a new dockerfile. > Nir -- This message was sent by Atlassian JIRA (v1000.571.2#100021)

1 0

[JIRA] (OVIRT-758) Vdsm docker testing images
by eyal edri [Administrator] (oVirt JIRA) 28 Nov '16

28 Nov '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-758?page=com.atlassian.jira.p… ] eyal edri [Administrator] commented on OVIRT-758: ------------------------------------------------- I created a new organization for oVirt under: https://hub.docker.com/u/ovirtinfra/ (ovirt wasn't available) please let me know which permissions do you need to create the VDSM images repos under it. > Vdsm docker testing images > -------------------------- > > Key: OVIRT-758 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-758 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Nir Soffer > Assignee: infra > > Hi all, > Vdsm includes now 2 Dockerfiles, building CentOS 7 and Fedora 24 images. > See https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:d… > Currently I maintain the images in docker hub: > - https://hub.docker.com/r/nirs/vdsm-centos/ > - https://hub.docker.com/r/nirs/vdsm-fedora/ > I configured automatic build, so each time I push a change to this branch: > https://github.com/nirs/vdsm/tree/dockerfile > Docker go and rebuilds the images. > We want to move the images to docker hub ovirt account: > https://hub.docker.com/u/ovirt/ > And configure vdsm github project so docker will rebuild > the images when we push a changes to the dockerfile branch, > or another solution to allow easy update of the images by > merging a new dockerfile. > Nir -- This message was sent by Atlassian JIRA (v1000.571.2#100021)

1 0

[JIRA] (OVIRT-712) Use repoman extra sources feature in VDSM check merge
by eyal edri [Administrator] (oVirt JIRA) 28 Nov '16

28 Nov '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-712?page=com.atlassian.jira.p… ] eyal edri [Administrator] reassigned OVIRT-712: ----------------------------------------------- Assignee: Nadav Goldin (was: infra) Nadav, I think this is what you're doing now on the check-merged job right? > Use repoman extra sources feature in VDSM check merge > ------------------------------------------------------ > > Key: OVIRT-712 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-712 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Reporter: Gal Ben Haim > Assignee: Nadav Goldin > > When running check merge, new rpms with the latest patch are being generated. > currently those repos are being copied by reposync to /var/lib/lago/reposync. > Those rpms shouldn't be saved to the cache, thus we need to use repoman to include those rpms in the internal repo. -- This message was sent by Atlassian JIRA (v1000.571.2#100021)

1 0

[JIRA] (OVIRT-95) [jenkins] add job to run upgrade vdsm from version X to version Y
by eyal edri [Administrator] (oVirt JIRA) 28 Nov '16

28 Nov '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-95?page=com.atlassian.jira.pl… ] eyal edri [Administrator] commented on OVIRT-95: ------------------------------------------------ we'll implement this as part of #OVIRT-567, as second step for upgrading hypervisors after engine upgrade. > [jenkins] add job to run upgrade vdsm from version X to version Y > ----------------------------------------------------------------- > > Key: OVIRT-95 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-95 > Project: oVirt - virtualization made easy > Issue Type: Task > Components: Jenkins > Affects Versions: Test > Reporter: eyal edri [Administrator] > Assignee: infra > Priority: Lowest > Labels: infra,vdsm,jenkins > > vdsm upgrade should be tested. (following on bug that was found). > suggested flow: > 1. install vdsm version X (e.g from 3.2) > 2. build latest vdsm version (3.3 or master) > 3. yum update vdsm > 4. check if service is up and running. -- This message was sent by Atlassian JIRA (v1000.571.2#100021)

1 0

[JIRA] (OVIRT-95) [jenkins] add job to run upgrade vdsm from version X to version Y
by eyal edri [Administrator] (oVirt JIRA) 28 Nov '16

28 Nov '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-95?page=com.atlassian.jira.pl… ] eyal edri [Administrator] updated OVIRT-95: ------------------------------------------- Resolution: Duplicate Status: Done (was: To Do) > [jenkins] add job to run upgrade vdsm from version X to version Y > ----------------------------------------------------------------- > > Key: OVIRT-95 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-95 > Project: oVirt - virtualization made easy > Issue Type: Task > Components: Jenkins > Affects Versions: Test > Reporter: eyal edri [Administrator] > Assignee: infra > Priority: Lowest > Labels: infra,vdsm,jenkins > > vdsm upgrade should be tested. (following on bug that was found). > suggested flow: > 1. install vdsm version X (e.g from 3.2) > 2. build latest vdsm version (3.3 or master) > 3. yum update vdsm > 4. check if service is up and running. -- This message was sent by Atlassian JIRA (v1000.571.2#100021)

1 0

[JIRA] (OVIRT-753) ovirt-appliance_master_build-artifacts-el7-x86_64 is ignoring failed commands
by eyal edri [Administrator] (oVirt JIRA) 28 Nov '16

28 Nov '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-753?page=com.atlassian.jira.p… ] eyal edri [Administrator] commented on OVIRT-753: ------------------------------------------------- [~fdeutsch] this job is still not working, is it using the new experimental rpms? Anything infra team can help with? > ovirt-appliance_master_build-artifacts-el7-x86_64 is ignoring failed commands > ----------------------------------------------------------------------------- > > Key: OVIRT-753 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-753 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: sbonazzo > Assignee: infra > > In: > http://jenkins.ovirt.org/job/ovirt-appliance_master_build-artifacts-el7-x86… > After appliance shutdown: > *00:15:44.383* [[ -n "1" ]] && [[ "$(virt-sparsify --help)" =~ > --in-place ]] && ( virt-sparsify --in-place > ovirt-engine-appliance.qcow2 ; ln ovirt-engine-appliance.qcow2 > ovirt-engine-appliance.qcow2.sparse ; )*00:25:53.734* virt-sparsify: > error: libguestfs error: guestfs_launch failed.*00:25:53.735* This > usually means the libguestfs appliance failed to start or > crashed.*00:25:53.735* See > http://libguestfs.org/guestfs-faq.1.html#debugging-libguestfs*00:25:53.735* > or run 'libguestfs-test-tool' and post the *complete* output into > a*00:25:53.735* bug report or message to the libguestfs mailing list. > The job should have failed here. Instead, the job continues and fails in a > later stage: > *00:33:01.284* ls -shal ovirt-engine-appliance.ova*00:33:01.287* 1.4G > -rwxr-xr-x. 1 root root 1.4G Oct 6 14:13 > ovirt-engine-appliance.ova*00:33:01.288* echo "all" appliance > done*00:33:01.290* all appliance done*00:33:01.291* + make > check*00:33:01.299* make -f image-tools/build.mk > ovirt-engine-appliance-manifest-rpm*00:33:01.305* make[1]: Entering > directory `/home/jenkins/workspace/ovirt-appliance_master_build-artifacts-el7-x86_64/ovirt-appliance/engine-appliance'*00:33:01.305* > guestfish --ro -i -a ovirt-engine-appliance.qcow2 sh 'rpm -qa | sort > -u' > ovirt-engine-appliance-manifest-rpm*00:41:58.044* libguestfs: > error: appliance closed the connection unexpectedly.*00:41:58.044* > This usually means the libguestfs appliance crashed.*00:41:58.044* See > http://libguestfs.org/guestfs-faq.1.html#debugging-libguestfs*00:41:58.045* > for information about how to debug libguestfs and report > bugs.*00:41:58.045* libguestfs: error: guestfs_launch > failed.*00:41:58.045* This usually means the libguestfs appliance > failed to start or crashed.*00:41:58.045* See > http://libguestfs.org/guestfs-faq.1.html#debugging-libguestfs*00:41:58.046* > or run 'libguestfs-test-tool' and post the *complete* output into > a*00:41:58.046* bug report or message to the libguestfs mailing > list.*00:41:58.059* make[1]: *** [ovirt-engine-appliance-manifest-rpm] > Error 1*00:41:58.059* make[1]: Leaving directory > `/home/jenkins/workspace/ovirt-appliance_master_build-artifacts-el7-x86_64/ovirt-appliance/engine-appliance'*00:41:58.060* > make: *** [ovirt-engine-appliance-manifest-rpm] Error 2*00:41:58.065* > Took 2325 seconds > wasting 20 minutes of jenkins slave time testing something already known > broken. > While working on fixing this job, please investigate while it's failing and > open a separate issue or bugzilla for it. > -- > Sandro Bonazzola > Better technology. Faster innovation. Powered by community collaboration. > See how it works at redhat.com > <https://www.redhat.com/it/about/events/red-hat-open-source-day-2016> -- This message was sent by Atlassian JIRA (v1000.571.2#100021)

1 0

[JIRA] (OVIRT-869) Investigate proxy errors from proxy.phx.ovirt.org
by eyal edri [Administrator] (oVirt JIRA) 28 Nov '16

28 Nov '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-869?page=com.atlassian.jira.p… ] eyal edri [Administrator] reassigned OVIRT-869: ----------------------------------------------- Assignee: Evgheni Dereveanchin (was: infra) First priority should be fixing the DNS errors we see, second is to reinstall the service as Squid as we talked before and stop using the custom python script we have now. > Investigate proxy errors from proxy.phx.ovirt.org > ------------------------------------------------- > > Key: OVIRT-869 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-869 > Project: oVirt - virtualization made easy > Issue Type: Bug > Reporter: eyal edri [Administrator] > Assignee: Evgheni Dereveanchin > Priority: Highest > > We need to make sure jobs don't fail on proxy like [1]. > Either use original repos if proxy is down or add watchdog / alerts for the proxy service. > http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/3693/artif… -- This message was sent by Atlassian JIRA (v1000.571.2#100021)

1 0

[JIRA] (OVIRT-848) Add support for building containers in oVirt CI
by Barak Korren (oVirt JIRA) 28 Nov '16

28 Nov '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-848?page=com.atlassian.jira.p… ] Barak Korren commented on OVIRT-848: ------------------------------------ Some details and considerations about the interaction between containers (specifically Docker-based) and "Standard CI": There are two possible ways to use Docker from inside mock: # Install Docker inside the mock environment, and start up the Docker daemon inside it as well. # Install Docker on the slave VM (The host under mock), Docker client in the mock env, and bind-mount the docket socket ({{/var/run/docker.sock}}) into it. The obvious benefit of method #1 is that it does not require any adjustments to the existing CI infrastructure (We just need to teach devs how to implement it). I have doubts, however, that mock will not cause some difficulties with this (For example, are cgroups mounted inside mock?). We will need to test this and verify it works. Method #1 will also cause issues when we come around to implementing something like OVIRT-873 ([Nested Docker is possible but far from recommneded|https://jpetazzo.github.io/2015/09/03/do-not-use-docker-in-docker-for-ci/]) or do anything that causes us to run Docker on the hosts themselves. Method #2 will not have the same issues as method #1, but it will require us to distribute and maintain Docker on the slaves which is a step back to the pre-Standard-CI era. I think we should actually implement _both_ methods like this: # Try to mount the Docker socket into the mock env. # If it works use method #2 # If it doesn't, use method #1. This will require a little change to {{mock_runner.sh}} to allow bind mounts to be optional, but this change may provide other benefits so we may as well go for it. > Add support for building containers in oVirt CI > ----------------------------------------------- > > Key: OVIRT-848 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-848 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Reporter: eyal edri [Administrator] > Assignee: infra > > more and more projects in oVirt are starting to build containers and using Docker files in their reops. > We need to start preparing oVirt CI to know how to handle containers and support containers the same way we support rpms today. > This will be a parent task with multiple sub-tasks that will follow, the following is a draft list of what we might need to do to add this support: > # Install Registry server ( maybe use openshift.ovirt.org ) > # Add for standard CI 'build-containers.sh' support > # Add verification steps for the build before publishing to registry > # Look at 3rd party OSS projects that might help and integrate with existing solutions -- This message was sent by Atlassian JIRA (v1000.571.2#100021)

1 0