[JIRA] (OVIRT-1918) Single project tests in change-queue-tester
by Barak Korren (oVirt JIRA)
This is a multi-part message in MIME format...
------------=_1520333776-20649-136
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
[ https://ovirt-jira.atlassian.net/browse/OVIRT-1918?page=com.atlassian.jir... ]
Barak Korren edited comment on OVIRT-1918 at 3/6/18 10:56 AM:
--------------------------------------------------------------
{quote}
So, supposing project A and B are completely fine, a failure in project C
can still prevent changes in A and B to go ahead through the pipeline and
get released.
{quote}
This statement is false - what will happen in this case is that a bisection search will run and isulate the change to project C, while allowing the changes for A and B to pass. This is the whole point of CQ and the difference between it and the 'experimental' system it replaced.
[~sbonazzo(a)redhat.com] Unless you need further clarification, I will close this ticket as WONTFIX.
was (Author: bkorren(a)redhat.com):
{quote}
So, supposing project A and B are completely fine, a failure in project C
can still prevent changes in A and B to go ahead through the pipeline and
get released.
{quote}
This statement is false - what will happen in this case is that a bisection search will run and isulate the change to project C, while allowing the changes for A and B to pass. This si the whole point of CQ and the difference between it and the 'experimental' system it replaced.
[~sbonazzo(a)redhat.com] Unless you need further clarification, I will close this ticket as WONTFIX.
> Single project tests in change-queue-tester
> -------------------------------------------
>
> Key: OVIRT-1918
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1918
> Project: oVirt - virtualization made easy
> Issue Type: By-EMAIL
> Reporter: sbonazzo
> Assignee: infra
>
> Please change change-queue-tester jobs for testing a single project at a
> time (ok for multiple patches at once, but from the same project).
> Right now if multiple patches are merged between a change-queue-tester
> execution and the next one are done, all of them will be tested in the next
> run, even if the changes are in different projects.
> So, supposing project A and B are completely fine, a failure in project C
> can still prevent changes in A and B to go ahead through the pipeline and
> get released.
> This cause major headaches at least to me, requiring me to go again over
> all the HEAD of the projects not being published and run yet again "ci
> re-merge please" again and again and again until I'm lucky enough to have
> nobody else merging patches or having all the ttested patches pass at once.
> I understand the need to reduce the amount of executions of the job since
> it takes an hour to execute but right now it's stealing days of execution
> for getting a patch landing on tested repo.
> --
> SANDRO BONAZZOLA
> ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
> Red Hat EMEA <https://www.redhat.com/>
> <https://red.ht/sig>
> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
--
This message was sent by Atlassian Jira
(v1001.0.0-SNAPSHOT#100081)
------------=_1520333776-20649-136
Content-Type: text/html; charset="UTF-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
<html><body>
<pre>[ https://ovirt-jira.atlassian.net/browse/OVIRT-1918?page=com.atlassian.jir... ]</pre>
<h3>Barak Korren edited comment on OVIRT-1918 at 3/6/18 10:56 AM:</h3>
<p>{quote} So, supposing project A and B are completely fine, a failure in project C can still prevent changes in A and B to go ahead through the pipeline and get released. {quote}</p>
<p>This statement is false – what will happen in this case is that a bisection search will run and isulate the change to project C, while allowing the changes for A and B to pass. This is the whole point of CQ and the difference between it and the ‘experimental’ system it replaced.</p>
<p>[~sbonazzo(a)redhat.com] Unless you need further clarification, I will close this ticket as WONTFIX.</p>
<p>was (Author: bkorren(a)redhat.com): {quote} So, supposing project A and B are completely fine, a failure in project C can still prevent changes in A and B to go ahead through the pipeline and get released. {quote}</p>
<p>This statement is false – what will happen in this case is that a bisection search will run and isulate the change to project C, while allowing the changes for A and B to pass. This si the whole point of CQ and the difference between it and the ‘experimental’ system it replaced.</p>
<p>[~sbonazzo(a)redhat.com] Unless you need further clarification, I will close this ticket as WONTFIX.</p>
<blockquote><h3>Single project tests in change-queue-tester</h3>
<pre> Key: OVIRT-1918
URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1918
Project: oVirt - virtualization made easy
Issue Type: By-EMAIL
Reporter: sbonazzo
Assignee: infra</pre>
<p>Please change change-queue-tester jobs for testing a single project at a time (ok for multiple patches at once, but from the same project). Right now if multiple patches are merged between a change-queue-tester execution and the next one are done, all of them will be tested in the next run, even if the changes are in different projects. So, supposing project A and B are completely fine, a failure in project C can still prevent changes in A and B to go ahead through the pipeline and get released. This cause major headaches at least to me, requiring me to go again over all the HEAD of the projects not being published and run yet again “ci re-merge please” again and again and again until I'm lucky enough to have nobody else merging patches or having all the ttested patches pass at once. I understand the need to reduce the amount of executions of the job since it takes an hour to execute but right now it's stealing days of execution for getting a patch landing on tested repo. — SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <<a href="https://www.redhat.com/">https://www.redhat.com/</a>> <<a href="https://red.ht/sig">https://red.ht/sig</a>> TRIED. TESTED. TRUSTED. <<a href="https://redhat.com/trusted">https://redhat.com/trusted</a>></p></blockquote>
<p>— This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100081)</p>
<img src="https://u4043402.ct.sendgrid.net/wf/open?upn=i5TMWGV99amJbNxJpSp2-2BJ33BS..." alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;"/>
</body></html>
------------=_1520333776-20649-136--
7 years
[JIRA] (OVIRT-1918) Single project tests in change-queue-tester
by Barak Korren (oVirt JIRA)
This is a multi-part message in MIME format...
------------=_1520333757-27720-121
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
[ https://ovirt-jira.atlassian.net/browse/OVIRT-1918?page=com.atlassian.jir... ]
Barak Korren edited comment on OVIRT-1918 at 3/6/18 10:55 AM:
--------------------------------------------------------------
{quote}
So, supposing project A and B are completely fine, a failure in project C
can still prevent changes in A and B to go ahead through the pipeline and
get released.
{quote}
This statement is false - what will happen in this case is that a bisection search will run and isulate the change to project C, while allowing the changes for A and B to pass. This si the whole point of CQ and the difference between it and the 'experimental' system it replaced.
[~sbonazzo(a)redhat.com] Unless you need further clarification, I will close this ticket as WONTFIX.
was (Author: bkorren(a)redhat.com):
{quote}
So, supposing project A and B are completely fine, a failure in project C
can still prevent changes in A and B to go ahead through the pipeline and
get released.
{quote}
This statement is false - what will happen in this case is that a bisection search will run and isulate the change to project C, while allowing the changes for A and B to pass. This si the whole point of CQ and the difference between it and the 'experimental' system it replaced.
[~sbonazzo(a)redhat.com] Un;ess you need further clarification, I will close this ticket as WONTFIX.
> Single project tests in change-queue-tester
> -------------------------------------------
>
> Key: OVIRT-1918
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1918
> Project: oVirt - virtualization made easy
> Issue Type: By-EMAIL
> Reporter: sbonazzo
> Assignee: infra
>
> Please change change-queue-tester jobs for testing a single project at a
> time (ok for multiple patches at once, but from the same project).
> Right now if multiple patches are merged between a change-queue-tester
> execution and the next one are done, all of them will be tested in the next
> run, even if the changes are in different projects.
> So, supposing project A and B are completely fine, a failure in project C
> can still prevent changes in A and B to go ahead through the pipeline and
> get released.
> This cause major headaches at least to me, requiring me to go again over
> all the HEAD of the projects not being published and run yet again "ci
> re-merge please" again and again and again until I'm lucky enough to have
> nobody else merging patches or having all the ttested patches pass at once.
> I understand the need to reduce the amount of executions of the job since
> it takes an hour to execute but right now it's stealing days of execution
> for getting a patch landing on tested repo.
> --
> SANDRO BONAZZOLA
> ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
> Red Hat EMEA <https://www.redhat.com/>
> <https://red.ht/sig>
> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
--
This message was sent by Atlassian Jira
(v1001.0.0-SNAPSHOT#100081)
------------=_1520333757-27720-121
Content-Type: text/html; charset="UTF-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
<html><body>
<pre>[ https://ovirt-jira.atlassian.net/browse/OVIRT-1918?page=com.atlassian.jir... ]</pre>
<h3>Barak Korren edited comment on OVIRT-1918 at 3/6/18 10:55 AM:</h3>
<p>{quote} So, supposing project A and B are completely fine, a failure in project C can still prevent changes in A and B to go ahead through the pipeline and get released. {quote}</p>
<p>This statement is false – what will happen in this case is that a bisection search will run and isulate the change to project C, while allowing the changes for A and B to pass. This si the whole point of CQ and the difference between it and the ‘experimental’ system it replaced.</p>
<p>[~sbonazzo(a)redhat.com] Unless you need further clarification, I will close this ticket as WONTFIX.</p>
<p>was (Author: bkorren(a)redhat.com): {quote} So, supposing project A and B are completely fine, a failure in project C can still prevent changes in A and B to go ahead through the pipeline and get released. {quote}</p>
<p>This statement is false – what will happen in this case is that a bisection search will run and isulate the change to project C, while allowing the changes for A and B to pass. This si the whole point of CQ and the difference between it and the ‘experimental’ system it replaced.</p>
<p>[~sbonazzo(a)redhat.com] Un;ess you need further clarification, I will close this ticket as WONTFIX.</p>
<blockquote><h3>Single project tests in change-queue-tester</h3>
<pre> Key: OVIRT-1918
URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1918
Project: oVirt - virtualization made easy
Issue Type: By-EMAIL
Reporter: sbonazzo
Assignee: infra</pre>
<p>Please change change-queue-tester jobs for testing a single project at a time (ok for multiple patches at once, but from the same project). Right now if multiple patches are merged between a change-queue-tester execution and the next one are done, all of them will be tested in the next run, even if the changes are in different projects. So, supposing project A and B are completely fine, a failure in project C can still prevent changes in A and B to go ahead through the pipeline and get released. This cause major headaches at least to me, requiring me to go again over all the HEAD of the projects not being published and run yet again “ci re-merge please” again and again and again until I'm lucky enough to have nobody else merging patches or having all the ttested patches pass at once. I understand the need to reduce the amount of executions of the job since it takes an hour to execute but right now it's stealing days of execution for getting a patch landing on tested repo. — SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <<a href="https://www.redhat.com/">https://www.redhat.com/</a>> <<a href="https://red.ht/sig">https://red.ht/sig</a>> TRIED. TESTED. TRUSTED. <<a href="https://redhat.com/trusted">https://redhat.com/trusted</a>></p></blockquote>
<p>— This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100081)</p>
<img src="https://u4043402.ct.sendgrid.net/wf/open?upn=i5TMWGV99amJbNxJpSp2-2BJ33BS..." alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;"/>
</body></html>
------------=_1520333757-27720-121--
7 years
[JIRA] (OVIRT-1918) Single project tests in change-queue-tester
by Barak Korren (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-1918?page=com.atlassian.jir... ]
Barak Korren commented on OVIRT-1918:
-------------------------------------
{quote}
So, supposing project A and B are completely fine, a failure in project C
can still prevent changes in A and B to go ahead through the pipeline and
get released.
{quote}
This statement is false - what will happen in this case is that a bisection search will run and isulate the change to project C, while allowing the changes for A and B to pass. This si the whole point of CQ and the difference between it and the 'experimental' system it replaced.
[~sbonazzo(a)redhat.com] Un;ess you need further clarification, I will close this ticket as WONTFIX.
> Single project tests in change-queue-tester
> -------------------------------------------
>
> Key: OVIRT-1918
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1918
> Project: oVirt - virtualization made easy
> Issue Type: By-EMAIL
> Reporter: sbonazzo
> Assignee: infra
>
> Please change change-queue-tester jobs for testing a single project at a
> time (ok for multiple patches at once, but from the same project).
> Right now if multiple patches are merged between a change-queue-tester
> execution and the next one are done, all of them will be tested in the next
> run, even if the changes are in different projects.
> So, supposing project A and B are completely fine, a failure in project C
> can still prevent changes in A and B to go ahead through the pipeline and
> get released.
> This cause major headaches at least to me, requiring me to go again over
> all the HEAD of the projects not being published and run yet again "ci
> re-merge please" again and again and again until I'm lucky enough to have
> nobody else merging patches or having all the ttested patches pass at once.
> I understand the need to reduce the amount of executions of the job since
> it takes an hour to execute but right now it's stealing days of execution
> for getting a patch landing on tested repo.
> --
> SANDRO BONAZZOLA
> ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
> Red Hat EMEA <https://www.redhat.com/>
> <https://red.ht/sig>
> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
--
This message was sent by Atlassian Jira
(v1001.0.0-SNAPSHOT#100081)
7 years
[JIRA] (OVIRT-1918) Single project tests in change-queue-tester
by sbonazzo (oVirt JIRA)
sbonazzo created OVIRT-1918:
-------------------------------
Summary: Single project tests in change-queue-tester
Key: OVIRT-1918
URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1918
Project: oVirt - virtualization made easy
Issue Type: By-EMAIL
Reporter: sbonazzo
Assignee: infra
Please change change-queue-tester jobs for testing a single project at a
time (ok for multiple patches at once, but from the same project).
Right now if multiple patches are merged between a change-queue-tester
execution and the next one are done, all of them will be tested in the next
run, even if the changes are in different projects.
So, supposing project A and B are completely fine, a failure in project C
can still prevent changes in A and B to go ahead through the pipeline and
get released.
This cause major headaches at least to me, requiring me to go again over
all the HEAD of the projects not being published and run yet again "ci
re-merge please" again and again and again until I'm lucky enough to have
nobody else merging patches or having all the ttested patches pass at once.
I understand the need to reduce the amount of executions of the job since
it takes an hour to execute but right now it's stealing days of execution
for getting a patch landing on tested repo.
--
SANDRO BONAZZOLA
ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
Red Hat EMEA <https://www.redhat.com/>
<https://red.ht/sig>
TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
--
This message was sent by Atlassian Jira
(v1001.0.0-SNAPSHOT#100081)
7 years
Build failed in Jenkins: system-sync_mirrors-epel-el6-x86_64 #1262
by jenkins＠jenkins.phx.ovirt.org
See <http://jenkins.ovirt.org/job/system-sync_mirrors-epel-el6-x86_64/1262/dis...>
------------------------------------------
Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on mirrors.phx.ovirt.org (mirrors) in workspace <http://jenkins.ovirt.org/job/system-sync_mirrors-epel-el6-x86_64/ws/>
> git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
> git config remote.origin.url http://gerrit.ovirt.org/jenkins.git # timeout=10
Cleaning workspace
> git rev-parse --verify HEAD # timeout=10
Resetting working tree
> git reset --hard # timeout=10
> git clean -fdx # timeout=10
Pruning obsolete local branches
Fetching upstream changes from http://gerrit.ovirt.org/jenkins.git
> git --version # timeout=10
> git fetch --tags --progress http://gerrit.ovirt.org/jenkins.git +refs/heads/*:refs/remotes/origin/* --prune
> git rev-parse origin/master^{commit} # timeout=10
Checking out Revision ea02d358e4b5ba495ce4f865f48d932427cd0bdb (origin/master)
> git config core.sparsecheckout # timeout=10
> git checkout -f ea02d358e4b5ba495ce4f865f48d932427cd0bdb
Commit message: "Revert "Install base packeges and start services from global_setup""
> git rev-list --no-walk ea02d358e4b5ba495ce4f865f48d932427cd0bdb # timeout=10
[system-sync_mirrors-epel-el6-x86_64] $ /bin/bash -xe /tmp/jenkins562107027827444518.sh
+ jenkins/scripts/mirror_mgr.sh resync_yum_mirror epel-el6 x86_64 jenkins/data/mirrors-reposync.conf
Checking if mirror needs a resync
Traceback (most recent call last):
File "/usr/bin/reposync", line 343, in <module>
main()
File "/usr/bin/reposync", line 175, in main
my.doRepoSetup()
File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 681, in doRepoSetup
return self._getRepos(thisrepo, True)
File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 721, in _getRepos
self._repos.doSetup(thisrepo)
File "/usr/lib/python2.7/site-packages/yum/repos.py", line 157, in doSetup
self.retrieveAllMD()
File "/usr/lib/python2.7/site-packages/yum/repos.py", line 88, in retrieveAllMD
dl = repo._async and repo._commonLoadRepoXML(repo)
File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 1474, in _commonLoadRepoXML
if self._latestRepoXML(local):
File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 1443, in _latestRepoXML
oxml = self._saveOldRepoXML(local)
File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 1300, in _saveOldRepoXML
shutil.copy2(local, old_local)
File "/usr/lib64/python2.7/shutil.py", line 131, in copy2
copystat(src, dst)
File "/usr/lib64/python2.7/shutil.py", line 98, in copystat
os.utime(dst, (st.st_atime, st.st_mtime))
OSError: [Errno 2] No such file or directory: '/home/jenkins/mirrors_cache/centos-extras-el7/repomd.xml.old.tmp'
Build step 'Execute shell' marked build as failure
7 years
[JIRA] (OVIRT-1917) Off by one bug in nested config parser
by Daniel Belenky (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-1917?page=com.atlassian.jir... ]
Daniel Belenky reassigned OVIRT-1917:
-------------------------------------
Assignee: Daniel Belenky (was: infra)
> Off by one bug in nested config parser
> --------------------------------------
>
> Key: OVIRT-1917
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1917
> Project: oVirt - virtualization made easy
> Issue Type: Bug
> Reporter: Daniel Belenky
> Assignee: Daniel Belenky
> Priority: Highest
>
> There is an off by one bug in _cartesian_multiplication() (nested_config.py) where if given a list of vectors to try and merge with each other, the last vector, if merged, needs to be excluded from the final result since it was already merged. In other cases, if the last vector was not merged, it needs to be included in the final result.
--
This message was sent by Atlassian Jira
(v1001.0.0-SNAPSHOT#100081)
7 years
[JIRA] (OVIRT-1917) Off by one bug in nested config parser
by Daniel Belenky (oVirt JIRA)
Daniel Belenky created OVIRT-1917:
-------------------------------------
Summary: Off by one bug in nested config parser
Key: OVIRT-1917
URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1917
Project: oVirt - virtualization made easy
Issue Type: Bug
Reporter: Daniel Belenky
Assignee: infra
Priority: Highest
There is an off by one bug in _cartesian_multiplication() (nested_config.py) where if given a list of vectors to try and merge with each other, the last vector, if merged, needs to be excluded from the final result since it was already merged. In other cases, if the last vector was not merged, it needs to be included in the final result.
--
This message was sent by Atlassian Jira
(v1001.0.0-SNAPSHOT#100081)
7 years
