<font size=2 face="sans-serif">Jay, Huiba, Chris, Solly, Zhiyan, and everybody
else,</font>
<br>
<br><font size=2 face="sans-serif">I am so excited that two of the proposals:
Image Upload Plugin(</font><a href=http://summit.openstack.org/cfp/details/353><font size=2 color=blue face="sans-serif">http://summit.openstack.org/cfp/details/353</font></a><font size=2 face="sans-serif">)
and Data transfer service Plugin(</font><a href=http://summit.openstack.org/cfp/details/352><font size=2 color=blue face="sans-serif">http://summit.openstack.org/cfp/details/352</font></a><font size=2 face="sans-serif">)
have been merged together and scheduled in the coming design summit. If
you show up in Atlanta, please come this session(</font><a href=http://junodesignsummit.sched.org/event/c00119362c07e4cb203d1c4053add187><font size=2 color=blue face="sans-serif">http://junodesignsummit.sched.org/event/c00119362c07e4cb203d1c4053add187</font></a><font size=2 face="sans-serif">)
and start our discussion,<b> on Wednesday, May 14 • 11:50am - 12:30pm</b>.</font>
<br>
<br><font size=2 face="sans-serif">I will propose a common image transfer
library for all the OpenStack projects to to upload and download the images.
If it is approved, with this library, Huiba, you can feel free to implement
the transfer protocols you like.</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>Sheng Bo Hou/China/IBM@IBMCN</b>
</font>
<p><font size=1 face="sans-serif">2014/04/27 22:33</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><font size=2 face="sans-serif">I have done a little test for the image
download and upload. I created an API for the image access, containing
copyFrom and sendTo. I moved the image download and upload code from XenApi
into the implementation for Http with some modifications, and the code
worked for libvirt as well. <br>
copyFrom means to download the image and return the image data, and different
hypervisors can choose to save it in a file or import it to the datastore;
sendTo is used to upload the image and the image data is passed in as a
parameter.</font><font size=3 face="sans-serif"> <br>
</font><font size=2 face="sans-serif"><br>
I also did an investigation about how each hypervisor is doing the image
upload and download.</font><font size=3 face="sans-serif"> <br>
</font><font size=2 face="sans-serif"><br>
For the download:</font><font size=3 face="sans-serif"> </font><font size=2 face="sans-serif"><br>
libvirt, hyper-v and baremetal use the code image_service.download to download
the image and save it into a file.</font><font size=3 face="sans-serif">
</font><font size=2 face="sans-serif"><br>
vmwareapi uses the code image_service.download to download the image and
import it into the datastore.</font><font size=3 face="sans-serif"> </font><font size=2 face="sans-serif"><br>
XenAPi uses image_service.download to download the image for VHD image.</font><font size=3 face="sans-serif">
<br>
</font><font size=2 face="sans-serif"><br>
For the upload:</font><font size=3 face="sans-serif"> </font><font size=2 face="sans-serif"><br>
They use image_service.upload to upload the image.</font><font size=3 face="sans-serif">
<br>
</font><font size=2 face="sans-serif"><br>
I think we can conclude that it is possible to have a common image transfer
library with different implementations for different protocols.</font><font size=3 face="sans-serif">
</font><font size=2 face="sans-serif"><br>
This is a small demo code for the library: </font><a href=https://review.openstack.org/#/c/90601/><font size=2 color=blue face="sans-serif"><u>https://review.openstack.org/#/c/90601/</u></font></a><font size=2 face="sans-serif">(Jay,
is it close to the library as you mentioned?). I just replaced the upload
and download part with the http implementation for the imageapi and it
worked fine.</font><font size=3 face="sans-serif"> <br>
</font><font size=2 face="sans-serif"><br>
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><font size=3 face="sans-serif"> <br>
<br>
</font>
<table width=100%>
<tr valign=top>
<td width=62%><font size=1 face="sans-serif"><b>Solly Ross <sross@redhat.com></b>
</font>
<p><font size=1 face="sans-serif">2014/04/25 01:46</font><font size=3 face="sans-serif">
</font>
<br>
<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>
<p>
<td width=37%>
<table width=100%>
<tr valign=top>
<td width=6%>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td width=93%><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>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br><font size=3 face="sans-serif"><br>
<br>
</font><tt><font size=2><br>
Something to be aware of when planing an image transfer library is that
individual drivers<br>
might have optimized support for image transfer in certain cases (especially
when dealing<br>
with transferring between different formats, like raw to qcow2, etc).  This
builds on what<br>
Christopher was saying -- there's actually a reason why we have code for
each driver.  While<br>
having a common image copying library would be nice, I think a better way
to do it would be to<br>
have some sort of library composed of building blocks, such that each driver
could make use of<br>
common functionality while still tailoring the operation to the quirks
of the particular drivers.<br>
<br>
Best Regards,<br>
Solly Ross<br>
<br>
----- Original Message -----<br>
From: "Christopher Lefelhocz" <christopher.lefelhoc@RACKSPACE.COM><br>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org><br>
Sent: Thursday, April 24, 2014 11:17:41 AM<br>
Subject: Re: [openstack-dev] [Nova][blueprint] Accelerate the booting process
of a number of vms via VMThunder<br>
<br>
Apologies for coming to this discussion late...<br>
<br>
On 4/22/14 6:21 PM, "Jay Pipes" <jaypipes@gmail.com> wrote:<br>
<br>
><br>
>Right, a good solution would allow for some flexibility via multiple<br>
>transfer drivers.<br>
<br>
+1. In particular I don't think this discussion should degenerate into<br>
zero-copy vs. pre caching.  I see both as possible solutions depending
on<br>
deployer/environment needs.<br>
<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>
If I understand correctly, we'll create some common library around this.<br>
It would be good to understand the details a bit better.  I've thought
a<br>
bit about this issue.  The one area that I get stuck at is providing
a<br>
common set of downloads which work across drivers effectively.  Part
of<br>
the reason there are a bunch or random image transfers is historical, but<br>
also because performance was already a problem.  Examples include:<br>
transferring to compute first then copying to dom0 causing performance<br>
issues, needs in some drivers to download image completely to validate<br>
prior to putting in place, etc.<br>
<br>
It may be easy to say we'll push most of this to the dom0, but I know for<br>
Xen our python stack is somewhat limited so that may be an issue.<br>
<br>
By the way we've been working on proposing a simpler image pre caching<br>
system/strategy.  It focuses specifically on the image caching portion
of<br>
this discussion.  For those interested, see the nova-spec</font></tt><font size=3 color=blue face="sans-serif"><u><br>
</u></font><a href=https://review.openstack.org/#/c/85792><tt><font size=2 color=blue><u>https://review.openstack.org/#/c/85792</u></font></tt></a><tt><font size=2>.
 We'd like to leverage whatever<br>
optimized image download strategy is available.<br>
<br>
Christopher <br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
OpenStack-dev@lists.openstack.org</font></tt><font size=3 color=blue face="sans-serif"><u><br>
</u></font><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2 color=blue><u>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</u></font></tt></a><tt><font size=2><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
OpenStack-dev@lists.openstack.org</font></tt><font size=3 color=blue face="sans-serif"><u><br>
</u></font><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2 color=blue><u>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</u></font></tt></a><tt><font size=2><br>
</font></tt><font size=3 face="sans-serif"><br>
</font><tt><font size=2>_______________________________________________<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>
</font></tt>
<br>