----- Original Message -----
> From: "Jenkins CI" <gerrit2(a)gerrit.ovirt.org>
> To: "Yedidyah Bar David" <didi(a)redhat.com>
> Sent: Sunday, June 7, 2015 2:45:00 PM
> Subject: Change in ovirt-engine[master]: packaging: Add queryEnvKey
> Jenkins CI has posted comments on this change.
> Change subject: packaging: Add queryEnvKey
> Patch Set 1:
> Build Failed
> : There was an infra issue, please contact infra(a)ovirt.org
Not an infra issue, a mere bug of mine caught by pyflakes:
12:44:15 packaging/setup/ovirt_engine_setup/dialog.py:86: undefined name 'tests'
Following a private discussion with Max, related to the recent suggestion to add
flags to gerrit in order to save unnecessary jenkins tests, I thought that drafts
are not checked at all. Perhaps this needs clarification, in that discussion and/or
> To view, visit https://gerrit.ovirt.org/42017
> To unsubscribe, visit https://gerrit.ovirt.org/settings
> Gerrit-MessageType: comment
> Gerrit-Change-Id: I7c9f7f2fb7424bbeadd3779378ce042598ea0348
> Gerrit-PatchSet: 1
> Gerrit-Project: ovirt-engine
> Gerrit-Branch: master
> Gerrit-Owner: Yedidyah Bar David <didi(a)redhat.com>
> Gerrit-Reviewer: Jenkins CI
> Gerrit-Reviewer: automation(a)ovirt.org
> Gerrit-HasComments: No
We really want to have reliable and snappy CI: to allow short cycles and encourage developers to write tests.
Many patches are neither ready for review nor for CI upon submission, which is OK.
But running all the jobs on those patches with limited resources results in: overloaded resources, slow response time, unhappy developers.
# Proposed Solution
To run less jobs we know we don’t need to, thus making more resources for the jobs we need to run.
We have been experimenting to make our CI stabler and quicker to respond by using gerrit flags. This has improved in both directions very well internally.
Now it seems a good time to let all the oVirt projects to use this.
This solution indirectly promotes reviews and quick tests - “to fail early”, yet full blown static code analysis and long tests to run “when ready”.
# How it works
2 new gerrit independent flags are added to gerrit.
## CI flag
Will express patch CI status. Values:
* +1 CI passed
* 0 CI did not run yet
* -1 CI failed
Permissions for setting: project maintainers (for special cases) should be able to set/override (except Jenkins).
## Workflow flag
Will express patch “workflow” state. Values:
* 0 Work In Progress
* +1 Ready For Review
* +2 Ready For Merge
Permissions for setting: Owner can set +1, Project Maintainers can set +2
## Review + CI Integration:
Merging [“Submit” button to appear] will require: Review+1, CI+1, Workflow+2
Patch lifecycle now is:
patch state |owner |reviewer |maintainer |CI tests |pass
added/updated |- |- |- |quick |CI+1
review |Workflow+1|Review+1 |- |heavy |CI+1
merge ready |- |- |Workflow+2 |gating |CI+1
merge |- |- |merge |merge |CI+1
Changes from current workflow:
Owner only adds reviewers, now owner needs to set "Workflow+1" for the patch to be reviewed, and heavily auto-tested.
Maintainer now needs to set "Workflow+2" and wait for "Submit" button to appear after CI has completed running gating tests.
Next step will be to automate merge the change after Workflow+2 has been set by the Maintainer and gating tests passed.
## Why now?
It is elimination of waste. The sooner - the better.
The solution has been used for a while and it works.
Resolving the problem without gerrit involved will lead to adding unreliable code into jobs, and will still be prone to problems:
Just recently, 3d ago we’ve tried detecting what to run from jenkins relying only on gerrit comments so that upon Verified+1, we’d run the job.
We could not use “Review+1”, because it makes no sense at all, so we left the job to set Verified+1.
Meaning - re-trigger itself immediately more than 1 times.
Jenkins and its visitors very unhappy, and we had to stop those jobs, clean up the queue, and spam developers.
## OK OK OK. Now what?
Now we want your comments and opinions before pushing this further:
Please participate in this thread, so we can start trying it out.
Ask, Suggest better ideas, all this is welcome.
Of course, this is not written in stone, in case we find a better approach on solving those issues, we will change to it.
And we will keep improving so don't be afraid that it will be enforced: if this does not work out we will discard it.
Kudos to dcaro, most of the work was done by him, and most of this text too.
Senior Software Engineer
Red Hat - EMEA ENG Virtualization R&D
Tel.: +972 9769 2060
Email: mkovgan [at] redhat [dot] com
RHT Global #: 82-72060
Please look at this unrelated test failure:
20:38:44 ERROR: import_templates
20:38:44 Traceback (most recent call last):
20:38:44 File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest
20:38:44 File "/usr/lib/python2.7/site-packages/ovirttestenv/testlib.py", line 106, in wrapped_test
20:38:44 return test()
20:38:44 File "/usr/lib/python2.7/site-packages/ovirttestenv/testlib.py", line 48, in wrapper
20:38:44 return func(get_test_prefix(), *args, **kwargs)
20:38:44 File "/usr/lib/python2.7/site-packages/ovirttestenv/testlib.py", line 59, in wrapper
20:38:44 File "/usr/share/ovirttestenv/test_scenarios/bootstrap.py", line 278, in import_templates
20:38:44 File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/brokers.py", line 18676, in register
20:38:44 File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/proxy.py", line 115, in request
20:38:44 File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/connectionspool.py", line 79, in do_request
20:38:44 File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/connectionspool.py", line 155, in __do_request
20:38:44 raise errors.RequestError(response_code, response_reason, response_body)
20:38:44 status: 400
20:38:44 reason: Bad
20:38:44 detail: Internal Engine Error
This failure is not related to vdsm and in particular to this patch.
Content-Type: text/plain; charset=us-ascii
----- Forwarded message from David Caro <dcaroest(a)redhat.com> -----
> From: David Caro <dcaroest(a)redhat.com>
> To: devel(a)ovirt.org
> Date: Fri, 5 Jun 2015 14:06:25 +0200
> Subject: Automated builds and releases
> User-Agent: Mutt/126.96.36.199 (2013-10-16)
> Hi everyone!
> In an effort to improve the project workflow and ease the maintenance and
> improve the quality of the project releases I want to propose start worki=
> towards automated builds and releases, the main ideas are the following:
> * Stop building differently for release and non-release:
> - Building only once, testing what you build and release what you test
> - Don't use two different version strings, one for testing and one for
> * Automate the build process, and the release process, directly getting t=
> code from the repos (no manual build tarballs)
> * Adopt semantic versioning, it's a lot more meaningful than the current =
> and fits very well with the above points
> This will ease and lower the maintenance and the extra work required by
> maintainers, release engineers (sandro) and infra itself by making releas=
> easy as hitting a button at any time. That will allow us to lower the time
> features and fixes get to the users, and deliver packages and builds that=
> passed through all the tests we have, instead of rebuilding on another en=
> another time, by someone else, and passing only manual testing.
> David Caro
> Red Hat S.L.
> Continuous Integration Engineer - EMEA ENG Virtualization R&D
> Tel.: +420 532 294 605
> Email: dcaro(a)redhat.com
> Web: www.redhat.com
> RHT Global #: 82-62605
----- End forwarded message -----
Red Hat S.L.
Continuous Integration Engineer - EMEA ENG Virtualization R&D
Tel.: +420 532 294 605
RHT Global #: 82-62605
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
-----END PGP SIGNATURE-----