Changed subject line since we've been discussing merge. Guys, what's the accepted or standard way to merge? Should I do a "git merge --squash", "git pull --rebase", or do we want all of the commits? I'm just a little gunshy about making sure it's done exactly as expected.
On Wed, Jan 16, 2013 at 4:29 AM, Wido den Hollander <w...@widodh.nl> wrote: > Hi, > > Update from my side as well. I've re-submitted my patches as the first > series got refused (with good feedback though!) > > On my Github[0] the patches can be found which I sent last weekend. > > I've those make it into 0.5.0 I can also implement the resizing for RBD > images in CloudStack. > > Wido > > [0]: https://github.com/wido/**libvirt-java/commits/snapshot-** > resize-migrate<https://github.com/wido/libvirt-java/commits/snapshot-resize-migrate> > > > On 01/16/2013 04:34 AM, Marcus Sorensen wrote: > >> Just an update (will post this on the feature request as well). With the >> tests patch Ryan provided today, I think we're ready to merge this in. >> That >> is unless it's going to cause problems for the license issues currently >> being worked out, but this is pretty much all new stuff so I don't expect >> it to cause conflicts. >> On Jan 9, 2013 11:16 AM, "Alex Huang" <alex.hu...@citrix.com> wrote: >> >> >>> >>> -----Original Message----- >>>> From: Marcus Sorensen [mailto:shadow...@gmail.com] >>>> Sent: Tuesday, January 08, 2013 10:56 AM >>>> To: >>>> cloudstack-dev@incubator.**apache.org<cloudstack-dev@incubator.apache.org> >>>> Subject: [DISCUSS] resizeVolume >>>> >>>> Guys, >>>> I've pushed this as a new branch called 'resizevolume', in order to >>>> collaborate with a few of you on it. I have several questions on how to >>>> proceed, due to refactoring efforts. I'm hoping that the experts in >>>> those >>>> efforts can collaborate. >>>> >>>> 1) Wido, would you be interested in looking at adding RBD resize to >>>> LibvirtComputingResource? The resize for CLVM and QCOW2 is done via >>>> scripts/storage/qcow2/**resizevolume.sh at the moment, since the >>>> libvirt >>>> bindings won't support volBlockResize until you get 0.5.0 out (and even >>>> then I'm not sure if it will support anything more than just informing >>>> >>> the >>> >>>> hypervisor/guest of the change, which is also in the script). >>>> >>>> 2) I'm not sure exactly how this will be affected by the storage >>>> >>> refactor, >>> >>>> but I'm sure it will be. I looked for examples in the createVolume on >>>> javelin, but it seems that the storage refactor is still early on, and >>>> >>> per >>> >>>> Edison's update only works for a few template commands at the moment. I >>>> thought it best to get this in as a fully fleged member of the storage >>>> >>> API >>> >>>> so that when the work is done on the storage commands, this will get >>>> >>> looked >>> >>>> at as well. So if everything looks good otherwise, I'd like to not block >>>> >>> on >>> >>>> the storage refactor unless this is just going to be scrapped when that >>>> comes along. >>>> >>> >>> I'm sure it will be impacted but check it in and we'll fix it on this end >>> as we merge storage refactor into cloudstack code. >>> >>> >>>> 3) I've implemented resize for Xen, but only tested with local storage >>>> >>> SR. >>> >>>> The SR in devcloud doesn't seem to support online resize, and I'm not >>>> familiar enough with the Xen setup to really figure out if that's just a >>>> byproduct of how the SR was created, whether it's a Xen limitation in >>>> DevCloud, or what. If someone more familiar with Xen wants to take a >>>> peek >>>> it would be appreciated, however I'm not really considering it a blocker >>>> >>> if >>> >>>> nobody does. For now resize works offline (or with data disk detached) >>>> >>> and >>> >>>> fails with warning that VM needs to be stopped or data disk detached. >>>> >>> >>> I'm not sure xen actually supports online resize. It didn't when we >>> started. I'll see if I can get some answers for you. >>> >>> >>>> 4) Can someone who is working with the api refactoring take this into >>>> account? I think I'd prefer it go in before the refactor, or if it >>>> >>> doesn't >>> >>>> that someone help me make any modifications necessary, so that it's not >>>> broken at any point in master. >>>> >>> >>> >>
