Re: [vdsm] Jenkins testing.
On 08/14/2012 04:54 AM, Deepak C Shetty wrote: On 08/14/2012 12:52 PM, Deepak C Shetty wrote: On 08/14/2012 11:13 AM, Robert Middleswarth wrote: After a few false starts it looks like we have per patch testing working on VDSM, oVirt-engine, oVirt-engine-sdk and oVirt-engine-cli. There are 3 status a patch can get. 1) Success - Means the patch ran though the tests without issue. 2) Failure - Means the tests failed. 3) Aborted - Generally means the submitter is not in the whitelist and the tests were never run. If you have any questions please feel free to ask. So what is needed for the submitted to be in whitelist ? I once for Success for few of my patches.. then got failure for some other patch( maybe thats due to the false starts u had) and then for the latest patch of mine, it says aborted. So not sure if i am in whitelist or not ? If not, what do i need to do to be part of it ? If yes, why did the build abort for my latest patch ? Pls see http://gerrit.ovirt.org/#/c/6856/ For patch1 it says build success, for patch 2, it says aborted.. why ? All the abort means as a protective measure we don't run the tests unless we know the committer. With that said you are now in the whitelist so it shouldn't be an issue in the feature. -- Thanks Robert Middleswarth @rmiddle (twitter/Freenode IRC) @RobertM (OFTC IRC) ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Jenkins testing.
On 08/22/2012 12:03 AM, Deepak C Shetty wrote: On 08/22/2012 07:40 AM, Robert Middleswarth wrote: On 08/14/2012 04:54 AM, Deepak C Shetty wrote: On 08/14/2012 12:52 PM, Deepak C Shetty wrote: On 08/14/2012 11:13 AM, Robert Middleswarth wrote: After a few false starts it looks like we have per patch testing working on VDSM, oVirt-engine, oVirt-engine-sdk and oVirt-engine-cli. There are 3 status a patch can get. 1) Success - Means the patch ran though the tests without issue. 2) Failure - Means the tests failed. 3) Aborted - Generally means the submitter is not in the whitelist and the tests were never run. If you have any questions please feel free to ask. So what is needed for the submitted to be in whitelist ? I once for Success for few of my patches.. then got failure for some other patch( maybe thats due to the false starts u had) and then for the latest patch of mine, it says aborted. So not sure if i am in whitelist or not ? If not, what do i need to do to be part of it ? If yes, why did the build abort for my latest patch ? Pls see http://gerrit.ovirt.org/#/c/6856/ For patch1 it says build success, for patch 2, it says aborted.. why ? All the abort means as a protective measure we don't run the tests unless we know the committer. With that said you are now in the whitelist so it shouldn't be an issue in the feature. Thanks for putting me in the whitelist. But it still doesn't clarify how patch 1 got build success and subsequent patch 2 had abort ? Patch 1 happened in the small window well I was testing before the whitelist went live. Patch 2 happened after the whitelist went live. Since you are now in the whitelist all new patches for you will run. -- Thanks Robert Middleswarth @rmiddle (twitter/Freenode IRC) @RobertM (OFTC IRC) ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Jenkins and Gerrit.
On 08/09/2012 03:30 AM, Dan Kenigsberg wrote: On Wed, Aug 08, 2012 at 03:53:35PM -0400, Robert Middleswarth wrote: On 08/08/2012 03:07 PM, Dan Kenigsberg wrote: On Wed, Aug 08, 2012 at 09:58:17AM -0400, Robert Middleswarth wrote: On 08/08/2012 09:50 AM, Dan Kenigsberg wrote: On Wed, Aug 08, 2012 at 02:55:17PM +0200, Ewoud Kohl van Wijngaarden wrote: On Wed, Aug 08, 2012 at 03:48:13PM +0300, Dan Kenigsberg wrote: On Wed, Aug 08, 2012 at 07:47:02AM -0400, Robert Middleswarth wrote: I have setup patch review on Jenkins.info for newly submitted patches and it seems to be working pretty well over all but last night well tweaking the process I broken it for a few min but that was long enough that about 50 jobs were marked -1 I will be fixing that today by rerunning the jobs. I am sorry if one of your patches was dinged and it should be fixed by this time tomorrow. Thanks, Robert, for working on this. It is highly important for me to know that something is going to break the build before taking it in. However, would it be possible to have a repository where we can review the code of the robot? It's Gerrit Trigger[1] and the code is on github[2]. I think it is important for the robot to be less noisy, and particularly, never give V+1. This task is reserved to humans that actually know what the patch should be doing. The V+1 has been fixed. Will give 0 when they pass, -1 when they fail. Also, I am not at all sure that the robot is limitting itself to be running code of trustworthy authors. Eyal added a feature request for this[3]. This was the result of a discussion on the infra mailing list[4]. As much as I like (and need) this per-commit verification, I think we should not deploy it before the feature is implemented. BTW, Federico suggested to initiate the test only on request (when oVirt Jenkins CI Server is added as reviewer). This would allow a more silent start for CI. Thanks, Dan. I already wrote a little bash code to do this outside the plug-in. It will be in place by the end of the day. This kind of script is exactly the thing I'd like to be peer-reviewed before applied en mass to gerrit changes. Particularly due to the security implications. Regards, Dan. If you are talking about the jenkins app that updates Gerrit that is has been in use on ovirt-node-devel for some time. As for the whitelist script that is like 4 lines. git log --pretty=%ce -n 1 $WORKSPACE/current_author.txt Are we sure that the top author is good enough? What if a trusted user builds on top of a non-trusted user? Does it mean that the lower commits are automatically trusted? You would assume that is someone we trusted were to use code from a non-trusted users they reviewed the code to make sure there wasn't some code in there to try and hack the system. Once you take the code and include it you have taken ownership of that code. Thanks Robert grep -f $WORKSPACE/current_author.txt $WORKSPACE/jenkins-whitelist.txt RETVAL=$? [ $RETVAL -ne 0 ] curl -u jenkins_bot:xx $BUILD_URL/stop; It is simple and the files are generated outside of the repo so it should be safe. -- Thanks Robert Middleswarth @rmiddle (twitter/IRC) ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Jenkins and Gerrit.
On 08/09/2012 03:37 AM, Eyal Edri wrote: - Original Message - From: Robert Middleswarth rob...@middleswarth.net To: Dan Kenigsberg dan...@redhat.com Cc: VDSM Project Development vdsm-devel@lists.fedorahosted.org, infra in...@ovirt.org Sent: Wednesday, August 8, 2012 10:53:35 PM Subject: Re: [vdsm] Jenkins and Gerrit. On 08/08/2012 03:07 PM, Dan Kenigsberg wrote: On Wed, Aug 08, 2012 at 09:58:17AM -0400, Robert Middleswarth wrote: On 08/08/2012 09:50 AM, Dan Kenigsberg wrote: On Wed, Aug 08, 2012 at 02:55:17PM +0200, Ewoud Kohl van Wijngaarden wrote: On Wed, Aug 08, 2012 at 03:48:13PM +0300, Dan Kenigsberg wrote: On Wed, Aug 08, 2012 at 07:47:02AM -0400, Robert Middleswarth wrote: I have setup patch review on Jenkins.info for newly submitted patches and it seems to be working pretty well over all but last night well tweaking the process I broken it for a few min but that was long enough that about 50 jobs were marked -1 I will be fixing that today by rerunning the jobs. I am sorry if one of your patches was dinged and it should be fixed by this time tomorrow. Thanks, Robert, for working on this. It is highly important for me to know that something is going to break the build before taking it in. However, would it be possible to have a repository where we can review the code of the robot? It's Gerrit Trigger[1] and the code is on github[2]. I think it is important for the robot to be less noisy, and particularly, never give V+1. This task is reserved to humans that actually know what the patch should be doing. The V+1 has been fixed. Will give 0 when they pass, -1 when they fail. Also, I am not at all sure that the robot is limitting itself to be running code of trustworthy authors. Eyal added a feature request for this[3]. This was the result of a discussion on the infra mailing list[4]. As much as I like (and need) this per-commit verification, I think we should not deploy it before the feature is implemented. BTW, Federico suggested to initiate the test only on request (when oVirt Jenkins CI Server is added as reviewer). This would allow a more silent start for CI. Thanks, Dan. I already wrote a little bash code to do this outside the plug-in. It will be in place by the end of the day. This kind of script is exactly the thing I'd like to be peer-reviewed before applied en mass to gerrit changes. Particularly due to the security implications. Regards, Dan. If you are talking about the jenkins app that updates Gerrit that is has been in use on ovirt-node-devel for some time. As for the whitelist script that is like 4 lines. git log --pretty=%ce -n 1 $WORKSPACE/current_author.txt grep -f $WORKSPACE/current_author.txt $WORKSPACE/jenkins-whitelist.txt RETVAL=$? [ $RETVAL -ne 0 ] curl -u jenkins_bot:xx $BUILD_URL/stop; It is simple and the files are generated outside of the repo so it should be safe. i think it's better to use $GERRIT_CHANGE_OWNER_NAME or $GERRIT_CHANGE_OWNER_EMAIL. I didn't see that documented any places and your are right $GERRIT_CHANGE_OWNER_EMAIL would be a better choice. Test updated to use that variable. Thanks Robert -- Thanks Robert Middleswarth @rmiddle (twitter/IRC) ___ Infra mailing list in...@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra -- Thanks Robert Middleswarth @rmiddle (twitter/IRC) ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
[vdsm] Jenkins and Gerrit.
I have setup patch review on Jenkins.info for newly submitted patches and it seems to be working pretty well over all but last night well tweaking the process I broken it for a few min but that was long enough that about 50 jobs were marked -1 I will be fixing that today by rerunning the jobs. I am sorry if one of your patches was dinged and it should be fixed by this time tomorrow. -- Thanks Robert Middleswarth @rmiddle (twitter/IRC) ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Jenkins and Gerrit.
On 08/08/2012 08:48 AM, Dan Kenigsberg wrote: On Wed, Aug 08, 2012 at 07:47:02AM -0400, Robert Middleswarth wrote: I have setup patch review on Jenkins.info for newly submitted patches and it seems to be working pretty well over all but last night well tweaking the process I broken it for a few min but that was long enough that about 50 jobs were marked -1 I will be fixing that today by rerunning the jobs. I am sorry if one of your patches was dinged and it should be fixed by this time tomorrow. Thanks, Robert, for working on this. It is highly important for me to know that something is going to break the build before taking it in. However, would it be possible to have a repository where we can review the code of the robot? It is the Jenkins Gerrit Tigger bot direct from jenkins-ci.org that is running the same unit jenkins has been running just against new patches. I think it is important for the robot to be less noisy, and particularly, never give V+1. Already adjusted new runs will give -1 for fail but 0 for success going forward. There were about 400 jobs/patches it gave +1 to if needed those can be re-run please let me know is this is required. This task is reserved to humans that actually know what the patch should be doing. Also, I am not at all sure that the robot is limitting itself to be running code of trustworthy authors. That is correct the reason there were some fails last night was my attempt to add in the limit and I broke things for a few min. I have already tested all the logic and should be in place by the end of today. Regards, Dan. -- Thanks Robert Middleswarth @rmiddle (twitter/IRC) ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Jenkins and Gerrit.
On 08/08/2012 03:07 PM, Dan Kenigsberg wrote: On Wed, Aug 08, 2012 at 09:58:17AM -0400, Robert Middleswarth wrote: On 08/08/2012 09:50 AM, Dan Kenigsberg wrote: On Wed, Aug 08, 2012 at 02:55:17PM +0200, Ewoud Kohl van Wijngaarden wrote: On Wed, Aug 08, 2012 at 03:48:13PM +0300, Dan Kenigsberg wrote: On Wed, Aug 08, 2012 at 07:47:02AM -0400, Robert Middleswarth wrote: I have setup patch review on Jenkins.info for newly submitted patches and it seems to be working pretty well over all but last night well tweaking the process I broken it for a few min but that was long enough that about 50 jobs were marked -1 I will be fixing that today by rerunning the jobs. I am sorry if one of your patches was dinged and it should be fixed by this time tomorrow. Thanks, Robert, for working on this. It is highly important for me to know that something is going to break the build before taking it in. However, would it be possible to have a repository where we can review the code of the robot? It's Gerrit Trigger[1] and the code is on github[2]. I think it is important for the robot to be less noisy, and particularly, never give V+1. This task is reserved to humans that actually know what the patch should be doing. The V+1 has been fixed. Will give 0 when they pass, -1 when they fail. Also, I am not at all sure that the robot is limitting itself to be running code of trustworthy authors. Eyal added a feature request for this[3]. This was the result of a discussion on the infra mailing list[4]. As much as I like (and need) this per-commit verification, I think we should not deploy it before the feature is implemented. BTW, Federico suggested to initiate the test only on request (when oVirt Jenkins CI Server is added as reviewer). This would allow a more silent start for CI. Thanks, Dan. I already wrote a little bash code to do this outside the plug-in. It will be in place by the end of the day. This kind of script is exactly the thing I'd like to be peer-reviewed before applied en mass to gerrit changes. Particularly due to the security implications. Regards, Dan. If you are talking about the jenkins app that updates Gerrit that is has been in use on ovirt-node-devel for some time. As for the whitelist script that is like 4 lines. git log --pretty=%ce -n 1 $WORKSPACE/current_author.txt grep -f $WORKSPACE/current_author.txt $WORKSPACE/jenkins-whitelist.txt RETVAL=$? [ $RETVAL -ne 0 ] curl -u jenkins_bot:xx $BUILD_URL/stop; It is simple and the files are generated outside of the repo so it should be safe. -- Thanks Robert Middleswarth @rmiddle (twitter/IRC) ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Avoid testStressTest Failing in Jenkins VDSM Unit Tests Job
On 08/08/2012 10:37 PM, Zhou Zheng Sheng wrote: Hi all, Recently the oVirt Jenkins runs unit test for every new patch set in Gerrit. There are a lot of new patch sets every day, so the Jenkins may run the unit tests in parallel. I notice that most of the unit tests can be run in parallel except testStressTest. testStressTest creates lots of threads nearly to the system limit, so if we run two or more testStressTest, it will fail, giving false positives. We found this when we started running 5 of them at once. I have since limited the job to one per host. To stop the failures. I though I had resubmitted all the jobs that failed because of that. So I suggest the oVirt Jenkins run most of the tests in parellel, but run testStressTest exlusively. With the help of the Exclusion-Plugin, it its possible to configure Jenkins to run some steps in parellel while some steps exclusive in one job. Firstly, add a resource with the help of Exclusion-Plugin. Give a meaningful name to that resource, and assign the resource to this Job. Secondly, add a build step of Execute Shell, in this step, run all the tests other than testStressTest. So the shell script can be as follow. cd tests NOSE_EXCLUDE=testStressTest \ ./run_tests_local.sh \ --with-xunit --xunit-file=nosetests0.xml \ *.py Then add a build step of Critical Block Start. Then add a build step of Execute Shell, in this step, only run testStressTest as follow. cd tests ./run_tests_local.sh -m testStressTest \ --with-xunit --xunit-file=nosetests1.xml \ resourceManagerTests.py Then add a build step of Critical BlockEnd. At last, in post-build actions, in the Publish Test Result Report section, modify the test report XMLs to tests/nosetests*.xml. Jenkins will merge the test reports. Some patch sets are marked as verify failure by oVirt Jenkins. Most of them fails in testStressTest. I hope this can help the oVirt Jenkins a little bit. This information is useful to know. I wonder if we could just remove the stress test from the patch test and just leave it on the master branch tests. -- Thanks Robert Middleswarth @rmiddle (twitter/IRC) ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Getting rid of a...@ovirt.org?
On 07/15/2012 03:59 PM, Ayal Baron wrote: - Original Message - -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/15/2012 01:53 AM, Ayal Baron wrote: Hi all, Sorry for cross-posting, but in this case I think it's relevant. The original idea was that every time we wish to discuss a new cross-component feature we should do it over arch list. However, it would appear that de-facto usually engine-devel and vdsm-devel are being used (cross posted). Currently engine-devel has 211 subscribers, arch has 160 and vdsm-devel has 128 so from this perspective again, arch seems less relevant. I propose we ditch arch and keep the other 2 mailing lists. I'm not sure whether new cross-component features should be discussed solely on engine-devel or cross-posted (there are probably people who wouldn't care about engine side but would still like to know about such changes). Thoughts? - -1 I don't normally read engine-devel and vdsm-devel, so I hadn't noticed that discussions I would expect to be on arch@ are not happening here. I'm probably not the only person in that situation. If this project were 100% about Engine and VDSM, then I could understand your reasoning. But we've already added a few new incubating projects, we have subsystem teams such as documentation and infrastructure, and we all need a single location where we know we can reach *all* contributors to this project. If we try to force all that discussion on to engine-devel, not everyone would be interested. There is enough on engine-devel that is not general interest that it would become noise (as it has for me, so I filter it) or people would drop it all together. Perhaps what we need to do is have the discipline to cross-post *all* general interest discussions from the project mailing list back to arch@? Enforce the rule that decisions that affect the whole project have to be ratified on arch@ instead of whatever project list the discussions started on? Strongly suggest that all contributors be on arch@ and announce@ as a minimum? I find that anything that should go on arch would interest anyone on the devel lists (as it is about new features, design, etc) so I believe that arch should have at least everyone on engine-devel and vdsm-devel. However, right now this is not the case as is evident by number of subs to each list (e.g. I haven't compared to see if everyone on arch is on engine). So imo something needs to be done. I'm fine with keeping arch, but as you said, that means we need to enforce it to be *the* list for feature discussions and I'm not exactly sure how you'd go about doing that. Maybe arch needs renamed to make it clear what if is for? Maybe something simple like ovirt-devel to make it clear it is for generally ovirt development? Thanks Robert I'm sure there are open source projects that don't have a general interest contributor list, preferring to run all that discussion on a technical-focused list. But I don't recommend it. It's the kind of thing that repels contributors who don't want to sort through deep developer discussions just to find out what is generally going on. - - Karsten - -- Karsten 'quaid' Wade, Sr. Analyst - Community Growth http://TheOpenSourceWay.org .^\ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFQAxvi2ZIOBq0ODEERAlaXAKDMCwHjZzS/mtWkzvYt+Px+iEhl/wCZASvN AYHTXhHYq33yJMebr4bmijE= =iBdY -END PGP SIGNATURE- ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel ___ 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
Re: [vdsm] Creating a new VM with a template
On 07/11/2012 09:08 AM, Shu Ming wrote: Hi, I created a VM with from existing template and found that the image of the new VM actually copied the image from the template instead of sharing a base from the template. I am wondering why the new VM doesn't use a new cow image as its image pointing to the base image in template. By that way, all the new VMs will share a common parent image in template and save the space in the storage domain. Is there any other concern not to do this? Under Resource Allocation did you use Thin or Clone when creating the VM from template? Thin will share the base and just use a cow image. Clone will copy the VM. Thanks Robert ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [RFC] An alternative way to provide a supported interface -- libvdsm
On 07/05/2012 04:45 PM, Adam Litke wrote: On Thu, Jul 05, 2012 at 03:47:42PM -0400, Saggi Mizrahi wrote: - Original Message - From: Adam Litke a...@us.ibm.com To: Saggi Mizrahi smizr...@redhat.com Cc: Anthony Liguori anth...@codemonkey.ws, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Thursday, July 5, 2012 2:34:50 PM Subject: Re: [RFC] An alternative way to provide a supported interface -- libvdsm On Wed, Jun 27, 2012 at 02:50:02PM -0400, Saggi Mizrahi wrote: The idea of having a supported C API was something I was thinking about doing (But I'd rather use gobject introspection and not schema generation) But the problem is not having a C API is using the current XML RPC API as it's base I want to disect this a bit to find out exactly where there might be agreement and disagreement. C API is a good thing to implement - Agreed. I also want to use gobject introspection but I don't agree that using glib precludes the use of a formalized schema. My proposal is that we write a schema definition and generate the glib C code from that schema. I agree that the _current_ xmlrpc API makes a pretty bad base from which to start a supportable API. XMLRPC is a perfectly reasonable remote/wire protocol and I think we should continue using it as a base for the next generation API. Using a schema will ensure that the new API is well-structured. There major problems with XML-RPC (and to some extent with REST as well) are high call overhead and no two way communication (push events). Basing on XML-RPC means that we will never be able to solve these issues. I am not sure I am ready to conceed that XML-RPC is too slow for our needs. Can you provide some more detail around this point and possibly suggest an alternative that has even lower overhead without sacrificing the ubiquity and usability of XML-RPC? As far as the two-way communication point, what are the options besides AMQP/ZeroMQ? Aren't these even worse from an overhead perspective than XML-RPC? Regarding two-way communication: you can write AMQP brokers based on the C API and run one on each vdsm host. Assuming the C API supports events, what else would you need? I personally think that using something like AMQP for inter-node communication and engine - node would be optimal. With a rest interface that just send messages though something like AMQP. Thanks Robert The current XML-RPC API contains a lot of decencies and inefficiencies and we would like to retire it as soon as we possibly can. Engine would like us to move to a message based API and 3rd parties want something simple like REST so it looks like no one actually wants to use XML-RPC. Not even us. I am proposing that AMQP brokers and REST APIs could be written against the public API. In fact, they need not even live in the vdsm tree anymore if that is what we choose. Core vdsm would only be responsible for providing libvdsm and whatever language bindings we want to support. If we take the libvdsm route, the only reason to even have a REST bridge is only to support OSes other then Linux which is something I'm not sure we care about at the moment. That might be true regarding the current in-tree implementation. However, I can almost guarantee that someone wanting to write a web GUI on top of standalone vdsm would want a REST API to talk to. But libvdsm makes this use case of no concern to the core vdsm developers. I do think that having C supportability in our API is a good idea, but the current API should not be used as the base. Let's _start_ with a schema document that describes today's API and then clean it up. I think that will work better than starting from scratch. Once my schema is written I will post it and we can 'patch' it as a community until we arrive at a 1.0 version we are all happy with. +1 Ok. Redoubling my efforts to get this done. Describing the output of list(True) takes awhile :) ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Agenda for tomorrow's call
From the US I am getting the conf number is invald? On 06/18/2012 09:31 AM, Deepak C Shetty wrote: On 06/17/2012 11:34 PM, Dan Kenigsberg wrote: Hi! tomorrow I would like to discuss: - the abysmal review condition of the rest api patches - vdsm status for ovirt-3.1 I know networking requires a heavy cherry-pick from upstream. There is probably more. Everybody invited to care for vdsm bugs that blocks Bug 822145 - Tracker: oVirt 3.1 release. - plenty pep8 patches applied, but there is plenty more. - Patches with pending verification. I see 11 of those now http://gerrit.ovirt.org/#/q/status:open+project:vdsm+verified%253D0+codereview%253E%253D%252B2+-codereview%253C%253D-1,n,z Please do not send your patches out to the cold and desert them there. Pet them, nag folks to review and verify them, and rebase (only!) when required. - Your issue comes here (or above, if it's more urgent). Regards, Dan. Hello Dan, The India dial in ... India Dial-In #: 000-800-650-1533 never works.. so I am unable to connect to this call from home. I cannot use the other India number as that is not supported for my telecom carrier. Who can help in resolving this issue. The above number always results in a 'engage' tone. It never asks for conf. id. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
