Yoshikazu fixed the issue related to qemu-img which introduced by his patch in cloudstack-6191. But there is another issue introduced by commit: a600d8408ea86782318139c17cf346c8497943d0, which causes starting vm failure. So I checked in a commit: e1095b0110f08fb0c7965f9cf293a6073bbce511, to fix CLOUDSTACK-7051. So I think, both CLOUDSTACK-6191 and CLOUDSTACK-7051 should be fixed now, no need to revert or change CLOUDSTACK-6191.
> -----Original Message----- > From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] > Sent: Saturday, July 12, 2014 11:02 AM > To: dev > Subject: Re: [DISCUSS]CLOUDSTACK-6191 > > -0 What does it fix and is the solution bonifide. We should fix the test > suite if > it is. The test suite not working is not enough reason to revert a commit, it > should block the test-suite because the system is broken, not because of the > way the test suite works. > > Disclaimer: I do not know enough of KVM to make a judgement call. I just got > triggered by the motivation in the mail thread. > > On Sat, Jul 12, 2014 at 12:21 AM, Rayees Namathponnan > <rayees.namathpon...@citrix.com> wrote: > > +1 Revert now and enable after complete full test in KVM > > > > KVM automation blocked more than 7 days due to this defect > > > > https://issues.apache.org/jira/browse/CLOUDSTACK-7051 > > > > Regards, > > Rayees > > > > -----Original Message----- > > From: Edison Su [mailto:edison...@citrix.com] > > Sent: Friday, July 11, 2014 2:49 PM > > To: dev@cloudstack.apache.org > > Subject: [DISCUSS]CLOUDSTACK-6191 > > > > Move the discussion to the list about CloudStack-6191: > > Automation test is blocked by this bug, we need to find a solution. My > suggestion is sort-of-revert-the-patch, but still give admin the opportunity > to > specify the way to optimize KVM volume creation. The reasons: > > > > 1. End user shouldn't care about how the volume is created, is it > sparse,flat/thin-provisoned or whatever technology used by hypervisor. So > we'd better not expose this option in disk offering. > > > > 2. It's true that admin does care about how the volume is created, so > we can add a global configuration just for the kvm volume creation. For > vmware, the option is already there(vmware.create.full.clone to control > whether link clone or full clone is used to create volume). We can add an > option, something like kvm.qcow2.volume.create.options. > > Comments? > > > > -- > Daan
