[JENKINS][ANN] jenkins.ovirt.org new look and infra
by eedri＠redhat.com
fyi,
Starting from yesterday (4/3/13) jenkins.ovirt.org [1] has migrated to a new hosting server provided by alterway [2].
the new server has a new ui look that is similar to ovirt.org and is running on stronger infra then the previous one.
All jobs and configuration have migrated from the old instance,
but if you're still missing a certain job or permissions please contact infra team at infra(a)ovirt.org.
I want to thank David caro from the infra team in helping with the migration and einav cohen from the
ovirt frontend developer community for helping with the new css for jenkins.
[1] http://jenkins.ovirt.org/
[2] http://www.ovirt.org/Sponsors_and_supporters
Eyal Edri
oVirt infra team.
11 years, 2 months
VDSM - top 10 with patches with no activity for more than 30 days
by iheim＠redhat.com
thoughts on how to trim these?
(in openstack gerrit they auto-abandon patches with no activity for a
couple of weeks - author can revive them back when they are relevant)
preferred_email | count
----------------------------+------
fsimonce(a)redhat.com | 34
smizrahi(a)redhat.com | 23
lvroyce(a)linux.vnet.ibm.com | 13
ewarszaw(a)redhat.com | 12
wudxw(a)linux.vnet.ibm.com | 12
xuhj(a)linux.vnet.ibm.com | 11
shaohef(a)linux.vnet.ibm.com | 6
lilei(a)linux.vnet.ibm.com | 6
zhshzhou(a)linux.vnet.ibm.com | 6
shuming(a)linux.vnet.ibm.com | 5
11 years, 2 months
[JENKINS] new job on jenkins.ovirt.org - verify errors codes on engine <-> vdsm
by eedri＠redhat.com
fyi,
a new job has been added (more liked fixed) - http://jenkins.ovirt.org/view/vdsm/job/vdsm_verify_error_codes/
Job Desc:
"
The purpose of this jenkins job is verify each error code reported by VDSM
has a correlated message on the engine side, else we get the 'Unexpected error'.
The missing error code should be added to:
ovirt-engine/backend/manager/modules/common/src/main/java/org/ovirt/engine/core/common/errors/VdcBllErrors.java
and the error message to:
ovirt-engine/backend/manager/modules/dal/src/main/resources/bundles/VdsmErrors.properties
If a specific VDSM error code should not be reported by VDSM and needed to be ignored, we can add it to the 'ignored list' of the jenkins job.
"
please notice if this job breaks after your commit, it will probably mean you changed/added an error code in one
component but not in the other.
eyal edri
oVirt infra team.
11 years, 2 months
VDSM Repository Reorganization
by Federico Simoncelli
It is some time now that we are discussing an eventual repository
reorganization for vdsm. In fact I'm sure that we all experienced
at least once the discomfort of having several modules scattered
around the tree.
The main goal of the reorganization would be to place the modules
in their proper location so that they can be used (imported) without
any special change (or hack) even when the code is executed inside
the development repository (e.g. tests).
Recently there has been an initial proposal about moving some of
these modules:
http://gerrit.ovirt.org/#/c/11858/
That spawned an interesting discussion that must involve the entire
community; in fact before starting any work we should try to converge
on a decision for the final repository structure in order to minimize
the discomfort for the contributors that will be forced to rebase
their pending gerrit patches. Even if the full reorganization won't
happen in a short time I think we should plan the entire structure
now and then eventually move only few relevant modules to their final
location.
To start the discussion I'm attaching here a sketch of the vdsm
repository structure that I envision:
.
|-- client
| |-- [...]
| `-- vdsClient.py
|-- common
| |-- [...]
| |-- betterPopen
| | `-- [...]
| `-- vdsm
| |-- [...]
| `-- config.py
|-- contrib
| |-- [...]
| |-- nfs-check.py
| `-- sos
|-- daemon
| |-- [...]
| |-- supervdsm.py
| `-- vdsmd
`-- tool
|-- [...]
`-- vdsm-tool
This would allow any component (daemon, client, tool, etc...) to run
in place with the only addition of PYTHONPATH=$(top_srcdir)/common.
The tests would need also the additional component path but that is
a given since it's what they should be testing.
Once the components are in the proper place we can eventually start
using distutils inside the Makefile.am files in order to simplify the
installation process (and also as verification that our repository
structure is complying with the python standards).
Please get involved, share your feedback and proposals.
Thanks,
--
Federico
11 years, 2 months
