[vdsm] [JENKINS] new job on jenkins.ovirt.org - verify errors codes on engine - vdsm
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. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] VDSM - top 10 with patches with no activity for more than 30 days
Hi, On 02/28/2013 06:51 PM, Doron Fediuck wrote: 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) Review day? Anyone thinks a monthly review day will help? Yes, definitely a review day (announced beforehand) would help - another thing which would help in general is a page where you can see the oldest unreviewed patches. Also, I would love to see us have some social way that people can start reviewing patches when they join the project - there's no better way to understand the project. The best way to lower the number of unreviewed patches is to have more reviewers. Also - as someone not that familiar with Gerrit, what's involved in picking up someone's patch and revising it for them? A pattern I see over over again is: Jane submits patch Alex reviews: -1 with suggestions for improvements Jane submits patch rev #2 Barry reviews: -1 (whitespace issues) Jane submits patch #3 Hoda reviews: -1 with suggestions for another approach Jane loses interest and patch remains *almost* ready forever until it no longer applies or gets dropped. Is there a way we can promote adopt a patch where you take someone else's patch and push it through review? Cheers, Dave. -- Dave Neary - Community Action and Impact Open Source and Standards, Red Hat - http://community.redhat.com Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13 ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] VDSM - top 10 with patches with no activity for more than 30 days
- Original Message - From: Dave Neary dne...@redhat.com To: Doron Fediuck dfedi...@redhat.com Cc: Itamar Heim ih...@redhat.com, vdsm-devel@lists.fedorahosted.org Sent: Wednesday, March 6, 2013 6:54:56 PM Subject: Re: [vdsm] VDSM - top 10 with patches with no activity for more than 30 days Hi, On 02/28/2013 06:51 PM, Doron Fediuck wrote: 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) Review day? Anyone thinks a monthly review day will help? Yes, definitely a review day (announced beforehand) would help - another thing which would help in general is a page where you can see the oldest unreviewed patches. Also, I would love to see us have some social way that people can start reviewing patches when they join the project - there's no better way to understand the project. The best way to lower the number of unreviewed patches is to have more reviewers. Also - as someone not that familiar with Gerrit, what's involved in picking up someone's patch and revising it for them? A pattern I see over over again is: Jane submits patch Alex reviews: -1 with suggestions for improvements Jane submits patch rev #2 Barry reviews: -1 (whitespace issues) Jane submits patch #3 Hoda reviews: -1 with suggestions for another approach Jane loses interest and patch remains *almost* ready forever until it no longer applies or gets dropped. Is there a way we can promote adopt a patch where you take someone else's patch and push it through review? Cheers, Dave. -- Dave Neary - Community Action and Impact Open Source and Standards, Red Hat - http://community.redhat.com Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13 Dave, I agree, but this is also shared by engine dev's, so maybe have a discussion on it in arch list? ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] VDSM - top 10 with patches with no activity for more than 30 days
On 03/06/2013 06:54 PM, Dave Neary wrote: Also - as someone not that familiar with Gerrit, what's involved in picking up someone's patch and revising it for them? A pattern I see over over again is: Jane submits patch Alex reviews: -1 with suggestions for improvements Jane submits patch rev #2 Barry reviews: -1 (whitespace issues) Jane submits patch #3 Hoda reviews: -1 with suggestions for another approach Jane loses interest and patch remains *almost* ready forever until it no longer applies or gets dropped. Is there a way we can promote adopt a patch where you take someone else's patch and push it through review? shouldn't be an issue for someone else to fetch the patch and submit an update to someone else's patch, based on same change-id ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [JENKINS][ANN] jenkins.ovirt.org new look and infra
On 03/05/2013 10:01 AM, Eyal Edri wrote: 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 in...@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. ___ Infra mailing list in...@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra finally... (and looks very nice) can we shutdown the ec2 instance for now? do we have more horsepower to start running say engine findbugs on gerrit patches? Thanks, Itamar ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [JENKINS][ANN] jenkins.ovirt.org new look and infra
- Original Message - From: Itamar Heim ih...@redhat.com To: Eyal Edri ee...@redhat.com Cc: us...@ovirt.org, engine-devel engine-de...@ovirt.org, vdsm-devel@lists.fedorahosted.org, infra in...@ovirt.org Sent: Wednesday, March 6, 2013 11:37:29 PM Subject: Re: [JENKINS][ANN] jenkins.ovirt.org new look and infra On 03/05/2013 10:01 AM, Eyal Edri wrote: 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 in...@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. ___ Infra mailing list in...@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra finally... (and looks very nice) can we shutdown the ec2 instance for now? not yet, me quaid should change the dns 1st (tomorrow)? and then we can do it. do we have more horsepower to start running say engine findbugs on gerrit patches? not really, since we're still using the same ec2 slaves. (unless we'll run it on the master, but that's not recommended in terms of security) once we'll have ovirt instance running with vms, i imagine we can. hopefully we'll have it running soon (either on alterway02 or on the rackspace servers) Thanks, Itamar ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [JENKINS][ANN] jenkins.ovirt.org new look and infra
On 03/06/2013 01:43 PM, Eyal Edri wrote: - Original Message - From: Itamar Heim ih...@redhat.com can we shutdown the ec2 instance for now? not yet, me quaid should change the dns 1st (tomorrow)? and then we can do it. If the host thinks it's already jenkins.ovirt.org, then we can just do the DNS switch soonest. Do we need to coordinate more closely on timing? Otherwise I can just file the ticket. (I'll wait for your word before picking a time.) do we have more horsepower to start running say engine findbugs on gerrit patches? not really, since we're still using the same ec2 slaves. (unless we'll run it on the master, but that's not recommended in terms of security) once we'll have ovirt instance running with vms, i imagine we can. hopefully we'll have it running soon (either on alterway02 or on the rackspace servers) I was supposed to be working RackSpace servers today, but I got caught up in being a bit sick and post-travel. But the plan is to load F18 + the oVirt all-in-one on rax01. - Karsten -- Karsten 'quaid' Wade, Sr. Analyst - Community Growth http://TheOpenSourceWay.org .^\ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 signature.asc Description: OpenPGP digital signature ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
[vdsm] VDSM test unit running path
Hi, Now, The VDSM test unit is expected to run in a un-installed enviornment and use hackVDSM() to fake modules importing. hackVDSM() is pretty tricky for other modules to be added because of the dependency order. I would propose to run the VDSM unit tests in a installed VDSM path which is the same path as other VDSM runnable binaries. By this way, we can abandon hackVDSM() and run the unit test normally. On the other hand, the VDSM building script installs the VDSM files to home/builder by default, it is reasonable to start the VDSM unit test after all parts of the building script finishes. Any comments about this idea? -- --- 舒明 Shu Ming Open Virtualization Engineerning; CSTL, IBM Corp. Tel: 86-10-82451626 Tieline: 9051626 E-mail: shum...@cn.ibm.com or shum...@linux.vnet.ibm.com Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
