January 2017 - Infra - oVirt List Archives

[JIRA] (OVIRT-1014) avoid repetition in automation/*packages
by Barak Korren (oVirt JIRA) 10 Jan '17

10 Jan '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1014?page=com.atlassian.jira.… ] Barak Korren commented on OVIRT-1014: ------------------------------------- {quote} could work for me. But I would like to be able to specify the version of package, in order to be able to generate spec file Requires: and BuildRequires: directives. {quote} The thing with this is that the '{{*.packages}}' file need to be translated to a single '{{yum install foo bar baz...}}' line. So there is not much versioning logic I can do. You can use exact versions though. I suppose we could implement more complex logic, but that will be equivalent to running '{{yum-builddep}' from inside the automation script (Which means, the results will not be cached, and the installation will be done every single time the job runs). We might be able to do more complex stuff when we get around to OVIRT-873. > avoid repetition in automation/*packages > ---------------------------------------- > > Key: OVIRT-1014 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1014 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Reporter: danken > Assignee: infra > > Currently we have many automation/*packages* files, mostly repeating each other. > Most of the information there is then repeated in vdsm.spec as well. > It would be nice to have a hierarchical way to define packages. E.g. having most packages in automation/build-artifacts-manual.packages, and adding el7-specific dependencies in avoid repetition in automation/build-artifacts-manual.packages.el7. > It would be even better to have a single palce (yaml file?) to declare each required package and its version, for each platform/architecture. We can then use it to generate the spec file. -- This message was sent by Atlassian JIRA (v1000.670.2#100024)

1 0

CI not running on ovirt-engine-dashboard-1.1 branch
by Greg Sheremeta 10 Jan '17

10 Jan '17

Hi, Even after [3] was merged, no CI is running on [1] and [2]. I tried "Re-run hooks: all" but no luck. Any ideas? Something else I need to do? Greg [1] https://gerrit.ovirt.org/#/c/69731/ [2] https://gerrit.ovirt.org/#/c/69735/ [3] https://gerrit.ovirt.org/#/c/69737/ -- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme(a)redhat.com

3 3

[JIRA] (OVIRT-1014) avoid repetition in automation/*packages
by danken (oVirt JIRA) 10 Jan '17

10 Jan '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1014?page=com.atlassian.jira.… ] danken commented on OVIRT-1014: ------------------------------- We are using symlinks when possible. #include "./check-patch.packages" could work for me. But I would like to be able to specify the version of package, in order to be able to generate spec file Requires: and BuildRequires: directives. > avoid repetition in automation/*packages > ---------------------------------------- > > Key: OVIRT-1014 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1014 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Reporter: danken > Assignee: infra > > Currently we have many automation/*packages* files, mostly repeating each other. > Most of the information there is then repeated in vdsm.spec as well. > It would be nice to have a hierarchical way to define packages. E.g. having most packages in automation/build-artifacts-manual.packages, and adding el7-specific dependencies in avoid repetition in automation/build-artifacts-manual.packages.el7. > It would be even better to have a single palce (yaml file?) to declare each required package and its version, for each platform/architecture. We can then use it to generate the spec file. -- This message was sent by Atlassian JIRA (v1000.670.2#100024)

1 0

[oVirt Jenkins] test-repo_ovirt_experimental_master - Build #4653 - FAILURE!
by jenkins＠jenkins.phx.ovirt.org 10 Jan '17

10 Jan '17

------=_Part_231_202001478.1484050214666 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Build: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/4653/, Build Number: 4653, Build Status: FAILURE ------=_Part_231_202001478.1484050214666--

1 3

[oVirt Jenkins] test-repo_ovirt_experimental_4.1 - Build #180 - FAILURE!
by jenkins＠jenkins.phx.ovirt.org 10 Jan '17

10 Jan '17

------=_Part_217_710524236.1484043988492 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Build: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_4.1/180/, Build Number: 180, Build Status: FAILURE ------=_Part_217_710524236.1484043988492--

1 4

[JIRA] (OVIRT-1014) avoid repetition in automation/*packages
by Barak Korren (oVirt JIRA) 10 Jan '17

10 Jan '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1014?page=com.atlassian.jira.… ] Barak Korren edited comment on OVIRT-1014 at 1/10/17 3:15 PM: -------------------------------------------------------------- This had been asked for before. If the files are exact replicas symlinks can be used. WRT hierarchical files, the problem with that is that then it becomes impossible to make certain packages NOT be installed on certain platforms... WRT having a structured file , this maybe possible - e.g. to keep the existing files as they are and have a new format specified alongside them. But we need to specify this very carefully, and I'm also weary of having too much logic in the CI infrastructure. Another backwards-compatible possibility to consider - Add an "#include" directive to the packages file. was (Author: bkorren(a)redhat.com) This had been asked for before. If the files are exact replicas symlinks can be used. WRT hierarchical files, the problem with that is that then it becomes impossible to make certain packages NOT be installed on certain platforms... WTR having a structured file , this maybe possible - e.g. to keep the existing files as they are and have a new format specified alongside them. But we need to specify this very carefully, and I'm also weary of having too much logic in the CI infrastructure. Another backwards-compatible possibility to consider - Add an "#include" directive to the packages file. > avoid repetition in automation/*packages > ---------------------------------------- > > Key: OVIRT-1014 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1014 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Reporter: danken > Assignee: infra > > Currently we have many automation/*packages* files, mostly repeating each other. > Most of the information there is then repeated in vdsm.spec as well. > It would be nice to have a hierarchical way to define packages. E.g. having most packages in automation/build-artifacts-manual.packages, and adding el7-specific dependencies in avoid repetition in automation/build-artifacts-manual.packages.el7. > It would be even better to have a single palce (yaml file?) to declare each required package and its version, for each platform/architecture. We can then use it to generate the spec file. -- This message was sent by Atlassian JIRA (v1000.670.2#100024)

1 0

[JIRA] (OVIRT-1014) avoid repetition in automation/*packages
by Barak Korren (oVirt JIRA) 10 Jan '17

10 Jan '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1014?page=com.atlassian.jira.… ] Barak Korren commented on OVIRT-1014: ------------------------------------- This had been asked for before. If the files are exact replicas symlinks can be used. WRT hierarchical files, the problem with that is that then it becomes impossible to make certain packages NOT be installed on certain platforms... WTR having a structured file , this maybe possible - e.g. to keep the existing files as they are and have a new format specified alongside them. But we need to specify this very carefully, and I'm also weary of having too much logic in the CI infrastructure. Another backwards-compatible possibility to consider - Add an "#include" directive to the packages file. > avoid repetition in automation/*packages > ---------------------------------------- > > Key: OVIRT-1014 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1014 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Reporter: danken > Assignee: infra > > Currently we have many automation/*packages* files, mostly repeating each other. > Most of the information there is then repeated in vdsm.spec as well. > It would be nice to have a hierarchical way to define packages. E.g. having most packages in automation/build-artifacts-manual.packages, and adding el7-specific dependencies in avoid repetition in automation/build-artifacts-manual.packages.el7. > It would be even better to have a single palce (yaml file?) to declare each required package and its version, for each platform/architecture. We can then use it to generate the spec file. -- This message was sent by Atlassian JIRA (v1000.670.2#100024)

1 0

[JIRA] (OVIRT-1014) avoid repetition in automation/*packages
by danken (oVirt JIRA) 10 Jan '17

10 Jan '17

danken created OVIRT-1014: ----------------------------- Summary: avoid repetition in automation/*packages Key: OVIRT-1014 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1014 Project: oVirt - virtualization made easy Issue Type: New Feature Reporter: danken Assignee: infra Currently we have many automation/*packages* files, mostly repeating each other. Most of the information there is then repeated in vdsm.spec as well. It would be nice to have a hierarchical way to define packages. E.g. having most packages in automation/build-artifacts-manual.packages, and adding el7-specific dependencies in avoid repetition in automation/build-artifacts-manual.packages.el7. It would be even better to have a single palce (yaml file?) to declare each required package and its version, for each platform/architecture. We can then use it to generate the spec file. -- This message was sent by Atlassian JIRA (v1000.670.2#100024)

1 0

[JIRA] (OVIRT-754) Guest name 'TestNode-node' is already in use.
by Evgheni Dereveanchin (oVirt JIRA) 10 Jan '17

10 Jan '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-754?page=com.atlassian.jira.p… ] Evgheni Dereveanchin reassigned OVIRT-754: ------------------------------------------ Assignee: Evgheni Dereveanchin (was: infra) > Guest name 'TestNode-node' is already in use. > --------------------------------------------- > > Key: OVIRT-754 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-754 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: sbonazzo > Assignee: Evgheni Dereveanchin > Fix For: OVIRT-INFRA-OCT-2016 > > > http://jenkins.ovirt.org/job/ovirt-node-ng_master_build-artifacts-el7-x86_6… > ====================================================================== > ERROR: test suite for <class 'testSanity.TestNode'> > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/nose/suite.py", line 208, in run > self.setUp() > File "/usr/lib/python2.7/site-packages/nose/suite.py", line 291, in setUp > self.setupContext(ancestor) > File "/usr/lib/python2.7/site-packages/nose/suite.py", line 314, in > setupContext > try_run(context, names) > File "/usr/lib/python2.7/site-packages/nose/util.py", line 469, in try_run > return func() > File > "/home/jenkins/workspace/ovirt-node-ng_master_build-artifacts-el7-x86_64/ovirt-node-ng/tests/testVirt.py", > line 150, in setUpClass > 77) > File > "/home/jenkins/workspace/ovirt-node-ng_master_build-artifacts-el7-x86_64/ovirt-node-ng/tests/testVirt.py", > line 88, in _start_vm > dom = VM.create(name, img, ssh_port=ssh_port, memory_gb=memory_gb) > File > "/home/jenkins/workspace/ovirt-node-ng_master_build-artifacts-el7-x86_64/ovirt-node-ng/tests/virt.py", > line 217, in create > dom = sh.virt_install(*args, **kwargs) > File "/usr/lib/python2.7/site-packages/sh.py", line 1021, in __call__ > return RunningCommand(cmd, call_args, stdin, stdout, stderr) > File "/usr/lib/python2.7/site-packages/sh.py", line 486, in __init__ > self.wait() > File "/usr/lib/python2.7/site-packages/sh.py", line 500, in wait > self.handle_command_exit_code(exit_code) > File "/usr/lib/python2.7/site-packages/sh.py", line 516, in > handle_command_exit_code > raise exc(self.ran, self.process.stdout, self.process.stderr) > ErrorReturnCode_1: > RAN: '/bin/virt-install --import --print-xml --network=user,model=virtio > --noautoconsole --memory=2048 --rng=/dev/random --memballoon=virtio > --cpu=host --vcpus=4 --graphics=vnc --watchdog=default,action=poweroff > --serial=pty > --disk=path=/var/tmp/TestNode-node.qcow2,bus=virtio,format=qcow2,driver_type=qcow2,discard=unmap,cache=unsafe > --check=all=off --channel=unix,target_type=virtio,name=local.test.0 > --name=TestNode-node' > STDOUT: > STDERR: > ERROR Guest name 'TestNode-node' is already in use. > Seems to be a run in a not clean environment. Not sure about what caused > this. > -- > 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.670.2#100024)

1 0

[oVirt Jenkins] test-repo_ovirt_experimental_master - Build #4651 - FAILURE!
by jenkins＠jenkins.phx.ovirt.org 10 Jan '17

10 Jan '17

------=_Part_221_1037406178.1484046090069 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Build: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/4651/, Build Number: 4651, Build Status: FAILURE ------=_Part_221_1037406178.1484046090069--

1 1