incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus Sorensen <shadow...@gmail.com>
Subject Re: [MERGE] resizeVolume
Date Wed, 16 Jan 2013 23:57:20 GMT
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 <wido@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.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.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.
>>>>
>>>
>>>
>>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message