- Infra - oVirt List Archives

[JIRA] (OVIRT-873) Implement Standard-CI with containers
by Nadav Goldin (oVirt JIRA) 28 Nov '16

28 Nov '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-873?page=com.atlassian.jira.p… ] Nadav Goldin commented on OVIRT-873: ------------------------------------ +1 - I think containers support would be great, especially if we use openshift. Few issues that come to mind from my little experience with docker: 1. docker has limitation, for example: running systemd is almost impossible, also I doubt if you can run qemu inside docker, so this is not relevant for OST. 2. docker wants one process per container(as for the guidelines), I think we have jobs that need to do more than that. 3. docker images are not always one-to-one with the images we want to test on, i.e. can we claim that centos7:latest on docker hub is equivalent to centos7 we "support"? not sure. Moreover, this means we will need to start maintaining images, what we don't do now(in a way we maintain mock configurations which might be considered as maintaining Dockerfiles). either way, every solution we go with would probably need to be hybrid one(maintaining both flows). > Implement Standard-CI with containers > ------------------------------------- > > Key: OVIRT-873 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-873 > Project: oVirt - virtualization made easy > Issue Type: Task > Components: General > Reporter: Barak Korren > Assignee: infra > > oVirt's Standard-CI is currently implemented using mock, and this has worked well for us so far. > Changing the implementation to use containers will provide several benefits: > * Faster start-up times - Most container provides have some form of image layering and caching that will be faster as bringing up a basic OS image then installing it with yum like mock does. > * Broader OS support - mock can only run on the Red Hat family of operating systems, and can only emulate those operating systems. Most container providers can both run on and emulate a broader range of operating systems. > * Better isolation and cleanup - Mock only isolates the file system, containers can isolate the file system as well as the networking layer and the process space. > Depending on the container provider, we may gain additional benefits: > * Some container providers like Kubernetes, can manage distributed compute resources across many nodes. This means can can stop managing Jenkins slaves and instead just have the Jenkins master start up containers on the provider. > * Some providers like OpenShift have built-in CI processes for creating and testing container images. > *Note:* At some point, David started an effort going this way: https://gerrit.ovirt.org/#/c/54376/ -- This message was sent by Atlassian JIRA (v1000.571.2#100021)

1 0

[JIRA] (OVIRT-873) Implement Standard-CI with containers
by eyal edri [Administrator] (oVirt JIRA) 28 Nov '16

28 Nov '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-873?page=com.atlassian.jira.p… ] eyal edri [Administrator] commented on OVIRT-873: ------------------------------------------------- I think its the right way going forward as version 2.0 of the standard CI. At some point we considered moving to stateless slaves instead mock , but I think this approach might prove to be better, because of the advantages of less maintenance of keeping various VMs with multiple operating systems + the overhead of ensuring the stateless mechanism works. Worth also looking into fabric8.io, it has integration with Kubernetes & OpenShift already. more info @ https://fabric8.io/articles/index.html > Implement Standard-CI with containers > ------------------------------------- > > Key: OVIRT-873 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-873 > Project: oVirt - virtualization made easy > Issue Type: Task > Components: General > Reporter: Barak Korren > Assignee: infra > > oVirt's Standard-CI is currently implemented using mock, and this has worked well for us so far. > Changing the implementation to use containers will provide several benefits: > * Faster start-up times - Most container provides have some form of image layering and caching that will be faster as bringing up a basic OS image then installing it with yum like mock does. > * Broader OS support - mock can only run on the Red Hat family of operating systems, and can only emulate those operating systems. Most container providers can both run on and emulate a broader range of operating systems. > * Better isolation and cleanup - Mock only isolates the file system, containers can isolate the file system as well as the networking layer and the process space. > Depending on the container provider, we may gain additional benefits: > * Some container providers like Kubernetes, can manage distributed compute resources across many nodes. This means can can stop managing Jenkins slaves and instead just have the Jenkins master start up containers on the provider. > * Some providers like OpenShift have built-in CI processes for creating and testing container images. > *Note:* At some point, David started an effort going this way: https://gerrit.ovirt.org/#/c/54376/ -- This message was sent by Atlassian JIRA (v1000.571.2#100021)

1 0

[JIRA] (OVIRT-873) Implement Standard-CI with containers
by Barak Korren (oVirt JIRA) 28 Nov '16

28 Nov '16

Barak Korren created OVIRT-873: ---------------------------------- Summary: Implement Standard-CI with containers Key: OVIRT-873 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-873 Project: oVirt - virtualization made easy Issue Type: Task Components: General Reporter: Barak Korren Assignee: infra oVirt's Standard-CI is currently implemented using mock, and this has worked well for us so far. Changing the implementation to use containers will provide several benefits: * Faster start-up times - Most container provides have some form of image layering and caching that will be faster as bringing up a basic OS image then installing it with yum like mock does. * Broader OS support - mock can only run on the Red Hat family of operating systems, and can only emulate those operating systems. Most container providers can both run on and emulate a broader range of operating systems. * Better isolation and cleanup - Mock only isolates the file system, containers can isolate the file system as well as the networking layer and the process space. Depending on the container provider, we may gain additional benefits: * Some container providers like Kubernetes, can manage distributed compute resources across many nodes. This means can can stop managing Jenkins slaves and instead just have the Jenkins master start up containers on the provider. * Some providers like OpenShift have built-in CI processes for creating and testing container images. *Note:* At some point, David started an effort going this way: https://gerrit.ovirt.org/#/c/54376/ -- This message was sent by Atlassian JIRA (v1000.571.2#100021)

1 0

[JIRA] (OVIRT-873) Implement Standard-CI with containers
by Barak Korren (oVirt JIRA) 28 Nov '16

28 Nov '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-873?page=com.atlassian.jira.p… ] Barak Korren updated OVIRT-873: ------------------------------- Epic Link: OVIRT-403 > Implement Standard-CI with containers > ------------------------------------- > > Key: OVIRT-873 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-873 > Project: oVirt - virtualization made easy > Issue Type: Task > Components: General > Reporter: Barak Korren > Assignee: infra > > oVirt's Standard-CI is currently implemented using mock, and this has worked well for us so far. > Changing the implementation to use containers will provide several benefits: > * Faster start-up times - Most container provides have some form of image layering and caching that will be faster as bringing up a basic OS image then installing it with yum like mock does. > * Broader OS support - mock can only run on the Red Hat family of operating systems, and can only emulate those operating systems. Most container providers can both run on and emulate a broader range of operating systems. > * Better isolation and cleanup - Mock only isolates the file system, containers can isolate the file system as well as the networking layer and the process space. > Depending on the container provider, we may gain additional benefits: > * Some container providers like Kubernetes, can manage distributed compute resources across many nodes. This means can can stop managing Jenkins slaves and instead just have the Jenkins master start up containers on the provider. > * Some providers like OpenShift have built-in CI processes for creating and testing container images. > *Note:* At some point, David started an effort going this way: https://gerrit.ovirt.org/#/c/54376/ -- This message was sent by Atlassian JIRA (v1000.571.2#100021)

1 0

[oVirt Jenkins] test-repo_ovirt_experimental_master - Build #3717 - FAILURE!
by jenkins＠jenkins.phx.ovirt.org 28 Nov '16

28 Nov '16

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

1 1

oVirt infra daily report - unstable production jobs - 151
by jenkins＠jenkins.phx.ovirt.org 28 Nov '16

28 Nov '16

------=_Part_1014_2136723980.1480287606307 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Good morning! Attached is the HTML page with the jenkins status report. You can see it also here: - http://jenkins.ovirt.org/job/system_jenkins-report/151//artifact/exported-a… Cheers, Jenkins ------=_Part_1014_2136723980.1480287606307 Content-Type: application/octet-stream; name=upstream_report.html Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=upstream_report.html Content-ID: <upstream_report.html> <!DOCTYPE html><head><style type="text/css"> table.gridtable { border-collapse: collapse; table-layout:fixed; width:1600px; font-family: monospace; font-size:13px; } .head { font-size:20px; font-family: arial; } .sub { font-size:18px; background-color:#e5e5e5; font-family: arial; } pre { font-family: monospace; display: inline; white-space: pre-wrap; white-space: -moz-pre-wrap !important; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word; } </style> </head> <body> <table class="gridtable" border=2> <tr><th colspan=2 class=head> RHEVM CI Jenkins Daily Report - 27/11/2016 </th></tr><tr><th colspan=2 class=sub> <font color="blue"><a href="http://jenkins.ovirt.org/">00 Unstable Jobs (Production)</a></font> </th></tr> <tr><td> <a href="http://jenkins.ovirt.org/job/cockpit-ovirt_ovirt-4.1_build-artifacts-fc23-x…">cockpit-ovirt_ovirt-4.1_build-artifacts-fc23-x86_64</a> </td><td> This job is automatically updated by jenkins job builder, any manual change will be lost in the next update. If you want to make permanent changes, check out the <a href="http://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;h=refs/heads/master;hb=…"> jenkins</a> repo.  </td></tr> <tr><td> <a href="http://jenkins.ovirt.org/job/fabric-ovirt_master_check-merged-el7-x86_64/">fabric-ovirt_master_check-merged-el7-x86_64</a> </td><td> This job is automatically updated by jenkins job builder, any manual change will be lost in the next update. If you want to make permanent changes, check out the <a href="http://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;h=refs/heads/master;hb=…"> jenkins</a> repo.  </td></tr> <tr><td> <a href="http://jenkins.ovirt.org/job/ovirt-engine-api-explorer_master_build-artifac…">ovirt-engine-api-explorer_master_build-artifacts-el7-x86_64</a> </td><td> This job is automatically updated by jenkins job builder, any manual change will be lost in the next update. If you want to make permanent changes, check out the <a href="http://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;h=refs/heads/master;hb=…"> jenkins</a> repo.  </td></tr> <tr><td> <a href="http://jenkins.ovirt.org/job/ovirt-engine-api-explorer_master_build-artifac…">ovirt-engine-api-explorer_master_build-artifacts-fc23-x86_64</a> </td><td> This job is automatically updated by jenkins job builder, any manual change will be lost in the next update. If you want to make permanent changes, check out the <a href="http://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;h=refs/heads/master;hb=…"> jenkins</a> repo.  </td></tr> <tr><td> <a href="http://jenkins.ovirt.org/job/ovirt-guest-agent_master_build-artifacts-fc23-…">ovirt-guest-agent_master_build-artifacts-fc23-x86_64</a> </td><td> This job is automatically updated by jenkins job builder, any manual change will be lost in the next update. If you want to make permanent changes, check out the <a href="http://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;h=refs/heads/master;hb=…"> jenkins</a> repo.  </td></tr> <tr><td> <a href="http://jenkins.ovirt.org/job/ovirt-live_master_experimental_create-iso-el7-…">ovirt-live_master_experimental_create-iso-el7-x86_64</a> </td><td> <h3>This job generates a nightly iso of ovirt-live using experimental repos</h3> </td></tr> <tr><td> <a href="http://jenkins.ovirt.org/job/ovirt-node-ng_master_build-artifacts-el7-x86_6…">ovirt-node-ng_master_build-artifacts-el7-x86_64</a> </td><td> This job is automatically updated by jenkins job builder, any manual change will be lost in the next update. If you want to make permanent changes, check out the <a href="http://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;h=refs/heads/master;hb=…"> jenkins</a> repo.  </td></tr> <tr><td> <a href="http://jenkins.ovirt.org/job/ovirt-node-ng_ovirt-3.6_build-artifacts-el7-x8…">ovirt-node-ng_ovirt-3.6_build-artifacts-el7-x86_64</a> </td><td> This job is automatically updated by jenkins job builder, any manual change will be lost in the next update. If you want to make permanent changes, check out the <a href="http://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;h=refs/heads/master;hb=…"> jenkins</a> repo.  </td></tr> <tr><td> <a href="http://jenkins.ovirt.org/job/ovirt-node-ng_ovirt-4.0-pre_build-artifacts-el…">ovirt-node-ng_ovirt-4.0-pre_build-artifacts-el7-x86_64</a> </td><td> This job is automatically updated by jenkins job builder, any manual change will be lost in the next update. If you want to make permanent changes, check out the <a href="http://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;h=refs/heads/master;hb=…"> jenkins</a> repo.  </td></tr> <tr><td> <a href="http://jenkins.ovirt.org/job/ovirt-node-ng_ovirt-4.0-snapshot_build-artifac…">ovirt-node-ng_ovirt-4.0-snapshot_build-artifacts-el7-x86_64</a> </td><td> This job is automatically updated by jenkins job builder, any manual change will be lost in the next update. If you want to make permanent changes, check out the <a href="http://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;h=refs/heads/master;hb=…"> jenkins</a> repo.  </td></tr> <tr><td> <a href="http://jenkins.ovirt.org/job/ovirt-node-ng_ovirt-4.0_build-artifacts-el7-x8…">ovirt-node-ng_ovirt-4.0_build-artifacts-el7-x86_64</a> </td><td> This job is automatically updated by jenkins job builder, any manual change will be lost in the next update. If you want to make permanent changes, check out the <a href="http://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;h=refs/heads/master;hb=…"> jenkins</a> repo.  </td></tr> <tr><td> <a href="http://jenkins.ovirt.org/job/ovirt-node-ng_ovirt-master-experimental_build-…">ovirt-node-ng_ovirt-master-experimental_build-artifacts-el7-x86_64</a> </td><td> This job is automatically updated by jenkins job builder, any manual change will be lost in the next update. If you want to make permanent changes, check out the <a href="http://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;h=refs/heads/master;hb=…"> jenkins</a> repo.  </td></tr> <tr><td> <a href="http://jenkins.ovirt.org/job/ovirt-provider-ovn_master_build-artifacts-el7-…">ovirt-provider-ovn_master_build-artifacts-el7-x86_64</a> </td><td> This job is automatically updated by jenkins job builder, any manual change will be lost in the next update. If you want to make permanent changes, check out the <a href="http://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;h=refs/heads/master;hb=…"> jenkins</a> repo.  </td></tr> <tr><td> <a href="http://jenkins.ovirt.org/job/ovirt-provider-ovn_master_check-merged-el7-x86…">ovirt-provider-ovn_master_check-merged-el7-x86_64</a> </td><td> This job is automatically updated by jenkins job builder, any manual change will be lost in the next update. If you want to make permanent changes, check out the <a href="http://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;h=refs/heads/master;hb=…"> jenkins</a> repo.  </td></tr> <tr><td> <a href="http://jenkins.ovirt.org/job/ovirt_master_system-tests_debug/">ovirt_master_system-tests_debug</a> </td><td> This job is automatically updated by jenkins job builder, any manual change will be lost in the next update. If you want to make permanent changes, check out the <a href="http://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;h=refs/heads/master;hb=…"> jenkins</a> repo.  </td></tr> <tr><td> <a href="http://jenkins.ovirt.org/job/repos_master_check-closure_fc24_merged/">repos_master_check-closure_fc24_merged</a> </td><td> This job is automatically updated by jenkins job builder, any manual change will be lost in the next update. If you want to make permanent changes, check out the <a href="http://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;h=refs/heads/master;hb=…"> jenkins</a> repo.  </td></tr> <tr><td> <a href="http://jenkins.ovirt.org/job/vdsm_4.0_check-merged-fc23-x86_64/">vdsm_4.0_check-merged-fc23-x86_64</a> </td><td> This job is automatically updated by jenkins job builder, any manual change will be lost in the next update. If you want to make permanent changes, check out the <a href="http://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;h=refs/heads/master;hb=…"> jenkins</a> repo.  </td></tr> ------=_Part_1014_2136723980.1480287606307--

1 0

Re: [ovirt-devel] Gerrit headers are not added to commits in vdsm repo
by Nir Soffer 27 Nov '16

27 Nov '16

On Fri, Nov 25, 2016 at 4:45 PM, Tomáš Golembiovský <tgolembi(a)redhat.com> wrote: > Hi, > > I've noticed that in vdsm repo the merged commits do not contain the > info headers added by Gerrit any more (Reviewed-by/Reviewed-on/etc.). > > Is that intentional? If yes, what was the motivation behind this? > > The change seem to have happened about 4 days ago. Sometime between the > following two commits: > > * 505f5da API: Introduce getQemuImageInfo API. [Maor Lipchuk] > * 1c4a39c protocoldetector: Avoid unneeded getpeername() [Nir Soffer] We switched vdsm to fast-forward 4 days ago, maybe this was unintended side effect of this change? The gerrit headers are very useful, please add back. Nir

4 6

[JIRA] (OVIRT-869) Investigate proxy errors from proxy.phx.ovirt.org
by Gil Shinar (oVirt JIRA) 27 Nov '16

27 Nov '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-869?page=com.atlassian.jira.p… ] Gil Shinar commented on OVIRT-869: ---------------------------------- In the log I'm seeing the following error messages: *ConnectionError: HTTPConnectionPool(host='ftp.linux.ncsu.edu', port=80): Max retries exceeded with url: /pub/fedora/linux/updates/23/x86_64/// (Caused by <class 'socket.error'>: [Errno 110] Connection timed out) ConnectionError: HTTPConnectionPool(host='mirror.evolvedservers.com', port=80): Max retries exceeded with url: /CentOS/7.1.1503/os/x86_64//repodata/repomd.xml (Caused by <class 'socket.error'>: [Errno 113] No route to host)* and *ConnectionError: HTTPConnectionPool(host='mirror.evolvedservers.com', port=80): Max retries exceeded with url: /CentOS/7.1.1503/os/x86_64//repodata/repomd.xml (Caused by <class 'socket.error'>: [Errno 101] Network is unreachable)* This one as well: *ConnectionError: HTTPConnectionPool(host='mirror.symnds.com', port=80): Max retries exceeded with url: /CentOS/7.2.1511/os/x86_64//repodata/repomd.xml (Caused by <class 'httplib.BadStatusLine'>: '')* After restart looks like they have gone but we need to find the core of the problem > Investigate proxy errors from proxy.phx.ovirt.org > ------------------------------------------------- > > Key: OVIRT-869 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-869 > Project: oVirt - virtualization made easy > Issue Type: Bug > Reporter: eyal edri [Administrator] > Assignee: infra > Priority: Highest > > We need to make sure jobs don't fail on proxy like [1]. > Either use original repos if proxy is down or add watchdog / alerts for the proxy service. > http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/3693/artif… -- This message was sent by Atlassian JIRA (v1000.571.2#100021)

1 0

[JIRA] (OVIRT-871) unrelated CI failure
by Gil Shinar (oVirt JIRA) 27 Nov '16

27 Nov '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-871?page=com.atlassian.jira.p… ] Gil Shinar commented on OVIRT-871: ---------------------------------- We had an Artifactory issue. Now looks like it is back to normal > unrelated CI failure > -------------------- > > Key: OVIRT-871 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-871 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: danken > Assignee: infra > > Change https://gerrit.ovirt.org/#/c/67101/ just failed on > http://jenkins.ovirt.org/job/ovirt-engine_master_check-patch-fc24-x86_64/80… > which I believe is utterly unrelated to the patch. please resolved the underlying problem. > [ERROR] Failed to execute goal on project restapi-definition: Could not resolve dependencies for project org.ovirt.engine.api:restapi-definition:jar:4.1.0-SNAPSHOT: Failed to collect dependencies at org.ovirt.engine.api:metamodel-runtime:jar:1.1.8: Failed to read artifact descriptor for org.ovirt.engine.api:metamodel-runtime:jar:1.1.8: Could not transfer artifact org.ovirt.engine.api:metamodel-runtime:pom:1.1.8 from/to ovirt-maven-repository (http://artifactory.ovirt.org/artifactory/ovirt-mirror) Failed to transfer file: http://artifactory.ovirt.org/artifactory/ovirt-mirror/org/ovirt/engine/api/…. Return code is: 502 , ReasonPhrase:Proxy Error. -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, please read the following articles: > [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionExcept… > [ERROR] > [ERROR] After correcting the problems, you can resume the build with the command > [ERROR] mvn <goals> -rf :restapi-definition > Makefile:256: recipe for target 'maven' failed > make[1]: *** [maven] Error 1 > make[1]: Leaving directory '/home/jenkins/workspace/ovirt-engine_master_check-patch-fc24-x86_64/ovirt-engine/rpmbuild/BUILD/ovirt-engine-4.1.0' > Makefile:263: recipe for target 'tmp.built' failed > make: *** [tmp.built] Error 2 > error: Bad exit status from /var/tmp/rpm-tmp.2ykGhi (%build) -- This message was sent by Atlassian JIRA (v1000.571.2#100021)

1 0

[JIRA] (OVIRT-872) Re: [ovirt-devel] Gerrit headers are not added to commits in vdsm repo
by Barak Korren (oVirt JIRA) 27 Nov '16

27 Nov '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-872?page=com.atlassian.jira.p… ] Barak Korren updated OVIRT-872: ------------------------------- Resolution: Won't Fix Status: Done (was: To Do) This has to do with the maintainers` chosen working mode for the Gerrit repo - as I replied in the mailing thread. The maintainers need to the decide if they want to change it, and understand the consequences. > Re: [ovirt-devel] Gerrit headers are not added to commits in vdsm repo > ---------------------------------------------------------------------- > > Key: OVIRT-872 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-872 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: eyal edri [Administrator] > Assignee: infra > > I don't see any options to control this from project config, it will > require more investigating to see if its a config option or only available > via cherry-pick. > opening a ticket to track this. > On Sun, Nov 27, 2016 at 1:38 PM, Dan Kenigsberg <danken(a)redhat.com> wrote: > > On Sun, Nov 27, 2016 at 12:31:21PM +0200, Eyal Edri wrote: > > > Not sure I understand what do you mean by Gerrit Headers. > > > Can you give examples? > > > > > > On Fri, Nov 25, 2016 at 4:57 PM, Nir Soffer <nsoffer(a)redhat.com> wrote: > > > > > > > On Fri, Nov 25, 2016 at 4:45 PM, Tomáš Golembiovský < > > tgolembi(a)redhat.com> > > > > wrote: > > > > > Hi, > > > > > > > > > > I've noticed that in vdsm repo the merged commits do not contain the > > > > > info headers added by Gerrit any more (Reviewed-by/Reviewed-on/etc.) > > . > > > > > > > > > > Is that intentional? If yes, what was the motivation behind this? > > > > > > > > > > The change seem to have happened about 4 days ago. Sometime between > > the > > > > > following two commits: > > > > > > > > > > * 505f5da API: Introduce getQemuImageInfo API. [Maor Lipchuk] > > > > > * 1c4a39c protocoldetector: Avoid unneeded getpeername() [Nir > > Soffer] > > > > > > > > We switched vdsm to fast-forward 4 days ago, maybe this was unintended > > > > side effect of this change? > > > > > > > > The gerrit headers are very useful, please add back. > > > > > > https://gerrit.ovirt.org/#/c/66295/ is the last one which had them: > > > > Reviewed-on: https://gerrit.ovirt.org/66295 > > Reviewed-by: Nir Soffer <nsoffer(a)redhat.com> > > Continuous-Integration: Jenkins CI > > > > they are added to the commit message during cherry-pick, and I find them > > very useful. > > > -- > 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.571.2#100021)

1 0