- Infra - oVirt List Archives

[JIRA] (OVIRT-837) artifactory /opt dir isn't monitored for space
by eyal edri [Administrator] (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-837?page=com.atlassian.jira.p… ] eyal edri [Administrator] reassigned OVIRT-837: ----------------------------------------------- Assignee: Evgheni Dereveanchin (was: infra) > artifactory /opt dir isn't monitored for space > ---------------------------------------------- > > Key: OVIRT-837 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-837 > Project: oVirt - virtualization made easy > Issue Type: Bug > Reporter: eyal edri [Administrator] > Assignee: Evgheni Dereveanchin > Priority: Highest > > Artifactory application is running on /opt and if the disk is full the application is failing to provide jars and gets very slow ( but errors on out of space are seen in the logs ). -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-896) Re: Jenkins issues
by eyal edri [Administrator] (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-896?page=com.atlassian.jira.p… ] eyal edri [Administrator] updated OVIRT-896: -------------------------------------------- Resolution: Duplicate Status: Done (was: To Do) duplicate of #OVIRT-909 > Re: Jenkins issues > ------------------ > > Key: OVIRT-896 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-896 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: eyal edri [Administrator] > Assignee: Shlomo Ben David > > better to send such info to infra-support to document as a ticket. ( adding > infra-support ) > On Thu, Dec 1, 2016 at 12:22 PM, Fabian Deutsch <fdeutsch(a)redhat.com> wrote: > > Hey, > > > > so - I have an issue > > this job: > > is often picking a wrong commit! > > http://jenkins.ovirt.org/user/fabiand/my-views/view/ovirt- > > node-ng/job/ovirt-node-ng_master_build-artifacts-el7- > > x86_64/219/consoleFull > > > > It says it resetted to master, but master is actually a different commit. > > I observed this a few times in the recent days. > > > > Does somebody have an idea why this could be happening? > > > > 00:00:02.156 Checking out Revision > > c1970c6f7a6404e8ab030147eec81233905345cf (origin/master) > > > > on my local host: > > $ git rev-parse FETCH_HEAD^{commit} # timeout=10 > > 9123c1fd3ce15b02f2e69efdc367ae1477193aef > > > > c1970c6f7a6404e8ab030147eec81233905345cf -- does actually no exist (in > > my history) > > > > - fabian > > > -- > Eyal Edri > Associate Manager > RHV DevOps > EMEA ENG Virtualization R&D > Red Hat Israel > phone: +972-9-7692018 > irc: eedri (on #tlv #rhev-dev #rhev-integ) -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-922) Add new project to standard ci from github
by Ondra Machacek (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-922?page=com.atlassian.jira.p… ] Ondra Machacek updated OVIRT-922: --------------------------------- Blocked By: OVIRT-874 Status: Blocked (was: To Do) > Add new project to standard ci from github > ------------------------------------------ > > Key: OVIRT-922 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-922 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: Jenkins > Reporter: Ondra Machacek > Assignee: infra > > I would like to request a jenkins machine for Ansible modules tests. > Those tests needs host with nested virtualization as it will create a few virtual machines for tests. > Actually, what I would need is similar machine which OST are using, but with preinstalled vagrant and ansible. > Then I would need some possibility to run this job from a hook from github, when new commit is pushed. > The tests are described here for an idea: > https://github.com/machacekondra/ovirt-tests > Would that be possible? -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-886) Yum install does not throw error on missing package
by Barak Korren (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-886?page=com.atlassian.jira.p… ] Barak Korren commented on OVIRT-886: ------------------------------------ Need to check if recent changes (see OVIRT-902) resolve this. > Yum install does not throw error on missing package > --------------------------------------------------- > > Key: OVIRT-886 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-886 > Project: oVirt - virtualization made easy > Issue Type: Bug > Reporter: Gil Shinar > Assignee: infra > > When running el7 mock on fc24 (not necessary the issue) and one of the required packages is missing because a repository in .repos hadn't been added, yum will not fail and the package will not be installed -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-884) check workspace cleanup task
by Barak Korren (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-884?page=com.atlassian.jira.p… ] Barak Korren commented on OVIRT-884: ------------------------------------ Isn't this a duplicate of OVIRT-909 ? > check workspace cleanup task > ---------------------------- > > Key: OVIRT-884 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-884 > Project: oVirt - virtualization made easy > Issue Type: Task > Components: Jenkins > Reporter: Evgheni Dereveanchin > Assignee: infra > > Recently we get lots of failures due to dirty workspaces on Jenkins slaves. > The cleanup task is reporting success, yet its runtime is usually below 1 second, so it may not be running properly and causing the failures: > http://jenkins.ovirt.org/job/system_cleanup-workspaces/5261/console > Need to check this job to ensure it actually cleans up workspaces. -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-922) Add new project to standard ci from github
by eyal edri [Administrator] (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-922?page=com.atlassian.jira.p… ] eyal edri [Administrator] updated OVIRT-922: -------------------------------------------- Epic Link: OVIRT-400 > Add new project to standard ci from github > ------------------------------------------ > > Key: OVIRT-922 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-922 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: Jenkins > Reporter: Ondra Machacek > Assignee: infra > > I would like to request a jenkins machine for Ansible modules tests. > Those tests needs host with nested virtualization as it will create a few virtual machines for tests. > Actually, what I would need is similar machine which OST are using, but with preinstalled vagrant and ansible. > Then I would need some possibility to run this job from a hook from github, when new commit is pushed. > The tests are described here for an idea: > https://github.com/machacekondra/ovirt-tests > Would that be possible? -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-920) Add a standard-CI job and button "build-scratch-artifacts"
by eyal edri [Administrator] (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-920?page=com.atlassian.jira.p… ] eyal edri [Administrator] updated OVIRT-920: -------------------------------------------- Epic Link: OVIRT-400 > Add a standard-CI job and button "build-scratch-artifacts" > ---------------------------------------------------------- > > Key: OVIRT-920 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-920 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Yedidyah Bar David > Assignee: infra > > Hi, > I think it will be useful to have an option to very easily (such as > pressing a button in gerrit) to do a full build of a project, > similarly to current build-artifacts, but for a pending patch - so it > will not be collected by any publisher, and will keep its artifacts > for a short time (say, 2 days). > This will allow to use these artifacts for manual tests, perhaps > longer than check-patch, in case a developer wants to do them. > -- > Didi -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-920) Add a standard-CI job and button "build-scratch-artifacts"
by eyal edri [Administrator] (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-920?page=com.atlassian.jira.p… ] eyal edri [Administrator] updated OVIRT-920: -------------------------------------------- Epic Link: OVIRT-400 > Add a standard-CI job and button "build-scratch-artifacts" > ---------------------------------------------------------- > > Key: OVIRT-920 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-920 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Yedidyah Bar David > Assignee: infra > > Hi, > I think it will be useful to have an option to very easily (such as > pressing a button in gerrit) to do a full build of a project, > similarly to current build-artifacts, but for a pending patch - so it > will not be collected by any publisher, and will keep its artifacts > for a short time (say, 2 days). > This will allow to use these artifacts for manual tests, perhaps > longer than check-patch, in case a developer wants to do them. > -- > Didi -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-922) Add new project to standard ci from github
by eyal edri [Administrator] (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-922?page=com.atlassian.jira.p… ] eyal edri [Administrator] updated OVIRT-922: -------------------------------------------- Epic Link: OVIRT-400 > Add new project to standard ci from github > ------------------------------------------ > > Key: OVIRT-922 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-922 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: Jenkins > Reporter: Ondra Machacek > Assignee: infra > > I would like to request a jenkins machine for Ansible modules tests. > Those tests needs host with nested virtualization as it will create a few virtual machines for tests. > Actually, what I would need is similar machine which OST are using, but with preinstalled vagrant and ansible. > Then I would need some possibility to run this job from a hook from github, when new commit is pushed. > The tests are described here for an idea: > https://github.com/machacekondra/ovirt-tests > Would that be possible? -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-911) Move repo closure to run in STD-CI
by eyal edri [Administrator] (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-911?page=com.atlassian.jira.p… ] eyal edri [Administrator] updated OVIRT-911: -------------------------------------------- Epic Link: OVIRT-400 > Move repo closure to run in STD-CI > ---------------------------------- > > Key: OVIRT-911 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-911 > Project: oVirt - virtualization made easy > Issue Type: Task > Reporter: Gil Shinar > Assignee: infra > > Repo closure jobs are currently running on VMs. > We would like to change these jobs to run inside mocks as STD-CI. -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-911) Move repo closure to run in STD-CI
by eyal edri [Administrator] (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-911?page=com.atlassian.jira.p… ] eyal edri [Administrator] updated OVIRT-911: -------------------------------------------- Epic Link: OVIRT-400 > Move repo closure to run in STD-CI > ---------------------------------- > > Key: OVIRT-911 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-911 > Project: oVirt - virtualization made easy > Issue Type: Task > Reporter: Gil Shinar > Assignee: infra > > Repo closure jobs are currently running on VMs. > We would like to change these jobs to run inside mocks as STD-CI. -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-919) Fwd: CI slaves extremely slow - overloaded slaves?
by eyal edri [Administrator] (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-919?page=com.atlassian.jira.p… ] eyal edri [Administrator] updated OVIRT-919: -------------------------------------------- Epic Link: OVIRT-403 > Fwd: CI slaves extremely slow - overloaded slaves? > -------------------------------------------------- > > Key: OVIRT-919 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-919 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Components: Jenkins > Reporter: Barak Korren > Assignee: infra > Labels: hypervisors, performance, slaves, standard-ci > > From: Nir Soffer <nsoffer(a)redhat.com> > Date: 7 December 2016 at 21:33 > Subject: CI slaves extremely slow - overloaded slaves? > To: infra <infra(a)ovirt.org>, Eyal Edri <eedri(a)redhat.com>, Dan > Kenigsberg <danken(a)redhat.com> > Hi all, > In the last weeks we see more and more test failures due to timeouts in the CI. > For example: > 17:19:49 ====================================================================== > 17:19:49 FAIL: test_scale (storage_filesd_test.GetAllVolumesTests) > 17:19:49 ---------------------------------------------------------------------- > 17:19:49 Traceback (most recent call last): > 17:19:49 File > "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/tests/storage_filesd_test.py", > line 165, in test_scale > 17:19:49 self.assertTrue(elapsed < 1.0, "Elapsed time: %f seconds" > % elapsed) > 17:19:49 AssertionError: Elapsed time: 1.105877 seconds > 17:19:49 -------------------- >> begin captured stdout << --------------------- > 17:19:49 1.105877 seconds > This test runs in 0.048 seconds on my laptop: > $ ./run_tests_local.sh storage_filesd_test.py -s > nose.config: INFO: Ignoring files matching ['^\\.', '^_', '^setup\\.py$'] > storage_filesd_test.GetAllVolumesTests > test_no_templates OK > test_no_volumes OK > test_scale 0.047932 seconds > OK > test_with_template OK > ---------------------------------------------------------------------- > Ran 4 tests in 0.189s > It seems that we are overloading the CI slaves. We should not use nested kvm > for the CI, such vms are much slower then regular vms, and we probably run > too many vms per cpu. > We can disable such tests in the CI, but we do want to know when there is > a regression in this code. Before it was fixed, the same test took 9 seconds > on my laptop. We need fast machines in the CI for this. > Nir -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-919) Fwd: CI slaves extremely slow - overloaded slaves?
by eyal edri [Administrator] (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-919?page=com.atlassian.jira.p… ] eyal edri [Administrator] reassigned OVIRT-919: ----------------------------------------------- Assignee: Evgheni Dereveanchin (was: infra) Epic Link: OVIRT-403 > Fwd: CI slaves extremely slow - overloaded slaves? > -------------------------------------------------- > > Key: OVIRT-919 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-919 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Components: Jenkins > Reporter: Barak Korren > Assignee: Evgheni Dereveanchin > Labels: hypervisors, performance, slaves, standard-ci > > From: Nir Soffer <nsoffer(a)redhat.com> > Date: 7 December 2016 at 21:33 > Subject: CI slaves extremely slow - overloaded slaves? > To: infra <infra(a)ovirt.org>, Eyal Edri <eedri(a)redhat.com>, Dan > Kenigsberg <danken(a)redhat.com> > Hi all, > In the last weeks we see more and more test failures due to timeouts in the CI. > For example: > 17:19:49 ====================================================================== > 17:19:49 FAIL: test_scale (storage_filesd_test.GetAllVolumesTests) > 17:19:49 ---------------------------------------------------------------------- > 17:19:49 Traceback (most recent call last): > 17:19:49 File > "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/tests/storage_filesd_test.py", > line 165, in test_scale > 17:19:49 self.assertTrue(elapsed < 1.0, "Elapsed time: %f seconds" > % elapsed) > 17:19:49 AssertionError: Elapsed time: 1.105877 seconds > 17:19:49 -------------------- >> begin captured stdout << --------------------- > 17:19:49 1.105877 seconds > This test runs in 0.048 seconds on my laptop: > $ ./run_tests_local.sh storage_filesd_test.py -s > nose.config: INFO: Ignoring files matching ['^\\.', '^_', '^setup\\.py$'] > storage_filesd_test.GetAllVolumesTests > test_no_templates OK > test_no_volumes OK > test_scale 0.047932 seconds > OK > test_with_template OK > ---------------------------------------------------------------------- > Ran 4 tests in 0.189s > It seems that we are overloading the CI slaves. We should not use nested kvm > for the CI, such vms are much slower then regular vms, and we probably run > too many vms per cpu. > We can disable such tests in the CI, but we do want to know when there is > a regression in this code. Before it was fixed, the same test took 9 seconds > on my laptop. We need fast machines in the CI for this. > Nir -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-904) False CI-1 due to unreachable copr-be.cloud.fedoraproject.org
by eyal edri [Administrator] (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-904?page=com.atlassian.jira.p… ] eyal edri [Administrator] updated OVIRT-904: -------------------------------------------- Epic Link: OVIRT-400 > False CI-1 due to unreachable copr-be.cloud.fedoraproject.org > ------------------------------------------------------------- > > Key: OVIRT-904 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-904 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: danken > Assignee: infra > > Many patches on > https://gerrit.ovirt.org/#/q/topic:passthroughMigration fail CI due to > failure: repodata/repomd.xml from patternfly: [Errno 256] No more > mirrors to try. > http://copr-be.cloud.fedoraproject.org/results/patternfly/patternfly1/epel-…: > [Errno 14] curl#7 - "Failed connect to > copr-be.cloud.fedoraproject.org:80; No route to host" > http://copr-be.cloud.fedoraproject.org/results/patternfly/patternfly1/epel-… -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-905) lago_master_check jobs still require fc23 slaves
by eyal edri [Administrator] (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-905?page=com.atlassian.jira.p… ] eyal edri [Administrator] updated OVIRT-905: -------------------------------------------- Epic Link: OVIRT-400 > lago_master_check jobs still require fc23 slaves > ------------------------------------------------ > > Key: OVIRT-905 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-905 > Project: oVirt - virtualization made easy > Issue Type: Task > Reporter: Evgheni Dereveanchin > Assignee: infra > > Lago check jobs require "nested && fc23" labels, and as Fedora 23 will be EOL in a couple of weeks we need to check if we can change this to newer Fedora versions or CentOS -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-905) lago_master_check jobs still require fc23 slaves
by eyal edri [Administrator] (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-905?page=com.atlassian.jira.p… ] eyal edri [Administrator] updated OVIRT-905: -------------------------------------------- Epic Link: OVIRT-400 > lago_master_check jobs still require fc23 slaves > ------------------------------------------------ > > Key: OVIRT-905 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-905 > Project: oVirt - virtualization made easy > Issue Type: Task > Reporter: Evgheni Dereveanchin > Assignee: infra > > Lago check jobs require "nested && fc23" labels, and as Fedora 23 will be EOL in a couple of weeks we need to check if we can change this to newer Fedora versions or CentOS -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-903) master-to-master CI upgrade tests
by eyal edri [Administrator] (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-903?page=com.atlassian.jira.p… ] eyal edri [Administrator] updated OVIRT-903: -------------------------------------------- Epic Link: OVIRT-400 > master-to-master CI upgrade tests > --------------------------------- > > Key: OVIRT-903 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-903 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Yedidyah Bar David > Assignee: infra > > Hi all, > Recently a patch to the engine [1] added a new package, > with a certain set of dependencies, which broke upgrade. > This is similar to [2] but for a new package. > CI wasn't affected, I think because of [3]. > To make CI test such flows, we should have a job that: > 1. Builds, installs and sets up the version we want to test > 2. Pushes a dummy change to the local git repo (to force > a new version), build the patched tree, create a yum repo > with the build and add it to yum.repos.d. > 3. yum update > 4. engine-setup > Another option is to revert [3], or to duplicate - have > both "upgrade current to self" and "upgrade latest snapshot > to current". The downside is that it will be checked later > than above plan - instead of in the same build, will only > be tested in the first build that uses the snapshot after > it was updated, and also will be misleading, as the reason > why that job failed will not be apparent (which was why > [3] was added). > Please handle. I can of course try to help. Best, > [1] https://gerrit.ovirt.org/66999 > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1321249 > [3] https://gerrit.ovirt.org/67263 > -- > Didi -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-904) False CI-1 due to unreachable copr-be.cloud.fedoraproject.org
by eyal edri [Administrator] (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-904?page=com.atlassian.jira.p… ] eyal edri [Administrator] updated OVIRT-904: -------------------------------------------- Epic Link: OVIRT-400 > False CI-1 due to unreachable copr-be.cloud.fedoraproject.org > ------------------------------------------------------------- > > Key: OVIRT-904 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-904 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: danken > Assignee: infra > > Many patches on > https://gerrit.ovirt.org/#/q/topic:passthroughMigration fail CI due to > failure: repodata/repomd.xml from patternfly: [Errno 256] No more > mirrors to try. > http://copr-be.cloud.fedoraproject.org/results/patternfly/patternfly1/epel-…: > [Errno 14] curl#7 - "Failed connect to > copr-be.cloud.fedoraproject.org:80; No route to host" > http://copr-be.cloud.fedoraproject.org/results/patternfly/patternfly1/epel-… -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-903) master-to-master CI upgrade tests
by eyal edri [Administrator] (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-903?page=com.atlassian.jira.p… ] eyal edri [Administrator] updated OVIRT-903: -------------------------------------------- Epic Link: OVIRT-400 > master-to-master CI upgrade tests > --------------------------------- > > Key: OVIRT-903 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-903 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Yedidyah Bar David > Assignee: infra > > Hi all, > Recently a patch to the engine [1] added a new package, > with a certain set of dependencies, which broke upgrade. > This is similar to [2] but for a new package. > CI wasn't affected, I think because of [3]. > To make CI test such flows, we should have a job that: > 1. Builds, installs and sets up the version we want to test > 2. Pushes a dummy change to the local git repo (to force > a new version), build the patched tree, create a yum repo > with the build and add it to yum.repos.d. > 3. yum update > 4. engine-setup > Another option is to revert [3], or to duplicate - have > both "upgrade current to self" and "upgrade latest snapshot > to current". The downside is that it will be checked later > than above plan - instead of in the same build, will only > be tested in the first build that uses the snapshot after > it was updated, and also will be misleading, as the reason > why that job failed will not be apparent (which was why > [3] was added). > Please handle. I can of course try to help. Best, > [1] https://gerrit.ovirt.org/66999 > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1321249 > [3] https://gerrit.ovirt.org/67263 > -- > Didi -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-900) Re: Rebase over other author's patch cannot be pushed to gerrit
by eyal edri [Administrator] (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-900?page=com.atlassian.jira.p… ] eyal edri [Administrator] updated OVIRT-900: -------------------------------------------- Epic Link: OVIRT-403 > Re: Rebase over other author's patch cannot be pushed to gerrit > --------------------------------------------------------------- > > Key: OVIRT-900 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-900 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Barak Korren > Assignee: Shlomo Ben David > > Forwarding to infra-support. > On 1 December 2016 at 18:03, Yaniv Bronheim <ybronhei(a)redhat.com> wrote: > > Not sure since when it was changed, but I noticed that I can't push patches > > if I'm not the author > > > > Counting objects: 50, done. > > Delta compression using up to 4 threads. > > Compressing objects: 100% (50/50), done. > > Writing objects: 100% (50/50), 36.66 KiB | 0 bytes/s, done. > > Total 50 (delta 34), reused 0 (delta 0) > > remote: Resolving deltas: 100% (34/34) > > remote: Processing changes: refs: 1, done > > remote: > > remote: ERROR: In commit db14ec7c1555a9eb37a0fb931bbb4ebdfc674bb4 > > remote: ERROR: author email address rnachimu(a)redhat.com > > remote: ERROR: does not match your user account. > > remote: ERROR: > > remote: ERROR: The following addresses are currently registered: > > remote: ERROR: bronhaim(a)gmail.com > > remote: ERROR: ybronhei(a)redhat.com > > remote: ERROR: > > remote: ERROR: To register an email address, please visit: > > remote: ERROR: https://gerrit.ovirt.org/#/settings/contact > > remote: > > remote: > > To ssh://ybronhei@gerrit.ovirt.org:29418/vdsm > > ! [remote rejected] HEAD -> refs/for/master (invalid author) > > error: failed to push some refs to > > 'ssh://ybronhei@gerrit.ovirt.org:29418/vdsm' > > > > We must have permissions to do that, this is part of the rebasing part, and > > I think its fine to fix patches on behalf of someone else.. but its not the > > best practice for reviewing. > > anyway, please undo this change, unless its something that related only to > > my env.. let me know > > > > Thanks > > > > -- > > Yaniv Bronhaim. > > > > _______________________________________________ > > Infra mailing list > > Infra(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/infra > > > -- > Barak Korren > bkorren(a)redhat.com > RHCE, RHCi, RHV-DevOps Team > https://ifireball.wordpress.com/ -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-900) Re: Rebase over other author's patch cannot be pushed to gerrit
by eyal edri [Administrator] (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-900?page=com.atlassian.jira.p… ] eyal edri [Administrator] updated OVIRT-900: -------------------------------------------- Epic Link: OVIRT-403 > Re: Rebase over other author's patch cannot be pushed to gerrit > --------------------------------------------------------------- > > Key: OVIRT-900 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-900 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Barak Korren > Assignee: Shlomo Ben David > > Forwarding to infra-support. > On 1 December 2016 at 18:03, Yaniv Bronheim <ybronhei(a)redhat.com> wrote: > > Not sure since when it was changed, but I noticed that I can't push patches > > if I'm not the author > > > > Counting objects: 50, done. > > Delta compression using up to 4 threads. > > Compressing objects: 100% (50/50), done. > > Writing objects: 100% (50/50), 36.66 KiB | 0 bytes/s, done. > > Total 50 (delta 34), reused 0 (delta 0) > > remote: Resolving deltas: 100% (34/34) > > remote: Processing changes: refs: 1, done > > remote: > > remote: ERROR: In commit db14ec7c1555a9eb37a0fb931bbb4ebdfc674bb4 > > remote: ERROR: author email address rnachimu(a)redhat.com > > remote: ERROR: does not match your user account. > > remote: ERROR: > > remote: ERROR: The following addresses are currently registered: > > remote: ERROR: bronhaim(a)gmail.com > > remote: ERROR: ybronhei(a)redhat.com > > remote: ERROR: > > remote: ERROR: To register an email address, please visit: > > remote: ERROR: https://gerrit.ovirt.org/#/settings/contact > > remote: > > remote: > > To ssh://ybronhei@gerrit.ovirt.org:29418/vdsm > > ! [remote rejected] HEAD -> refs/for/master (invalid author) > > error: failed to push some refs to > > 'ssh://ybronhei@gerrit.ovirt.org:29418/vdsm' > > > > We must have permissions to do that, this is part of the rebasing part, and > > I think its fine to fix patches on behalf of someone else.. but its not the > > best practice for reviewing. > > anyway, please undo this change, unless its something that related only to > > my env.. let me know > > > > Thanks > > > > -- > > Yaniv Bronhaim. > > > > _______________________________________________ > > Infra mailing list > > Infra(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/infra > > > -- > Barak Korren > bkorren(a)redhat.com > RHCE, RHCi, RHV-DevOps Team > https://ifireball.wordpress.com/ -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-895) mailing list memberships reminder - do we need that?
by eyal edri [Administrator] (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-895?page=com.atlassian.jira.p… ] eyal edri [Administrator] updated OVIRT-895: -------------------------------------------- Epic Link: OVIRT-403 > mailing list memberships reminder - do we need that? > ---------------------------------------------------- > > Key: OVIRT-895 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-895 > Project: oVirt - virtualization made easy > Issue Type: Task > Reporter: Evgheni Dereveanchin > Assignee: infra > Priority: Low > > I'm subscribed to a bunch of lists and every month I get membership reminder emails. Do we have them for a reason? If not - I'd like to disable them (can be done per-list in the settings or globally across the Mailman instance) -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-895) mailing list memberships reminder - do we need that?
by eyal edri [Administrator] (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-895?page=com.atlassian.jira.p… ] eyal edri [Administrator] updated OVIRT-895: -------------------------------------------- Epic Link: OVIRT-403 I don't have strong feeling about it, you can disable it from the mailman setting if you'd like. > mailing list memberships reminder - do we need that? > ---------------------------------------------------- > > Key: OVIRT-895 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-895 > Project: oVirt - virtualization made easy > Issue Type: Task > Reporter: Evgheni Dereveanchin > Assignee: infra > Priority: Low > > I'm subscribed to a bunch of lists and every month I get membership reminder emails. Do we have them for a reason? If not - I'd like to disable them (can be done per-list in the settings or globally across the Mailman instance) -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-896) Re: Jenkins issues
by eyal edri [Administrator] (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-896?page=com.atlassian.jira.p… ] eyal edri [Administrator] commented on OVIRT-896: ------------------------------------------------- [~fdeutsch] is this is the same issue with errors on git clones? If so, its a duplicate on another ticket we're tracking the fix there. > Re: Jenkins issues > ------------------ > > Key: OVIRT-896 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-896 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: eyal edri [Administrator] > Assignee: Shlomo Ben David > > better to send such info to infra-support to document as a ticket. ( adding > infra-support ) > On Thu, Dec 1, 2016 at 12:22 PM, Fabian Deutsch <fdeutsch(a)redhat.com> wrote: > > Hey, > > > > so - I have an issue > > this job: > > is often picking a wrong commit! > > http://jenkins.ovirt.org/user/fabiand/my-views/view/ovirt- > > node-ng/job/ovirt-node-ng_master_build-artifacts-el7- > > x86_64/219/consoleFull > > > > It says it resetted to master, but master is actually a different commit. > > I observed this a few times in the recent days. > > > > Does somebody have an idea why this could be happening? > > > > 00:00:02.156 Checking out Revision > > c1970c6f7a6404e8ab030147eec81233905345cf (origin/master) > > > > on my local host: > > $ git rev-parse FETCH_HEAD^{commit} # timeout=10 > > 9123c1fd3ce15b02f2e69efdc367ae1477193aef > > > > c1970c6f7a6404e8ab030147eec81233905345cf -- does actually no exist (in > > my history) > > > > - fabian > > > -- > Eyal Edri > Associate Manager > RHV DevOps > EMEA ENG Virtualization R&D > Red Hat Israel > phone: +972-9-7692018 > irc: eedri (on #tlv #rhev-dev #rhev-integ) -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-886) Yum install does not throw error on missing package
by eyal edri [Administrator] (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-886?page=com.atlassian.jira.p… ] eyal edri [Administrator] updated OVIRT-886: -------------------------------------------- Epic Link: OVIRT-400 > Yum install does not throw error on missing package > --------------------------------------------------- > > Key: OVIRT-886 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-886 > Project: oVirt - virtualization made easy > Issue Type: Bug > Reporter: Gil Shinar > Assignee: infra > > When running el7 mock on fc24 (not necessary the issue) and one of the required packages is missing because a repository in .repos hadn't been added, yum will not fail and the package will not be installed -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-886) Yum install does not throw error on missing package
by eyal edri [Administrator] (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-886?page=com.atlassian.jira.p… ] eyal edri [Administrator] updated OVIRT-886: -------------------------------------------- Epic Link: OVIRT-400 > Yum install does not throw error on missing package > --------------------------------------------------- > > Key: OVIRT-886 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-886 > Project: oVirt - virtualization made easy > Issue Type: Bug > Reporter: Gil Shinar > Assignee: infra > > When running el7 mock on fc24 (not necessary the issue) and one of the required packages is missing because a repository in .repos hadn't been added, yum will not fail and the package will not be installed -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-884) check workspace cleanup task
by eyal edri [Administrator] (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-884?page=com.atlassian.jira.p… ] eyal edri [Administrator] updated OVIRT-884: -------------------------------------------- Epic Link: OVIRT-403 > check workspace cleanup task > ---------------------------- > > Key: OVIRT-884 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-884 > Project: oVirt - virtualization made easy > Issue Type: Task > Components: Jenkins > Reporter: Evgheni Dereveanchin > Assignee: infra > > Recently we get lots of failures due to dirty workspaces on Jenkins slaves. > The cleanup task is reporting success, yet its runtime is usually below 1 second, so it may not be running properly and causing the failures: > http://jenkins.ovirt.org/job/system_cleanup-workspaces/5261/console > Need to check this job to ensure it actually cleans up workspaces. -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-884) check workspace cleanup task
by eyal edri [Administrator] (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-884?page=com.atlassian.jira.p… ] eyal edri [Administrator] updated OVIRT-884: -------------------------------------------- Epic Link: OVIRT-403 > check workspace cleanup task > ---------------------------- > > Key: OVIRT-884 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-884 > Project: oVirt - virtualization made easy > Issue Type: Task > Components: Jenkins > Reporter: Evgheni Dereveanchin > Assignee: infra > > Recently we get lots of failures due to dirty workspaces on Jenkins slaves. > The cleanup task is reporting success, yet its runtime is usually below 1 second, so it may not be running properly and causing the failures: > http://jenkins.ovirt.org/job/system_cleanup-workspaces/5261/console > Need to check this job to ensure it actually cleans up workspaces. -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-867) Re: [oVirt Jenkins] repos_3.6_check-closure_el7_merged - Build # 92 - Still Failing!
by eyal edri [Administrator] (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-867?page=com.atlassian.jira.p… ] eyal edri [Administrator] updated OVIRT-867: -------------------------------------------- Resolution: Fixed Status: Done (was: To Do) job is back to stable after removing bad mirror, there is another task to move these to standard CI so they can benefit from the proxy as well > Re: [oVirt Jenkins] repos_3.6_check-closure_el7_merged - Build # 92 - Still Failing! > ------------------------------------------------------------------------------------ > > Key: OVIRT-867 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-867 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: sbonazzo > Assignee: Evgheni Dereveanchin > > *00:01:53.955* Can't download or revert repomd.xml for > check-epel-el7*00:01:53.955* Some dependencies may not be complete for > this repository*00:01:53.956* Run as root to get all dependencies or > use -t to enable a user temp cache > Can you check? looks like it's not possible to update local cache of metadata. > On Fri, Nov 25, 2016 at 1:07 PM, <jenkins(a)jenkins.phx.ovirt.org> wrote: > > Project: http://jenkins.ovirt.org/job/repos_3.6_check-closure_el7_merged/ > > Build: http://jenkins.ovirt.org/job/repos_3.6_check-closure_el7_merged/92/ > > Build Number: 92 > > Build Status: Still Failing > > Triggered By: Started by user Sandro Bonazzola > > > > ------------------------------------- > > Changes Since Last Success: > > ------------------------------------- > > Changes for Build #89 > > [Eyal Edri] deploy ovirt-engine-cli 3.6 to 4.0 and master repos as well > > > > [Yedidyah Bar David] master_upgrade_from_master: Upgrade to self instead > > of snapshot > > > > > > Changes for Build #90 > > No changes > > > > Changes for Build #91 > > No changes > > > > Changes for Build #92 > > No changes > > > > > > > > ----------------- > > Failed Tests: > > ----------------- > > No tests ran. > > > > > > _______________________________________________ > > Infra mailing list > > Infra(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/infra > > > > > -- > Sandro Bonazzola > Better technology. Faster innovation. Powered by community collaboration. > See how it works at redhat.com -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-922) Add new project to standard ci from github
by eyal edri [Administrator] (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-922?page=com.atlassian.jira.p… ] eyal edri [Administrator] commented on OVIRT-922: ------------------------------------------------- Also, can you rename the repo to something with more context? ovirt-tests is very generic name ( we have system tests / functional tests/ unit tests ). If its ansbile, maybe worth calling it ovirt-ansible-tests or something else with ansible ) > Add new project to standard ci from github > ------------------------------------------ > > Key: OVIRT-922 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-922 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: Jenkins > Reporter: Ondra Machacek > Assignee: infra > > I would like to request a jenkins machine for Ansible modules tests. > Those tests needs host with nested virtualization as it will create a few virtual machines for tests. > Actually, what I would need is similar machine which OST are using, but with preinstalled vagrant and ansible. > Then I would need some possibility to run this job from a hook from github, when new commit is pushed. > The tests are described here for an idea: > https://github.com/machacekondra/ovirt-tests > Would that be possible? -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-898) Send committers in test experimental job's email
by eyal edri [Administrator] (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-898?page=com.atlassian.jira.p… ] eyal edri [Administrator] reassigned OVIRT-898: ----------------------------------------------- Assignee: Daniel Belenky (was: infra) > Send committers in test experimental job's email > ------------------------------------------------ > > Key: OVIRT-898 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-898 > Project: oVirt - virtualization made easy > Issue Type: Task > Reporter: Gil Shinar > Assignee: Daniel Belenky > > I can get the job that triggered deploy experimental and test experimental and get commiters from that job. -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-922) Add new project to standard ci from github
by eyal edri [Administrator] (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-922?page=com.atlassian.jira.p… ] eyal edri [Administrator] updated OVIRT-922: -------------------------------------------- Summary: Add new project to standard ci from github (was: Please create new jenkins machine for Ansible modules tests) > Add new project to standard ci from github > ------------------------------------------ > > Key: OVIRT-922 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-922 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: Jenkins > Reporter: Ondra Machacek > Assignee: infra > > I would like to request a jenkins machine for Ansible modules tests. > Those tests needs host with nested virtualization as it will create a few virtual machines for tests. > Actually, what I would need is similar machine which OST are using, but with preinstalled vagrant and ansible. > Then I would need some possibility to run this job from a hook from github, when new commit is pushed. > The tests are described here for an idea: > https://github.com/machacekondra/ovirt-tests > Would that be possible? -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-922) Please create new jenkins machine for Ansible modules tests
by eyal edri [Administrator] (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-922?page=com.atlassian.jira.p… ] eyal edri [Administrator] commented on OVIRT-922: ------------------------------------------------- We don't maintain 'special' machines or mange them with any CM tools like we did in the past, instead we use mock to give an isolated environment for any testing you'd like to run and you have full control over what is running there. You will need to make your project part of the 'standard ci' flow and add automation dir under the root folder. ( see other projects for e.g, like ovirt-engine ). see [1] for detailed info. But, as an example, you said you need vagrant and ansible installed, then you'll just need to add them to the .packages file in the automation dir under check-patch or check-merge depends on when you want it tested. We don't support yet GitHub as a standard CI project, there is another ticket to add support for it ( as part of adding ovirt-web-ui project ), so it might take bit more time. (for projects in Gerrit is straightforward now) [1] http://infra-docs.readthedocs.io/en/latest/CI/Build_and_test_standards.html > Please create new jenkins machine for Ansible modules tests > ----------------------------------------------------------- > > Key: OVIRT-922 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-922 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: Jenkins > Reporter: Ondra Machacek > Assignee: infra > > I would like to request a jenkins machine for Ansible modules tests. > Those tests needs host with nested virtualization as it will create a few virtual machines for tests. > Actually, what I would need is similar machine which OST are using, but with preinstalled vagrant and ansible. > Then I would need some possibility to run this job from a hook from github, when new commit is pushed. > The tests are described here for an idea: > https://github.com/machacekondra/ovirt-tests > Would that be possible? -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-922) Please create new jenkins machine for Ansible modules tests
by Ondra Machacek (oVirt JIRA) 08 Dec '16

08 Dec '16

Ondra Machacek created OVIRT-922: ------------------------------------ Summary: Please create new jenkins machine for Ansible modules tests Key: OVIRT-922 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-922 Project: oVirt - virtualization made easy Issue Type: New Feature Components: Jenkins Reporter: Ondra Machacek Assignee: infra I would like to request a jenkins machine for Ansible modules tests. Those tests needs host with nested virtualization as it will create a few virtual machines for tests. Actually, what I would need is similar machine which OST are using, but with preinstalled vagrant and ansible. Then I would need some possibility to run this job from a hook from github, when new commit is pushed. The tests are described here for an idea: https://github.com/machacekondra/ovirt-tests Would that be possible? -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-922) Please create new jenkins machine for Ansible modules tests
by Ondra Machacek (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-922?page=com.atlassian.jira.p… ] Ondra Machacek commented on OVIRT-922: -------------------------------------- CC [~mperina] [~oourfali(a)redhat.com] > Please create new jenkins machine for Ansible modules tests > ----------------------------------------------------------- > > Key: OVIRT-922 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-922 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: Jenkins > Reporter: Ondra Machacek > Assignee: infra > > I would like to request a jenkins machine for Ansible modules tests. > Those tests needs host with nested virtualization as it will create a few virtual machines for tests. > Actually, what I would need is similar machine which OST are using, but with preinstalled vagrant and ansible. > Then I would need some possibility to run this job from a hook from github, when new commit is pushed. > The tests are described here for an idea: > https://github.com/machacekondra/ovirt-tests > Would that be possible? -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-908) jenkins failures
by eyal edri [Administrator] (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-908?page=com.atlassian.jira.p… ] eyal edri [Administrator] reassigned OVIRT-908: ----------------------------------------------- Assignee: Shlomo Ben David (was: infra) > jenkins failures > ---------------- > > Key: OVIRT-908 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-908 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Martin Polednik > Assignee: Shlomo Ben David > > Hi, > after pushing update to my patch series[1], I've been greeted with > unhealthy amount of jenkins failures. Actually, it's a single fail > that affected all but one(!) patch. > The failure: ERROR: Command failed. See logs for output. [2] > Can we get these issues solved or have some > false-positive/false-negative protection (preferably both)? > [1] https://gerrit.ovirt.org/#/q/topic:hostdev-caching > [2] http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc24-x86_64/5788/conso… > Regards, > mpolednik -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-899) Create locking on experimental flow
by Gil Shinar (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-899?page=com.atlassian.jira.p… ] Gil Shinar reassigned OVIRT-899: -------------------------------- Assignee: Daniel Belenky (was: infra) > Create locking on experimental flow > ----------------------------------- > > Key: OVIRT-899 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-899 > Project: oVirt - virtualization made easy > Issue Type: Task > Reporter: Gil Shinar > Assignee: Daniel Belenky > > In order to make experimental flow atomic, we need to do as follows: > in deploy.sh script and in start_testing_latest.sh we need to add a loop in the beginning of each script that does the following: > *while 1: > do > is_locked=$((echo aaa > my.lock) 2> /dev/null || echo is locked) > if [[ -z $is_locked ]]; then > break > else > sleep 5 > fi > done* > Wrap the whole script with a trap so in the end if each script we will be able to remove my.lock no matter what happened. -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-921) Smarter cache handling for mock_runner.sh
by Barak Korren (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-921?page=com.atlassian.jira.p… ] Barak Korren updated OVIRT-921: ------------------------------- Labels: mock mock_runner.sh performance standard-ci (was: ) > Smarter cache handling for mock_runner.sh > ----------------------------------------- > > Key: OVIRT-921 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-921 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Jenkins > Reporter: Barak Korren > Assignee: infra > Labels: mock, mock_runner.sh, performance, standard-ci > > We've improved our handing of mock caches in OVIRT-902, but it could be better. > Right now we're just deleting everything from {{mock_cleanup.sh}} every two days, but we could do things in a smarter and more refined way: > * Mock actually has two separate caches that could be handled separately: > *# The yum cache - Caches package that are installed in the chroot > *# The root cache - Keeps an archive of the whole chroot > * We can make the yum cache shared by all the chroots that use the same repos > * We can keep the yum cache for much longer since 'yum' will refresh it automatically. We can tune this from mock root config file: > ** {{config_opts\['plugin_conf']\['yum_cache_opts']\['max_age_days']}} > ** {{config_opts\['plugin_conf']\['yum_cache_opts']\['max_metadata_age_days']}} > * We can also control the chroot cache from the mock config file, this will allow us greated flexibility, like deciding that some chroots live longer: > ** {{config_opts\['plugin_conf']\['root_cache_opts']\['max_age_days']}} > * We can use a different compression algorithm for the chroot acche, this may yield better performance. > * We still need some cleanup in {{moch_cleanup.sh}} but only for chroot caches that ahvn't been in use for a long time. -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-921) Smarter cache handling for mock_runner.sh
by Barak Korren (oVirt JIRA) 08 Dec '16

08 Dec '16

Barak Korren created OVIRT-921: ---------------------------------- Summary: Smarter cache handling for mock_runner.sh Key: OVIRT-921 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-921 Project: oVirt - virtualization made easy Issue Type: Improvement Components: Jenkins Reporter: Barak Korren Assignee: infra We've improved our handing of mock caches in OVIRT-902, but it could be better. Right now we're just deleting everything from {{mock_cleanup.sh}} every two days, but we could do things in a smarter and more refined way: * Mock actually has two separate caches that could be handled separately: *# The yum cache - Caches package that are installed in the chroot *# The root cache - Keeps an archive of the whole chroot * We can make the yum cache shared by all the chroots that use the same repos * We can keep the yum cache for much longer since 'yum' will refresh it automatically. We can tune this from mock root config file: ** {{config_opts\['plugin_conf']\['yum_cache_opts']\['max_age_days']}} ** {{config_opts\['plugin_conf']\['yum_cache_opts']\['max_metadata_age_days']}} * We can also control the chroot cache from the mock config file, this will allow us greated flexibility, like deciding that some chroots live longer: ** {{config_opts\['plugin_conf']\['root_cache_opts']\['max_age_days']}} * We can use a different compression algorithm for the chroot acche, this may yield better performance. * We still need some cleanup in {{moch_cleanup.sh}} but only for chroot caches that ahvn't been in use for a long time. -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-921) Smarter cache handling for mock_runner.sh
by Barak Korren (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-921?page=com.atlassian.jira.p… ] Barak Korren updated OVIRT-921: ------------------------------- Epic Link: OVIRT-400 > Smarter cache handling for mock_runner.sh > ----------------------------------------- > > Key: OVIRT-921 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-921 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Jenkins > Reporter: Barak Korren > Assignee: infra > Labels: mock, mock_runner.sh, performance, standard-ci > > We've improved our handing of mock caches in OVIRT-902, but it could be better. > Right now we're just deleting everything from {{mock_cleanup.sh}} every two days, but we could do things in a smarter and more refined way: > * Mock actually has two separate caches that could be handled separately: > *# The yum cache - Caches package that are installed in the chroot > *# The root cache - Keeps an archive of the whole chroot > * We can make the yum cache shared by all the chroots that use the same repos > * We can keep the yum cache for much longer since 'yum' will refresh it automatically. We can tune this from mock root config file: > ** {{config_opts\['plugin_conf']\['yum_cache_opts']\['max_age_days']}} > ** {{config_opts\['plugin_conf']\['yum_cache_opts']\['max_metadata_age_days']}} > * We can also control the chroot cache from the mock config file, this will allow us greated flexibility, like deciding that some chroots live longer: > ** {{config_opts\['plugin_conf']\['root_cache_opts']\['max_age_days']}} > * We can use a different compression algorithm for the chroot acche, this may yield better performance. > * We still need some cleanup in {{moch_cleanup.sh}} but only for chroot caches that ahvn't been in use for a long time. -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-830) Vdsm lost its "Forge Author" permission?
by Shlomo Ben David (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-830?page=com.atlassian.jira.p… ] Shlomo Ben David reassigned OVIRT-830: -------------------------------------- Assignee: Shlomo Ben David (was: infra) > Vdsm lost its "Forge Author" permission? > ---------------------------------------- > > Key: OVIRT-830 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-830 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: danken > Assignee: Shlomo Ben David > > Until recently, any registered user could take on somebody else's change, > and post a new patchset to it. > It's very useful when someone wants to fix a typo in someone else's > code, or when we need to take on a work of a sick/vacating developer. > Please amend this. I'm not 100% sure, but it could be fix by setting > "Forge Author" on the vdsm project. > https://gerrit-review.googlesource.com/Documentation/access-control.html#ca… -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-907) Add CI for mock_runner.sh
by Barak Korren (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-907?page=com.atlassian.jira.p… ] Barak Korren commented on OVIRT-907: ------------------------------------ This was partially done here: https://gerrit.ovirt.org/#/c/67802 Still missing: * Other arch tests (We will need to resolve OVIRT-914 for this) * More tests (For example verify that all packages from the "{{*.packages}}" file were installed. > Add CI for mock_runner.sh > ------------------------- > > Key: OVIRT-907 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-907 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Jenkins > Reporter: Barak Korren > Assignee: infra > > We have some CI jobs running on our "Jenkins" repo right now. Those jobs mostly check YAML, but they are also useful for checking changes to mock_runner.sh because they are running inside it. However: > # These jobs do a full YAML check even when it is not needed. > # We're not actually checking mock_runner.sh for all the platforms it simulates. > We've already seem some regressions happen in the CI system because we don't have enough tests for mock_runner.sh > This ticket is for creating good CI coverage for mock_runner.sh, all that is needed to be done in practice is make some changes to the check_patch.sh script and the YAML so that: > * YAML checking is skipped if no JJB-related changes were done > * Various features of mock_runner like the installation of packages for the *.packages files are checked. > * The tests are ran for all platforms that mock_runner.sh supports. -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-830) Vdsm lost its "Forge Author" permission?
by eyal edri [Administrator] (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-830?page=com.atlassian.jira.p… ] eyal edri [Administrator] updated OVIRT-830: -------------------------------------------- Resolution: Fixed Status: Done (was: To Do) permission updated to work for all registered users. > Vdsm lost its "Forge Author" permission? > ---------------------------------------- > > Key: OVIRT-830 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-830 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: danken > Assignee: infra > > Until recently, any registered user could take on somebody else's change, > and post a new patchset to it. > It's very useful when someone wants to fix a typo in someone else's > code, or when we need to take on a work of a sick/vacating developer. > Please amend this. I'm not 100% sure, but it could be fix by setting > "Forge Author" on the vdsm project. > https://gerrit-review.googlesource.com/Documentation/access-control.html#ca… -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-828) ovirt-engine_master_check-patch-fc24-x86_64 failing
by eyal edri [Administrator] (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-828?page=com.atlassian.jira.p… ] eyal edri [Administrator] updated OVIRT-828: -------------------------------------------- Resolution: Cannot Reproduce Status: Done (was: To Do) job history is deleted already and didn't got a response on this ticket. feel free to open is issue persists. > ovirt-engine_master_check-patch-fc24-x86_64 failing > --------------------------------------------------- > > Key: OVIRT-828 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-828 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Greg Sheremeta > Assignee: infra > > http://jenkins.ovirt.org/job/ovirt-engine_master_check-patch-fc24-x86_64/68… > Doesn't appear related to the patch. > > > > 17:52:04 Finish: cleaning yum metadata > > 17:52:04 Mock Version: 1.2.21 > > 17:52:04 INFO: Mock Version: 1.2.21 > > 17:52:04 Start: yum install > > 17:52:09 ERROR: Command failed. See logs for output. > > 17:52:09 # /usr/bin/yum-deprecated --installroot > > /var/lib/mock/fedora-24-x86_64-a84bda050a5e85bcae66e67894bf5f93-17376/root/ > > --releasever 24 install @buildsys-build --setopt=tsflags=nocontexts > > 17:52:09 Init took 6 seconds > Thanks, > Greg > -- > Greg Sheremeta, MBA > Red Hat, Inc. > Sr. Software Engineer > gshereme(a)redhat.com -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-920) Add a standard-CI job and button "build-scratch-artifacts"
by eyal edri [Administrator] (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-920?page=com.atlassian.jira.p… ] eyal edri [Administrator] commented on OVIRT-920: ------------------------------------------------- the hooks triggering is totally different system ( gerrit hooks internal ) and yes, the comments are not functional and we should probably fix them. What I suggested is to use the Jenkins Gerrit Trigger capabilities, so it won't suffer from the same problem. > Add a standard-CI job and button "build-scratch-artifacts" > ---------------------------------------------------------- > > Key: OVIRT-920 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-920 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Yedidyah Bar David > Assignee: infra > > Hi, > I think it will be useful to have an option to very easily (such as > pressing a button in gerrit) to do a full build of a project, > similarly to current build-artifacts, but for a pending patch - so it > will not be collected by any publisher, and will keep its artifacts > for a short time (say, 2 days). > This will allow to use these artifacts for manual tests, perhaps > longer than check-patch, in case a developer wants to do them. > -- > Didi -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-904) False CI-1 due to unreachable copr-be.cloud.fedoraproject.org
by Barak Korren (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-904?page=com.atlassian.jira.p… ] Barak Korren edited comment on OVIRT-904 at 12/8/16 10:36 AM: -------------------------------------------------------------- [~gshereme(a)redhat.com] are you doing that manually, or do you have some automation built around it? I'm not sure oVirt's own infra would be the best place, because Patternfly is not strictly an oVirt project. Perhaps make travis run the build in Copr, and then take the result and push it to GitHub's artifact storage? Another possibility is to use [BinTray|https://bintray.com/] We might eventually mirror this in oVirt infra to make CI resilient to changes there (see OVIRT-575) was (Author: bkorren(a)redhat.com) [~gshereme(a)redhat.com] are you dong that manually, or do you have some automation built around it? I'm not sure oVirt's own infra would be the best place, because Patternfly is not strictly an oVirt project. Perhaps make travis run the build in Copr, and then take the result and push it to GitHub's artifact storage? Another possibility is to use [BinTray|https://bintray.com/] We might eventually mirror this in oVirt infra to make CI resilient to changes there (see OVIRT-575) > False CI-1 due to unreachable copr-be.cloud.fedoraproject.org > ------------------------------------------------------------- > > Key: OVIRT-904 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-904 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: danken > Assignee: infra > > Many patches on > https://gerrit.ovirt.org/#/q/topic:passthroughMigration fail CI due to > failure: repodata/repomd.xml from patternfly: [Errno 256] No more > mirrors to try. > http://copr-be.cloud.fedoraproject.org/results/patternfly/patternfly1/epel-…: > [Errno 14] curl#7 - "Failed connect to > copr-be.cloud.fedoraproject.org:80; No route to host" > http://copr-be.cloud.fedoraproject.org/results/patternfly/patternfly1/epel-… -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-920) Add a standard-CI job and button "build-scratch-artifacts"
by Yedidyah Bar David (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-920?page=com.atlassian.jira.p… ] Yedidyah Bar David commented on OVIRT-920: ------------------------------------------ On Thu, Dec 8, 2016 at 10:13 AM, eyal edri [Administrator] (oVirt JIRA) < Fine with me, but then please add to the page a link somewhere to the list of possible commands. I commented "Rerun-Hooks: all" tens of times so far, and in each and every one of them had to search for the exact syntax - never managed to memorize it. -- Didi > Add a standard-CI job and button "build-scratch-artifacts" > ---------------------------------------------------------- > > Key: OVIRT-920 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-920 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Yedidyah Bar David > Assignee: infra > > Hi, > I think it will be useful to have an option to very easily (such as > pressing a button in gerrit) to do a full build of a project, > similarly to current build-artifacts, but for a pending patch - so it > will not be collected by any publisher, and will keep its artifacts > for a short time (say, 2 days). > This will allow to use these artifacts for manual tests, perhaps > longer than check-patch, in case a developer wants to do them. > -- > Didi -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-920) Add a standard-CI job and button "build-scratch-artifacts"
by eyal edri [Administrator] (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-920?page=com.atlassian.jira.p… ] eyal edri [Administrator] commented on OVIRT-920: ------------------------------------------------- We might be able to do it but not with a button, but with a comment, similar to what GitHub has ( for e.g in Lago we do "ci test please" to run a job on PR ). This still needs checking, but it might be possible via adding new 'build-artifacts-from-patch.sh' script added to standard CI which will run the same code as build-artifacts (it can symlink to the build-artifacts if there is no diff between it to normal build-artifacts) and the trigger for it will be done by typing a comment in the patch, something like "jenkins please build". We'll implement it by adding a yaml patch with new template for the gerrit trigger plugin with the 'comment added contains regular expression' option. > Add a standard-CI job and button "build-scratch-artifacts" > ---------------------------------------------------------- > > Key: OVIRT-920 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-920 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Yedidyah Bar David > Assignee: infra > > Hi, > I think it will be useful to have an option to very easily (such as > pressing a button in gerrit) to do a full build of a project, > similarly to current build-artifacts, but for a pending patch - so it > will not be collected by any publisher, and will keep its artifacts > for a short time (say, 2 days). > This will allow to use these artifacts for manual tests, perhaps > longer than check-patch, in case a developer wants to do them. > -- > Didi -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-904) False CI-1 due to unreachable copr-be.cloud.fedoraproject.org
by Barak Korren (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-904?page=com.atlassian.jira.p… ] Barak Korren commented on OVIRT-904: ------------------------------------ [~gshereme(a)redhat.com] are you dong that manually, or do you have some automation built around it? I'm not sure oVirt's own infra would be the best place, because Patternfly is not strictly an oVirt project. Perhaps make travis run the build in Copr, and then take the result and push it to GitHub's artifact storage? Another possibility is to use [BinTray|https://bintray.com/] We might eventually mirror this in oVirt infra to make CI resilient to changes there (see OVIRT-575) > False CI-1 due to unreachable copr-be.cloud.fedoraproject.org > ------------------------------------------------------------- > > Key: OVIRT-904 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-904 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: danken > Assignee: infra > > Many patches on > https://gerrit.ovirt.org/#/q/topic:passthroughMigration fail CI due to > failure: repodata/repomd.xml from patternfly: [Errno 256] No more > mirrors to try. > http://copr-be.cloud.fedoraproject.org/results/patternfly/patternfly1/epel-…: > [Errno 14] curl#7 - "Failed connect to > copr-be.cloud.fedoraproject.org:80; No route to host" > http://copr-be.cloud.fedoraproject.org/results/patternfly/patternfly1/epel-… -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-920) Add a standard-CI job and button "build-scratch-artifacts"
by Yedidyah Bar David (oVirt JIRA) 08 Dec '16

08 Dec '16

Yedidyah Bar David created OVIRT-920: ---------------------------------------- Summary: Add a standard-CI job and button "build-scratch-artifacts" Key: OVIRT-920 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-920 Project: oVirt - virtualization made easy Issue Type: By-EMAIL Reporter: Yedidyah Bar David Assignee: infra Hi, I think it will be useful to have an option to very easily (such as pressing a button in gerrit) to do a full build of a project, similarly to current build-artifacts, but for a pending patch - so it will not be collected by any publisher, and will keep its artifacts for a short time (say, 2 days). This will allow to use these artifacts for manual tests, perhaps longer than check-patch, in case a developer wants to do them. -- Didi -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0