Merged. On Wed, Jan 16, 2013 at 5:05 PM, Edison Su <edison...@citrix.com> wrote:
> Better to use "git pull --rebase", which is cleaner than "git merge". > If you can squash your changes into small commits before push, that will > be even better:) > > > -----Original Message----- > > From: Marcus Sorensen [mailto:shadow...@gmail.com] > > Sent: Wednesday, January 16, 2013 3:57 PM > > To: cloudstack-dev@incubator.apache.org > > Subject: Re: [MERGE] resizeVolume > > > > 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-r > > > esize-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- > > d...@incubator.apac > > >>>> he.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. > > >>>> > > >>> > > >>> > > >> >
