<font size=2 face="sans-serif">Right, our discussion ends up with two
directions to access the image: full-copying(upload and download the whole
image) and zero-copying(remotely access the image and copy on demand).</font>
<ul>
<li><font size=2 face="sans-serif">For image transfer via "full-copying",
nova.image module works, because we only care about how the data(bytes/image)
is going to send. It does not matter what the hypervisor is and what the
storage it is. I think we can take the library approach with </font><tt><font size=2>task
= image_api.copy(from_path_or_uri, to_path_or_uri)</font></tt><font size=2 face="sans-serif">
as Jay proposed.</font>
<li><font size=2 face="sans-serif">For image transfer via "zero-copying"
as Zhi Yan mentioned, depends on the hypervisor and the backend storage.
nova.virt is able to access hypervisor and storage  context, but not
nova.image. The image does not have to be in the same location, where to
launch the VM. We care about how the data(image) is accessed(how the VM
is launched.)</font></ul><font size=2 face="sans-serif">Each of them needs
one module to put, and it is hard to merge them.</font>
<br>
<br><font size=2 face="sans-serif">Best wishes,<br>
Vincent Hou (侯胜博)<br>
<br>
Staff Software Engineer, Open Standards and Open Source Team, Emerging
Technology Institute, IBM China Software Development Lab<br>
<br>
Tel: 86-10-82450778 Fax: 86-10-82453660<br>
Notes ID: Sheng Bo Hou/China/IBM@IBMCN    E-mail: sbhou@cn.ibm.com
<br>
Address:3F Ring, Building 28 Zhongguancun Software Park, 8 Dongbeiwang
West Road, Haidian District, Beijing, P.R.C.100193<br>
地址:北京市海淀区东北旺西路8号中关村软件园28号楼环宇大厦3层
邮编：100193</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Zhi Yan Liu <lzy.dev@gmail.com></b>
</font>
<p><font size=1 face="sans-serif">2014/04/24 14:30</font>
<table border>
<tr valign=top>
<td bgcolor=white>
<div align=center><font size=1 face="sans-serif">Please respond to<br>
"OpenStack Development Mailing List \(not for usage questions\)"
<openstack-dev@lists.openstack.org></font></div></table>
<br>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">"OpenStack Development Mailing
List (not for usage questions)" <openstack-dev@lists.openstack.org>,
</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">Re: [openstack-dev] [Nova][blueprint]
Accelerate the booting process of a number of vms via VMThunder</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><tt><font size=2>First, after the discussing between I and Vincent,
I'm sure what we<br>
talked for "zero-copying" in above mail threads is different
with<br>
"full-copying"/transferring. The transferring/full-copying means
image<br>
bits duplication, it focuses on using some method to accelerate image<br>
bits replication and transferring between Glance/backend-storage and<br>
Nova compute host, like P2P, FTP, HTTP, etc., but zero-copying means<br>
there is NO any bits duplication and transferring happened between<br>
those two sides during the image preparing for VM provisioning, so the<br>
latter one focuses on a) how to attaching remote image volume/disk<br>
within Glance managed backend-storage from Nova compute host directly,<br>
and b) making the VM's root disk from remote template image  based
on<br>
such hypervisor and particular storage technology, btw c) preventing<br>
image bits uploading for VM snapshot/capture case. They are totally<br>
different to me. (refer: review comments in<br>
</font></tt><a href=https://review.openstack.org/#/c/84671/><tt><font size=2>https://review.openstack.org/#/c/84671/</font></tt></a><tt><font size=2>
)<br>
<br>
Second, on the implementation level, I consider to put all image<br>
handling related code into nova.image namespace sounds neat but I<br>
think it can not work (the "leak" as last mail side here). IMO,
the<br>
transferring/full-copying logic is more applicable for nova.image<br>
namespace, such transferring approach can be implemented based on<br>
existing download module plugins structure, e.g. P2P, FTP, but for the<br>
zero-copying, regarding to my above points of view, I consider to<br>
implement it in nova.virt + nova.virt.<hypervisor> is make more sense,<br>
since it's more related with particular hypervisor and/or storage<br>
technology. (refer: inline comments in<br>
</font></tt><a href="https://review.openstack.org/#/c/86583/6/specs/juno/image-multiple-location.rst"><tt><font size=2>https://review.openstack.org/#/c/86583/6/specs/juno/image-multiple-location.rst</font></tt></a><tt><font size=2><br>
)<br>
<br>
zhiyan<br>
<br>
On Wed, Apr 23, 2014 at 11:02 PM, Jay Pipes <jaypipes@gmail.com>
wrote:<br>
> On Wed, 2014-04-23 at 13:56 +0800, lihuiba wrote:<br>
>> >For live migration, we use shared storage so I don't think
it's quite<br>
>> >the same as getting/putting image bits from/to arbitrary locations.<br>
>> With a good zero-copy transfer lib, live migration support can
be<br>
>> extended to non-shared storage, or cross-datacenter. It's a kind
of<br>
>> value.<br>
><br>
> Hmm, I totally see the value of doing this. Not sure that there could
be<br>
> the same kinds of "liveness" guarantees with non-shared-storage,
but I<br>
> am certainly happy to see a proof of concept in this area! :)<br>
><br>
>> >task = image_api.copy(from_path_or_uri, to_path_or_uri)<br>
>> ># do some other work<br>
>> >copy_task_result = task.wait()<br>
>> +1  looks cool!<br>
>> how about zero-copying?<br>
><br>
> It would be an implementation detail within nova.image.api.copy()<br>
> function (and the aforementioned "image bits mover library")
:)<br>
><br>
> The key here is to leak as little implementation detail out of the<br>
> nova.image.api module<br>
><br>
> Best,<br>
> -jay<br>
><br>
>> At 2014-04-23 07:21:27,"Jay Pipes" <jaypipes@gmail.com>
wrote:<br>
>> >Hi Vincent, Zhi, Huiba, sorry for delayed response. See comments
inline.<br>
>> ><br>
>> >On Tue, 2014-04-22 at 10:59 +0800, Sheng Bo Hou wrote:<br>
>> >> I actually support the idea Huiba has proposed, and I
am thinking of<br>
>> >> how to optimize the large data transfer(for example,
100G in a short<br>
>> >> time) as well.<br>
>> >> I registered two blueprints in nova-specs, one is for
an image upload<br>
>> >> plug-in to upload the image to<br>
>> >> glance(</font></tt><a href=https://review.openstack.org/#/c/84671/><tt><font size=2>https://review.openstack.org/#/c/84671/</font></tt></a><tt><font size=2>),
the other is a data<br>
>> >> transfer plug-in(</font></tt><a href=https://review.openstack.org/#/c/87207/><tt><font size=2>https://review.openstack.org/#/c/87207/</font></tt></a><tt><font size=2>)
for data<br>
>> >> migration among nova nodes. I would like to see other
transfer<br>
>> >> protocols, like FTP, bitTorrent, p2p, etc, implemented
for data<br>
>> >> transfer in OpenStack besides HTTP.<br>
>> >><br>
>> >> Data transfer may have many use cases. I summarize them
into two<br>
>> >> catalogs. Please feel free to comment on it.<br>
>> >> 1. The machines are located in one network, e.g. one
domain, one<br>
>> >> cluster, etc. The characteristic is the machines can
access each other<br>
>> >> directly via the IP addresses(VPN is beyond consideration).
In this<br>
>> >> case, data can be transferred via iSCSI, NFS, and definitive
zero-copy<br>
>> >> as Zhiyan mentioned.<br>
>> >> 2. The machines are located in different networks, e.g.
two data<br>
>> >> centers, two firewalls, etc. The characteristic is the
machines can<br>
>> >> not access each other directly via the IP addresses(VPN
is beyond<br>
>> >> consideration). The machines are isolated, so they can
not be<br>
>> >> connected with iSCSI, NFS, etc. In this case, data have
to go via the<br>
>> >> protocols, like HTTP, FTP, p2p, etc. I am not sure whether
zero-copy<br>
>> >> can work for this case. Zhiyan, please help me with this
doubt.<br>
>> >><br>
>> >> I guess for data transfer, including image downloading,
image<br>
>> >> uploading, live migration, etc, OpenStack needs to taken
into account<br>
>> >> the above two catalogs for data transfer.<br>
>> ><br>
>> >For live migration, we use shared storage so I don't think
it's quite<br>
>> >the same as getting/putting image bits from/to arbitrary locations.<br>
>> ><br>
>> >>  It is hard to say that one protocol is better than
another, and one<br>
>> >> approach prevails another(BitTorrent is very cool, but
if there is<br>
>> >> only one source and only one target, it would not be
that faster than<br>
>> >> a direct FTP). The key is the use<br>
>> >> case(FYI:</font></tt><a href="http://amigotechnotes.wordpress.com/2013/12/23/file-transmission-with-different-sharing-solution-on-nas/"><tt><font size=2>http://amigotechnotes.wordpress.com/2013/12/23/file-transmission-with-different-sharing-solution-on-nas/</font></tt></a><tt><font size=2>).<br>
>> ><br>
>> >Right, a good solution would allow for some flexibility via
multiple<br>
>> >transfer drivers.<br>
>> ><br>
>> >> Jay Pipes has suggested we figure out a blueprint for
a separate<br>
>> >> library dedicated to the data(byte) transfer, which may
be put in oslo<br>
>> >> and used by any projects in need (Hoping Jay can come
in:-)). Huiba,<br>
>> >> Zhiyan, everyone else, do you think we come up with a
blueprint about<br>
>> >> the data transfer in oslo can work?<br>
>> ><br>
>> >Yes, so I believe the most appropriate solution is to create
a library<br>
>> >-- in oslo or a standalone library like taskflow -- that would
offer a<br>
>> >simple byte streaming library that could be used by nova.image
to expose<br>
>> >a neat and clean task-based API.<br>
>> ><br>
>> >Right now, there is a bunch of random image transfer code
spread<br>
>> >throughout nova.image and in each of the virt drivers there
seems to be<br>
>> >different re-implementations of similar functionality. I propose
we<br>
>> >clean all that up and have nova.image expose an API so that
a virt<br>
>> >driver could do something like this:<br>
>> ><br>
>> >from nova.image import api as image_api<br>
>> ><br>
>> >...<br>
>> ><br>
>> >task = image_api.copy(from_path_or_uri, to_path_or_uri)<br>
>> ># do some other work<br>
>> >copy_task_result = task.wait()<br>
>> ><br>
>> >Within nova.image.api.copy(), we would use the aforementioned
transfer<br>
>> >library to move the image bits from the source to the destination
using<br>
>> >the most appropriate method.<br>
>> ><br>
>> >Best,<br>
>> >-jay<br>
>> ><br>
>> ><br>
>> >_______________________________________________<br>
>> >OpenStack-dev mailing list<br>
>> >OpenStack-dev@lists.openstack.org<br>
>> ></font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> OpenStack-dev@lists.openstack.org<br>
>> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> OpenStack-dev@lists.openstack.org<br>
> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
OpenStack-dev@lists.openstack.org<br>
</font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
<br>
</font></tt>
<br>