[JIRA] (OVIRT-753) ovirt-appliance_master_build-artifacts-el7-x86_64 is ignoring failed commands
by eyal edri [Administrator] (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-753?page=com.atlassian.jira... ]
eyal edri [Administrator] commented on OVIRT-753:
-------------------------------------------------
[~fdeutsch] this job is still not working, is it using the new experimental rpms?
Anything infra team can help with?
> ovirt-appliance_master_build-artifacts-el7-x86_64 is ignoring failed commands
> -----------------------------------------------------------------------------
>
> Key: OVIRT-753
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-753
> Project: oVirt - virtualization made easy
> Issue Type: By-EMAIL
> Reporter: sbonazzo
> Assignee: infra
>
> In:
> http://jenkins.ovirt.org/job/ovirt-appliance_master_build-artifacts-el7-x...
> After appliance shutdown:
> *00:15:44.383* [[ -n "1" ]] && [[ "$(virt-sparsify --help)" =~
> --in-place ]] && ( virt-sparsify --in-place
> ovirt-engine-appliance.qcow2 ; ln ovirt-engine-appliance.qcow2
> ovirt-engine-appliance.qcow2.sparse ; )*00:25:53.734* virt-sparsify:
> error: libguestfs error: guestfs_launch failed.*00:25:53.735* This
> usually means the libguestfs appliance failed to start or
> crashed.*00:25:53.735* See
> http://libguestfs.org/guestfs-faq.1.html#debugging-libguestfs*00:25:53.735*
> or run 'libguestfs-test-tool' and post the *complete* output into
> a*00:25:53.735* bug report or message to the libguestfs mailing list.
> The job should have failed here. Instead, the job continues and fails in a
> later stage:
> *00:33:01.284* ls -shal ovirt-engine-appliance.ova*00:33:01.287* 1.4G
> -rwxr-xr-x. 1 root root 1.4G Oct 6 14:13
> ovirt-engine-appliance.ova*00:33:01.288* echo "all" appliance
> done*00:33:01.290* all appliance done*00:33:01.291* + make
> check*00:33:01.299* make -f image-tools/build.mk
> ovirt-engine-appliance-manifest-rpm*00:33:01.305* make[1]: Entering
> directory `/home/jenkins/workspace/ovirt-appliance_master_build-artifacts-el7-x86_64/ovirt-appliance/engine-appliance'*00:33:01.305*
> guestfish --ro -i -a ovirt-engine-appliance.qcow2 sh 'rpm -qa | sort
> -u' > ovirt-engine-appliance-manifest-rpm*00:41:58.044* libguestfs:
> error: appliance closed the connection unexpectedly.*00:41:58.044*
> This usually means the libguestfs appliance crashed.*00:41:58.044* See
> http://libguestfs.org/guestfs-faq.1.html#debugging-libguestfs*00:41:58.045*
> for information about how to debug libguestfs and report
> bugs.*00:41:58.045* libguestfs: error: guestfs_launch
> failed.*00:41:58.045* This usually means the libguestfs appliance
> failed to start or crashed.*00:41:58.045* See
> http://libguestfs.org/guestfs-faq.1.html#debugging-libguestfs*00:41:58.046*
> or run 'libguestfs-test-tool' and post the *complete* output into
> a*00:41:58.046* bug report or message to the libguestfs mailing
> list.*00:41:58.059* make[1]: *** [ovirt-engine-appliance-manifest-rpm]
> Error 1*00:41:58.059* make[1]: Leaving directory
> `/home/jenkins/workspace/ovirt-appliance_master_build-artifacts-el7-x86_64/ovirt-appliance/engine-appliance'*00:41:58.060*
> make: *** [ovirt-engine-appliance-manifest-rpm] Error 2*00:41:58.065*
> Took 2325 seconds
> wasting 20 minutes of jenkins slave time testing something already known
> broken.
> While working on fixing this job, please investigate while it's failing and
> open a separate issue or bugzilla for it.
> --
> 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.571.2#100021)
8 years
[JIRA] (OVIRT-848) Add support for building containers in oVirt CI
by Barak Korren (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-848?page=com.atlassian.jira... ]
Barak Korren commented on OVIRT-848:
------------------------------------
Some details and considerations about the interaction between containers (specifically Docker-based) and "Standard CI":
There are two possible ways to use Docker from inside mock:
# Install Docker inside the mock environment, and start up the Docker daemon inside it as well.
# Install Docker on the slave VM (The host under mock), Docker client in the mock env, and bind-mount the docket socket ({{/var/run/docker.sock}}) into it.
The obvious benefit of method #1 is that it does not require any adjustments to the existing CI infrastructure (We just need to teach devs how to implement it). I have doubts, however, that mock will not cause some difficulties with this (For example, are cgroups mounted inside mock?). We will need to test this and verify it works.
Method #1 will also cause issues when we come around to implementing something like OVIRT-873 ([Nested Docker is possible but far from recommneded|https://jpetazzo.github.io/2015/09/03/do-not-use-docker-in-docker-for-ci/]) or do anything that causes us to run Docker on the hosts themselves.
Method #2 will not have the same issues as method #1, but it will require us to distribute and maintain Docker on the slaves which is a step back to the pre-Standard-CI era.
I think we should actually implement _both_ methods like this:
# Try to mount the Docker socket into the mock env.
# If it works use method #2
# If it doesn't, use method #1.
This will require a little change to {{mock_runner.sh}} to allow bind mounts to be optional, but this change may provide other benefits so we may as well go for it.
> Add support for building containers in oVirt CI
> -----------------------------------------------
>
> Key: OVIRT-848
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-848
> Project: oVirt - virtualization made easy
> Issue Type: Improvement
> Reporter: eyal edri [Administrator]
> Assignee: infra
>
> more and more projects in oVirt are starting to build containers and using Docker files in their reops.
> We need to start preparing oVirt CI to know how to handle containers and support containers the same way we support rpms today.
> This will be a parent task with multiple sub-tasks that will follow, the following is a draft list of what we might need to do to add this support:
> # Install Registry server ( maybe use openshift.ovirt.org )
> # Add for standard CI 'build-containers.sh' support
> # Add verification steps for the build before publishing to registry
> # Look at 3rd party OSS projects that might help and integrate with existing solutions
--
This message was sent by Atlassian JIRA
(v1000.571.2#100021)
8 years
[JIRA] (OVIRT-873) Implement Standard-CI with containers
by Nadav Goldin (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-873?page=com.atlassian.jira... ]
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)
8 years
[JIRA] (OVIRT-873) Implement Standard-CI with containers
by eyal edri [Administrator] (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-873?page=com.atlassian.jira... ]
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)
8 years
[JIRA] (OVIRT-873) Implement Standard-CI with containers
by Barak Korren (oVirt JIRA)
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)
8 years
[JIRA] (OVIRT-873) Implement Standard-CI with containers
by Barak Korren (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-873?page=com.atlassian.jira... ]
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)
8 years
oVirt infra daily report - unstable production jobs - 151
by jenkins＠jenkins.phx.ovirt.org
------=_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...
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...">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;h...">
jenkins</a> repo.
<!-- Managed by Jenkins Job Builder -->
</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;h...">
jenkins</a> repo.
<!-- Managed by Jenkins Job Builder -->
</td></tr>
<tr><td>
<a href="http://jenkins.ovirt.org/job/ovirt-engine-api-explorer_master_build-artif...">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;h...">
jenkins</a> repo.
<!-- Managed by Jenkins Job Builder -->
</td></tr>
<tr><td>
<a href="http://jenkins.ovirt.org/job/ovirt-engine-api-explorer_master_build-artif...">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;h...">
jenkins</a> repo.
<!-- Managed by Jenkins Job Builder -->
</td></tr>
<tr><td>
<a href="http://jenkins.ovirt.org/job/ovirt-guest-agent_master_build-artifacts-fc2...">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;h...">
jenkins</a> repo.
<!-- Managed by Jenkins Job Builder -->
</td></tr>
<tr><td>
<a href="http://jenkins.ovirt.org/job/ovirt-live_master_experimental_create-iso-el...">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...">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;h...">
jenkins</a> repo.
<!-- Managed by Jenkins Job Builder -->
</td></tr>
<tr><td>
<a href="http://jenkins.ovirt.org/job/ovirt-node-ng_ovirt-3.6_build-artifacts-el7-...">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;h...">
jenkins</a> repo.
<!-- Managed by Jenkins Job Builder -->
</td></tr>
<tr><td>
<a href="http://jenkins.ovirt.org/job/ovirt-node-ng_ovirt-4.0-pre_build-artifacts-...">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;h...">
jenkins</a> repo.
<!-- Managed by Jenkins Job Builder -->
</td></tr>
<tr><td>
<a href="http://jenkins.ovirt.org/job/ovirt-node-ng_ovirt-4.0-snapshot_build-artif...">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;h...">
jenkins</a> repo.
<!-- Managed by Jenkins Job Builder -->
</td></tr>
<tr><td>
<a href="http://jenkins.ovirt.org/job/ovirt-node-ng_ovirt-4.0_build-artifacts-el7-...">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;h...">
jenkins</a> repo.
<!-- Managed by Jenkins Job Builder -->
</td></tr>
<tr><td>
<a href="http://jenkins.ovirt.org/job/ovirt-node-ng_ovirt-master-experimental_buil...">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;h...">
jenkins</a> repo.
<!-- Managed by Jenkins Job Builder -->
</td></tr>
<tr><td>
<a href="http://jenkins.ovirt.org/job/ovirt-provider-ovn_master_build-artifacts-el...">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;h...">
jenkins</a> repo.
<!-- Managed by Jenkins Job Builder -->
</td></tr>
<tr><td>
<a href="http://jenkins.ovirt.org/job/ovirt-provider-ovn_master_check-merged-el7-x...">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;h...">
jenkins</a> repo.
<!-- Managed by Jenkins Job Builder -->
</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;h...">
jenkins</a> repo.
<!-- Managed by Jenkins Job Builder -->
</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;h...">
jenkins</a> repo.
<!-- Managed by Jenkins Job Builder -->
</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;h...">
jenkins</a> repo.
<!-- Managed by Jenkins Job Builder -->
</td></tr>
------=_Part_1014_2136723980.1480287606307--
8 years
Re: [ovirt-devel] Gerrit headers are not added to commits in vdsm repo
by Nir Soffer
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
8 years
