Re: [vdsm] upstream/downstream compat
On Fri, Apr 06, 2012 at 09:58:09AM -0500, Ryan Harper wrote: I've submitted some changes to start some of the work of removing the RHEV/RHEVM names throughout the vdsm code. In one of the patches, there's a good discussion on compatibility with downstream[1] And I wanted to continue that on the mailing list so we could have more eyes; it's not clear to me if everyone is able to see/participate in an inline thread to just one of my patches. To the point; as we look at moving toward an upstream vdsm which may be used stand-alone; ie, it may or may not having ovirt-engine/RHEVM driving actions. I'm interested in hearing details what our requirements for compatibility are and which parts of the tree might be affected. I'd like to posit that downstream compat is the responsibility of the distro versus the upstream community; though that's not a license to make things difficult. IMHO, this means we can do things that help clean up the code or move the project in a particular direction without having to always worry about what the package looks like in a particular distro. Blissful upstream development is great for upstream maintainer (me), but it leads to serious headaches for downstream maintainer with considerable installed base (me). We have a lot of Fedoraisms and RHELisms and RHEVisms in our code. Removing them is noble, probably legally required, and I truly thank whomever cleans up the code. But since there are so many of them, blind removal can add significant burden on yours truly and his colleagues. I would like to ask upstream to think twice before breaking downstream compatibility. Downstream can always revert your patch, but let's make it easier on them^Wus - have a configurable value, so that downstream patch is a oneliner, for example. If an API must be broken, let's file a bug on the adjacent component, so as not to surprise it. So please, worry about how the package would look in particular distros with considerable installed base. Discuss upgrade paths. Help make Vdsm easily downstreamable. The other aspect to compatibility I'd like to hear details/discussion on the interfaces (explicit or implicit) between vdsm and ovirt-engine. I rekindled a discussion[2] on at least one known issue around engine including the qemu machine type in the database; Any pointers to other places would be helpful as I'm wrapping my head around the back and forth between vdsm and engine. 1. http://gerrit.ovirt.org/#patch,unified,3287,1,vds_bootstrap/vds_bootstrap.py 2. http://lists.ovirt.org/pipermail/engine-devel/2012-April/001209.html -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx ry...@us.ibm.com ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [Engine-devel] Is there a preferred workflow when adding additional error messages to VDSM _and_ Engine?
On 07/04/12 18:10, Lee Yarwood wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello all, I'm currently working on a patch to correct the logic used by vdsm when reviewing the logical and physical block size of physical volumes [1]. Once/If this is approved I'd like to look into making the exceptions thrown from vdsm and the errors displayed within engine more descriptive. Before I start throwing patches into gerrit I was wondering *if* there is a preferred workflow when adding additional exceptions and error messages across both projects. For example, committing changes to vdsm before engine, engine before vdsm or both at the same time. Hi Lee, We had a Jenkins Job to give warning if there is a new error code in VDSM that is not covered in the backend. I see this job is disabled in ovirt Jenkins, http://jenkins.ovirt.org/job/vdsm_verify_error_codes/ Eyal, any specific reason this is disabled? Livnat I'm also wondering if there is a way to say that vdsm gerrit changeid x relies on engine gerrit changeid y etc? Thanks in advance, Lee - -- Lee Yarwood Software Maintenance Engineer Red Hat UK Ltd 200 Fowler Avenue IQ Farnborough, Farnborough, Hants GU14 7JP Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham (USA), Brendan Lane (Ireland), Matt Parson(USA), Charlie Peters (USA) GPG fingerprint : A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPgFjGAAoJELymbjP2ci12MScIANRBXgWPSjeSZvSM2+bZmDrD FefJfxMcCQFtTqWYePXIxFgqeeRcFc57+6alExBRU2g9nKZJEIPn2vj640XSTGlt n5T4ItED1IVydzuEXFOAvgaTmZfKzTQkxQWp8QgL6pC7cYgnp2nL7gkbkedx1JyI gCgCGomrHeWP2++vUS8UjtCccZdTJiOiWqoH2sBCKgEVcmFMgvYREK6hTou4DHU4 DcpureWuLvM4HWUlyfl37eXQOmy66A7uHGp3xF5sykQZ9aozaiMFjSoCqQOEVqO6 jHRnsQB6FfF/xU+F/UQK5PKZOm7e+KvrMjhIDfR+/DX3t0rkrtc69gg2O6duy4o= =vdud -END PGP SIGNATURE- ___ Engine-devel mailing list engine-de...@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
[vdsm] Test that broken upstream
Upstream will not currently build because of the following patch: commit 1d4f220616ca6fc014bbdfef7b826a16ed608ddf Author: y kaplan ykap...@redhat.com Date: Thu Apr 5 18:02:40 2012 +0300 Added guestIFTests Change-Id: I8b5138296c098826f149c26d38fd2bfce8794fe4 Reviewed-on: http://gerrit.ovirt.org/3379 Reviewed-by: Dan Kenigsberg dan...@redhat.com Tested-by: Dan Kenigsberg dan...@redhat.com It's import utils before setting up constants. The reason it worked for the committer is that it had VDSM installed on the host so it could import vdsm from site-packages. Please note that when writing tests and try to test with a clean host. We are in the process of having Jenkins plug in to Gerrit to do it for us before we actually commit and break the build. But until then please double check. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
[vdsm] Task and other resource leak problem
Guys,
I'm investigating about resource leak problem about task,job,storage
pool,storage domain.I don't know very deep about the whole scheme, hope
someone can tell if what I found is a problem or not.
task managerthread pool
self.tasks = {}self.__tasks = Queue
| |
|refers(*1.a*) |refers(*1.b*)
|\|/
| task(*1.c*:self.log)
task.jobs[ ]
/|\ |(*2.a*)
（*1.d*) | \|/
job
4 references all together.(*1.a,1.b,1.c,1.d*)
When thread pool call getNextTask reference *1.b* cleared
When Task manager call clearTask reference *1.a* cleared
But reference *1.c* and* 1.d* not cleared.Ref *1.d* and *2.a* make task and
its jobs can't be released
My question is:
When task manager task call clearTask means a task all deleted or will
it be reused or others will clean the remaining reference?
Because task.job sequence never cleared so I assume task should be all
cleared when clearTask to make jobs freed, but the two uncleared
reference confuse me about this.
Would someone give me a hint?
___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/vdsm-devel
