Open Stack

On Thu, Nov 01, 2012 at 12:03:10AM +0800, Rongze Zhu wrote:
> 1. You are right, it just requires basic Posix filesystems APIs + Linux
> xattrs.
> But you know that naming is very hard, so I temporarily name it to 'ext4'.
> In
> the future, I will give it a new name.

I'd say just stick to localfs or similar as that is most descriptive.

> 2. I am not familiar with md5 and sha1, but md5 is only used for checksum,
> why
> it is a bit dangerous? I'm confused :)

MD5 is an old hashing algorithm for which it's fairly easy to find hash
collisions.  I actually misread the code and thought you'd use the hash
for content addressing, in which case this would be a real issue.  If
it's just a checksum against corruption it's not bad, but I'd still
recommend using a better hash algorithm these days.

> 3. If qcow3 format is comming, I also need to implement qcow3 python
> library.

"Qcow3" is a set of extensions to the qcow2 format.  The format is still
handled by the same driver, just the version field in the header is
bumped to 3.  If I'm reading the python code in your branch correctly
there currently is no support for that, but no check to reject it
either.

> I only read snapshot data and metadata from image, qemu concurrent I/O will
> not
> modify snapshot data and metadata, so it is consistency.

I'd like a bit more documentation an asserts that this is really the
case.


In addition I have another question, although that might be more towards
the nova gurus on the list:  What guarantees no I/O is pending when
the create_snapshot method is called?  Just like in a driver I'm writing
right now you call qem-u-img snapshot from the create_snapshot method,
and I'm again worried about qemu accessing it concurrently.  The same
issue also applied to the delete_snapshot method.  I've been trying to
dig into this, but the API documentation for cinder seems severly
lackingunfortunately.

> 4. I agree with you, it is best that we can export snapshot data and
> metadata from image by monitor command.

I'd suggest going there, as it means all format specific are hidden
in qemu, this would also allow to support e.g. vhd or vmware images
without changes to your openstack code.

You already need a qemu patch anyway so I don't think it's a huge issue.

Thinking about qemu I think your initial provisioning in the
initialize_connection could also be greatly simplified by using the
copy on read support in recent qemu.  This uses the qemu backing device
support, but updates the overlay image not only on writes but pages in
data on reads as well and thus gradually moves the data to be local.