- Infra - oVirt List Archives

[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

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

10 Jan '17

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

1 3

[JIRA] (OVIRT-914) Better arch support for mock_runner.sh
by Barak Korren (oVirt JIRA) 10 Jan '17

10 Jan '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-914?page=com.atlassian.jira.p… ] Barak Korren updated OVIRT-914: ------------------------------- Labels: mock_runner.sh standard-ci (was: ) > Better arch support for mock_runner.sh > -------------------------------------- > > Key: OVIRT-914 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-914 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Jenkins > Reporter: Barak Korren > Assignee: infra > Labels: mock_runner.sh, standard-ci > > We managed to us "{{mock_runner.sh}}" in multi-arch so far because it was flexible enough to allow us to select the chroot file. > The issue is that mock_runner does not actually *know* the arch we are running on so we can`t:: > * do different mounts per-arch > * install different packages per-arch > * have different {{check_*}} scripts per-arch -- This message was sent by Atlassian JIRA (v1000.670.2#100024)

1 0

[JIRA] (OVIRT-1013) Automate standard-CI job creation
by Barak Korren (oVirt JIRA) 10 Jan '17

10 Jan '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1013?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1013: -------------------------------- Labels: standard-ci (was: ) > Automate standard-CI job creation > --------------------------------- > > Key: OVIRT-1013 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1013 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Jenkins > Reporter: Barak Korren > Assignee: infra > Labels: standard-ci > > The premise of the CI standard is simple: The developers place simple script in the 'automation' directory, and The infa team take care of making Jenkins run it when it should. > But we haven't been able to fully deliver on this premise yet. Getting a project to work with the CI standard also takes writing some YAML in the 'Jenkins' repo. Even worse, this YAML needs to be maintained over time as new project branches get created, new platforms get targeted, etc. > The core reason behind having to write YAML, is that there are two technical details that we need to know in order to run the CI jobs, but are not specified in a way that allows detecting them automatically. Those details are: > 1. The platforms a certain project needs to be built and tested on. > 2. The branches of the project that CI needs to look at, and how do they map to an oVirt releases. > We need to specify a way to specify the details above in a way that will allow the CI system to automatically detect them. -- This message was sent by Atlassian JIRA (v1000.670.2#100024)

1 0

[JIRA] (OVIRT-1013) Automate standard-CI job creation
by Barak Korren (oVirt JIRA) 10 Jan '17

10 Jan '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1013?page=com.atlassian.jira.… ] Barak Korren commented on OVIRT-1013: ------------------------------------- Since this may be a developer-visible change, a message about this was sent to devel: http://lists.ovirt.org/pipermail/devel/2017-January/029161.html > Automate standard-CI job creation > --------------------------------- > > Key: OVIRT-1013 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1013 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Jenkins > Reporter: Barak Korren > Assignee: infra > > The premise of the CI standard is simple: The developers place simple script in the 'automation' directory, and The infa team take care of making Jenkins run it when it should. > But we haven't been able to fully deliver on this premise yet. Getting a project to work with the CI standard also takes writing some YAML in the 'Jenkins' repo. Even worse, this YAML needs to be maintained over time as new project branches get created, new platforms get targeted, etc. > The core reason behind having to write YAML, is that there are two technical details that we need to know in order to run the CI jobs, but are not specified in a way that allows detecting them automatically. Those details are: > 1. The platforms a certain project needs to be built and tested on. > 2. The branches of the project that CI needs to look at, and how do they map to an oVirt releases. > We need to specify a way to specify the details above in a way that will allow the CI system to automatically detect them. -- This message was sent by Atlassian JIRA (v1000.670.2#100024)

1 0

[JIRA] (OVIRT-1013) Automate standard-CI job creation
by Barak Korren (oVirt JIRA) 10 Jan '17

10 Jan '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1013?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1013: -------------------------------- Description: The premise of the CI standard is simple: The developers place simple script in the 'automation' directory, and The infa team take care of making Jenkins run it when it should. But we haven't been able to fully deliver on this premise yet. Getting a project to work with the CI standard also takes writing some YAML in the 'Jenkins' repo. Even worse, this YAML needs to be maintained over time as new project branches get created, new platforms get targeted, etc. The core reason behind having to write YAML, is that there are two technical details that we need to know in order to run the CI jobs, but are not specified in a way that allows detecting them automatically. Those details are: 1. The platforms a certain project needs to be built and tested on. 2. The branches of the project that CI needs to look at, and how do they map to an oVirt releases. We need to specify a way to specify the details above in a way that will allow the CI system to automatically detect them. was: The premise of the CI standard is simple: The developers place simple script in the 'automation' directory, and The infa team take care of making Jenkins run it when it should. But we haven't been able to fully deliver on this premise yet. Getting a project to work with the CI standard also takes writing some YAML in the 'jenkins' repo. Even worse, this YAML needs to be maintained over time as new project branches get created, new platforms get targeted, etc. The core reason behind having to write YAML, is that there are two technical details that we need to know in order to run the CI jobs, but are not specified in a way that allows detecting them automatically. Those details are: 1. The platforms a certain project needs to be built and tested on. 2. The branches of the project that CI needs to look at, and how do they map to an oVirt releases. We need to specify a way to specify the details above in a way that will allow the CI system to automatically detect them. > Automate standard-CI job creation > --------------------------------- > > Key: OVIRT-1013 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1013 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Jenkins > Reporter: Barak Korren > Assignee: infra > > The premise of the CI standard is simple: The developers place simple script in the 'automation' directory, and The infa team take care of making Jenkins run it when it should. > But we haven't been able to fully deliver on this premise yet. Getting a project to work with the CI standard also takes writing some YAML in the 'Jenkins' repo. Even worse, this YAML needs to be maintained over time as new project branches get created, new platforms get targeted, etc. > The core reason behind having to write YAML, is that there are two technical details that we need to know in order to run the CI jobs, but are not specified in a way that allows detecting them automatically. Those details are: > 1. The platforms a certain project needs to be built and tested on. > 2. The branches of the project that CI needs to look at, and how do they map to an oVirt releases. > We need to specify a way to specify the details above in a way that will allow the CI system to automatically detect them. -- This message was sent by Atlassian JIRA (v1000.670.2#100024)

1 0

[JIRA] (OVIRT-1013) Automate standard-CI job creation
by Barak Korren (oVirt JIRA) 10 Jan '17

10 Jan '17

Barak Korren created OVIRT-1013: ----------------------------------- Summary: Automate standard-CI job creation Key: OVIRT-1013 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1013 Project: oVirt - virtualization made easy Issue Type: Improvement Components: Jenkins Reporter: Barak Korren Assignee: infra The premise of the CI standard is simple: The developers place simple script in the 'automation' directory, and The infa team take care of making Jenkins run it when it should. But we haven't been able to fully deliver on this premise yet. Getting a project to work with the CI standard also takes writing some YAML in the 'jenkins' repo. Even worse, this YAML needs to be maintained over time as new project branches get created, new platforms get targeted, etc. The core reason behind having to write YAML, is that there are two technical details that we need to know in order to run the CI jobs, but are not specified in a way that allows detecting them automatically. Those details are: 1. The platforms a certain project needs to be built and tested on. 2. The branches of the project that CI needs to look at, and how do they map to an oVirt releases. We need to specify a way to specify the details above in a way that will allow the CI system to automatically detect them. -- This message was sent by Atlassian JIRA (v1000.670.2#100024)

1 0

[JIRA] (OVIRT-1013) Automate standard-CI job creation
by Barak Korren (oVirt JIRA) 10 Jan '17

10 Jan '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1013?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1013: -------------------------------- Epic Link: OVIRT-400 > Automate standard-CI job creation > --------------------------------- > > Key: OVIRT-1013 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1013 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Jenkins > Reporter: Barak Korren > Assignee: infra > > The premise of the CI standard is simple: The developers place simple script in the 'automation' directory, and The infa team take care of making Jenkins run it when it should. > But we haven't been able to fully deliver on this premise yet. Getting a project to work with the CI standard also takes writing some YAML in the 'jenkins' repo. Even worse, this YAML needs to be maintained over time as new project branches get created, new platforms get targeted, etc. > The core reason behind having to write YAML, is that there are two technical details that we need to know in order to run the CI jobs, but are not specified in a way that allows detecting them automatically. Those details are: > 1. The platforms a certain project needs to be built and tested on. > 2. The branches of the project that CI needs to look at, and how do they map to an oVirt releases. > We need to specify a way to specify the details above in a way that will allow the CI system to automatically detect them. -- This message was sent by Atlassian JIRA (v1000.670.2#100024)

1 0

[JIRA] (OVIRT-894) Add support of secrets and credentials in Standard-CI
by Barak Korren (oVirt JIRA) 10 Jan '17

10 Jan '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-894?page=com.atlassian.jira.p… ] Barak Korren updated OVIRT-894: ------------------------------- Summary: Add support of secrets and credentials in Standard-CI (was: Add support of sercers and credentials in Standard-CI) > Add support of secrets and credentials in Standard-CI > ----------------------------------------------------- > > Key: OVIRT-894 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-894 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: General > Reporter: Barak Korren > Assignee: infra > Labels: standard-ci > > Some task we'd like to carry out in Standard-CI require credentials. Examples for such tasks include: > # Publishing artifacts to repositories (E.g containers to Dokcerhub, puppet code to Puppetmaster) > # Launching remote processes (Check code with remote services) > While Jenkins supports storing and managing secret data, we did not enable a way to use this capability from Standard-CI so far. -- This message was sent by Atlassian JIRA (v1000.670.2#100024)

1 0