On Wed, 2014-04-23 at 13:56 +0800, lihuiba wrote: > >For live migration, we use shared storage so I don't think it's quite > >the same as getting/putting image bits from/to arbitrary locations. > With a good zero-copy transfer lib, live migration support can be > extended to non-shared storage, or cross-datacenter. It's a kind of > value.
Hmm, I totally see the value of doing this. Not sure that there could be the same kinds of "liveness" guarantees with non-shared-storage, but I am certainly happy to see a proof of concept in this area! :) > >task = image_api.copy(from_path_or_uri, to_path_or_uri) > ># do some other work > >copy_task_result = task.wait() > +1 looks cool! > how about zero-copying? It would be an implementation detail within nova.image.api.copy() function (and the aforementioned "image bits mover library") :) The key here is to leak as little implementation detail out of the nova.image.api module Best, -jay > At 2014-04-23 07:21:27,"Jay Pipes" <jaypi...@gmail.com> wrote: > >Hi Vincent, Zhi, Huiba, sorry for delayed response. See comments inline. > > > >On Tue, 2014-04-22 at 10:59 +0800, Sheng Bo Hou wrote: > >> I actually support the idea Huiba has proposed, and I am thinking of > >> how to optimize the large data transfer(for example, 100G in a short > >> time) as well. > >> I registered two blueprints in nova-specs, one is for an image upload > >> plug-in to upload the image to > >> glance(https://review.openstack.org/#/c/84671/), the other is a data > >> transfer plug-in(https://review.openstack.org/#/c/87207/) for data > >> migration among nova nodes. I would like to see other transfer > >> protocols, like FTP, bitTorrent, p2p, etc, implemented for data > >> transfer in OpenStack besides HTTP. > >> > >> Data transfer may have many use cases. I summarize them into two > >> catalogs. Please feel free to comment on it. > >> 1. The machines are located in one network, e.g. one domain, one > >> cluster, etc. The characteristic is the machines can access each other > >> directly via the IP addresses(VPN is beyond consideration). In this > >> case, data can be transferred via iSCSI, NFS, and definitive zero-copy > >> as Zhiyan mentioned. > >> 2. The machines are located in different networks, e.g. two data > >> centers, two firewalls, etc. The characteristic is the machines can > >> not access each other directly via the IP addresses(VPN is beyond > >> consideration). The machines are isolated, so they can not be > >> connected with iSCSI, NFS, etc. In this case, data have to go via the > >> protocols, like HTTP, FTP, p2p, etc. I am not sure whether zero-copy > >> can work for this case. Zhiyan, please help me with this doubt. > >> > >> I guess for data transfer, including image downloading, image > >> uploading, live migration, etc, OpenStack needs to taken into account > >> the above two catalogs for data transfer. > > > >For live migration, we use shared storage so I don't think it's quite > >the same as getting/putting image bits from/to arbitrary locations. > > > >> It is hard to say that one protocol is better than another, and one > >> approach prevails another(BitTorrent is very cool, but if there is > >> only one source and only one target, it would not be that faster than > >> a direct FTP). The key is the use > >> case(FYI:http://amigotechnotes.wordpress.com/2013/12/23/file-transmission-with-different-sharing-solution-on-nas/). > > > >Right, a good solution would allow for some flexibility via multiple > >transfer drivers. > > > >> Jay Pipes has suggested we figure out a blueprint for a separate > >> library dedicated to the data(byte) transfer, which may be put in oslo > >> and used by any projects in need (Hoping Jay can come in:-)). Huiba, > >> Zhiyan, everyone else, do you think we come up with a blueprint about > >> the data transfer in oslo can work? > > > >Yes, so I believe the most appropriate solution is to create a library > >-- in oslo or a standalone library like taskflow -- that would offer a > >simple byte streaming library that could be used by nova.image to expose > >a neat and clean task-based API. > > > >Right now, there is a bunch of random image transfer code spread > >throughout nova.image and in each of the virt drivers there seems to be > >different re-implementations of similar functionality. I propose we > >clean all that up and have nova.image expose an API so that a virt > >driver could do something like this: > > > >from nova.image import api as image_api > > > >... > > > >task = image_api.copy(from_path_or_uri, to_path_or_uri) > ># do some other work > >copy_task_result = task.wait() > > > >Within nova.image.api.copy(), we would use the aforementioned transfer > >library to move the image bits from the source to the destination using > >the most appropriate method. > > > >Best, > >-jay > > > > > >_______________________________________________ > >OpenStack-dev mailing list > >OpenStack-dev@lists.openstack.org > >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev