Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of Edison.su@citrix.com
 designates 66.165.176.89 as permitted sender)
From: Edison Su <Edison.su@citrix.com>
To: "cloudstack-dev@incubator.apache.org"
	<cloudstack-dev@incubator.apache.org>
Date: Wed, 16 Jan 2013 16:05:58 -0800
Subject: RE: [MERGE] resizeVolume
Thread-Topic: [MERGE] resizeVolume
Thread-Index: Ac30RU+Nk/Gu+N6vTniZxszB18WYWgAAHBgw
Message-ID: 
 <C66C814C1ABFA8449FF65CB44953A8B4012CBF3A5781@SJCPMAILBOX01.citrite.net>
References: 
 <CALFpzo57U9wEv0wNuRsGqwSoOsf7LsM05_QLh84PO9sr+j-fVg@mail.gmail.com>
	<B1DF26ECC0458748AC97CECE2DA98D41012FA385EF56@SJCPMAILBOX01.citrite.net>
	<CALFpzo4tvonpHJCOMx9aczVOZd=BQ9ah7PspAJbUq5A-0unTUw@mail.gmail.com>
	<50F68F1E.60107@widodh.nl>
 <CALFpzo6nZrqbL6oSV3exZAKQKYZZs8Cj8kP-z4b7zoHvMk_8uQ@mail.gmail.com>
In-Reply-To: 
 <CALFpzo6nZrqbL6oSV3exZAKQKYZZs8Cj8kP-z4b7zoHvMk_8uQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

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:shadowsor@gmail.com]
> Sent: Wednesday, January 16, 2013 3:57 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: [MERGE] resizeVolume
>=20
> Changed subject line since we've been discussing merge.
>=20
> 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.
>=20
> On Wed, Jan 16, 2013 at 4:29 AM, Wido den Hollander <wido@widodh.nl>
> wrote:
>=20
> > 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.Huang@citrix.com> wrote:
> >>
> >>
> >>>
> >>>  -----Original Message-----
> >>>> From: Marcus Sorensen [mailto:shadowsor@gmail.com]
> >>>> Sent: Tuesday, January 08, 2013 10:56 AM
> >>>> To:
> >>>> cloudstack-dev@incubator.**apache.org<cloudstack-
> dev@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.
> >>>>
> >>>
> >>>
> >>