Wednesday, 2016-06-08

*** openstackgerrit has quit IRC02:47
*** openstackgerrit has joined #openstack-storlets02:48
kota_hello03:02
kota_sorry, probably I won't be at today's IRC meeting. I'll read the log tommorow-ish.03:03
openstackgerritTakashi Kajinami proposed openstack/storlets: DO NOT MERGE: PoC code for zero copy  https://review.openstack.org/32594903:13
*** eranrom has joined #openstack-storlets06:02
*** eranrom has quit IRC06:12
*** eranrom has joined #openstack-storlets06:30
*** openstackgerrit has quit IRC06:48
*** openstackgerrit has joined #openstack-storlets06:48
*** eranrom_ has joined #openstack-storlets07:04
*** eranrom has quit IRC07:04
*** eranrom has joined #openstack-storlets07:06
*** eranrom_ has quit IRC07:06
eranromkota_: no problem07:20
*** openstackgerrit has quit IRC07:48
*** openstackgerrit has joined #openstack-storlets07:49
*** takashi has joined #openstack-storlets08:14
takashieranrom: sorry for my long absence from irc. I replied to your comment in patch 314140, so please check it when you have time..08:15
patchbottakashi: https://review.openstack.org/#/c/314140/ - storlets - Refactor Storlet protocol classes08:15
*** openstackgerrit has quit IRC08:48
*** openstackgerrit has joined #openstack-storlets08:48
*** takashi has quit IRC09:40
*** takashi has joined #openstack-storlets11:08
*** eranrom has quit IRC11:13
*** takashi has quit IRC11:23
*** eranrom has joined #openstack-storlets11:42
*** eranrom has quit IRC12:18
*** takashi has joined #openstack-storlets12:51
*** eranrom has joined #openstack-storlets12:57
eranromHi12:57
takashieranrom: Hi12:57
eranromI believe its only the two of us today12:57
eranromso lets get started12:57
takashieranrom: +112:58
eranromI did not update the agenda but we can discuss the protocol merge patch and the spark "echosystem"12:58
takashieranrom: ok13:00
eranromDid you see my response?13:00
takashieranrom: Yes, and had a little thought after that13:00
takashieranrom: So can we start with the discussion about protocol merge?13:01
eranromtakashi: sure, lets start with that.13:01
takashieranrom: I checked you reply on patch 314140, and had some thoughts about that13:02
patchbottakashi: https://review.openstack.org/#/c/314140/ - storlets - Refactor Storlet protocol classes13:02
takashiI still have some concerns about using fd in diskfile13:03
takashiMy biggest concern is that we are now using internal thing in swift to pass fd directly to storlets13:04
takashiself.stream = orig_resp.app_iter._fp.fileno()13:04
takashiAs you can see, _fp should not be accessed outside diskfile, based on the design of diskfile13:05
eranromtakashi: I agree this is a concern. I still think that we can do here a best effort thing. That is if the fd is there lets use it, if not then fall back to a copy13:06
eranromtakashi: AFAIK, currently hdd is the main media in Swift deployments.13:07
eranromand I would like to make use of it as much as possible.13:07
takashieranrom: ok13:08
eranromYou may argue that it might be dangerous to commit on a random access functionality that might disappear one day13:08
eranrombut we can (1) document this (2) when this is no longer possible we deprecate13:09
eranromOther then the commitment for a random access this is all internal.13:09
takashieranrom: I think I need some more thought about interface, when we accept both of iter and fd13:11
eranromtakashi: sure.13:11
takashiand some logic to automatically use available fd instead of iter13:11
takashiI tried to make all protocols to use fd first, but there are some problems because in proxy-server we may get raw data, which should be parsed in http manner13:12
eranromabsolutely. My first step there is to have a way to pass metadata on the fd/stream so that the Docker side would know how to act.13:12
eranromIn fact this is part of 31964013:13
eranromand I plan to break it into a different patch13:14
eranromThis is the patch13:14
eranromhttps://review.openstack.org/#/c/319640/13:14
patchboteranrom: patch 319640 - storlets - WIP: Allow to run a single range request on the ob...13:14
takashieranrom: I had a quick locck and added some comments, but still need deep look about it13:14
eranromand I still need to look at the comments :-) I am currently focused on the documentation improvemnts...13:15
eranromBTW - did you see my comment on https://review.openstack.org/#/c/325949/13:15
patchboteranrom: patch 325949 - storlets - DO NOT MERGE: PoC code for zero copy13:15
takashieranrom: yes13:15
eranrommetadata over the stream could be beneficial there as well13:16
takashieranrom: eranrom: and I noticed that we should deal with parsing of raw http message, as you pointed out. I think I need some more thinking about that patch13:17
takashieranrom: Can I ask you one thing about random read?13:18
eranromtakashi: go ahead13:18
takashieranrom: My question, which is my second concern about passing fd for random read, is we only can make it on object-server, right?13:18
takashiIn object server, we can get the FileObject of object file as app_iter._fp to realize random access using it13:20
eranromtakashi: right. But note that in many other cases as well we cannot run in the object server anyway. encryption/EC13:20
takashieranrom: yes, We only can't get more that fd for socket, which supports sequential access13:21
takashis/that/than13:21
eranromtakashi: In what sense the app_iter._fp gives random access?13:21
eranromI mean doesn't using app_iter._fp mean pass the asspciated fd to the storlet side?13:23
eranroms/asspciated/associated13:23
takashiIn object-server we get the instance of swift.obj.diskfile.BaseDiskFileReader as app_iter13:24
takashiit has FileObject for the object file, and we can get the fd for file, right?13:25
takashiSo that fd is connected to file, and we can realize random access over object using it13:25
eranromright, but I thought that this is exactly what you were concerned about :-) Note that my zero copy remark was only for the object-server case. I am sorry if this was not clear.13:26
eranromI still think it would be cool to have zero copy on the proxy, bur this is more difficult...13:26
takashieranrom: I think having zero copy is good, but we have limitations for that, right? We should run storlets on object server13:27
takashieranrom: and now I'm thinking the way to prohibit executing storlets, which requires random access, on proxy-server, where we can not reazlie random accesss13:28
eranromright. In fact we cannot ever run random access storlets in the cases of enc./EC and as you mentioned in the future also not over other types of media13:29
eranrommight be that this calls for a storlet metadata that testifies the storlet assumes random access13:29
eranromand so we can error out if we are forced to run on the proxy or if the fd is not there on the object...13:30
takashieranrom: yes13:30
eranromtakashi: So here is my thinking:13:32
eranrom1. add stream/fd metadata field to the protocol between the middleware and SCommon13:32
eranrom2. add the range reads for object server execution13:33
eranrom3. can be done earlier: merge the existing protocol classes into two (1) those that require copy of the input (2) those that are zero copy13:33
eranromwhat do you think?13:34
takashieranrom: make sense13:34
eranromOnce I am done with the documentation I will go for #113:34
eranromIt will take me few more days I believe13:35
takashieranrom: I'll think about 3 first. I'll find the way to realize general interface to accept both of iter and fd13:35
takashiif I can :-)13:35
eranromtakashi: That would be great.13:35
eranromtakashi: If you do that then I could do the range stuff on top of that. so we do 3 and then 213:35
eranromtakashi: If you do not find a way to have a general interface for both, we can always have two classes. It would still be better then the 4 we have now.13:37
takashieranrom: +113:37
takashieranrom: I think I should be consistent with your range change,13:38
takashiso I think you don't have to wait me finishing. I can rebase my idea on your change.13:39
eranromtakashi: no worries. Let me do 1 first and see where we stand13:39
eranromwe can decide later13:39
takashieranrom: ok13:39
eranromtakashi: do you want to talk about Spark or anything else?13:40
eranromor leave it for next time?13:40
takashiCan you let me know a quick update? I think we had better discuss about detail when kota_ is also available13:41
eranromok. no problem.13:41
eranroma quick update13:42
eranromCurrently there is a PoC in IBM which is pretty far from something that can be upstreamed13:42
eranromThe PoC makes some changes to the following components:13:42
eranrom(1) Stocator - The Spark Swift connector written by Gil Vernik. I think that the changes made there should be somewhere else in the stack13:43
eranrom(2) spark csv - This is the Spark library that helps dealing with csv format. There is an inherent problem in doing the change there, which I can explain next time we talk13:44
eranromI think that we may need to supply an alternative library altogether. But I still need to have a deeper look.13:45
takashithis one? https://github.com/SparkTC/stocator13:45
takashiabout Stocator13:45
eranromI think this is a clone. Let me look sec.13:45
takashinp. I'll search it later13:46
eranromI guess this is it yes13:46
takashieranrom: thx!13:46
eranrom(3) spark rdd - This is a very generic layer in Spark, and I think that the push down could be done without touchinng it13:47
eranrom(4) hadoop rdd, this is a pluggable rdd library which we may need to supply our own implementation and not changing this one13:48
eranromAt a high level this where we touched the stack to make it work, but I plan to redo the whole thing13:49
eranromI have some spark learning to do before that13:49
eranromIf NTT is interested we can do this together...13:49
takashieranrom: I'll discuss with kota_ about that later13:51
eranromtakashi: sure13:52
eranromanything else for today?13:52
takashibut honestly speaking we are now putting our focus on existing applications, which doesn't use spark now.13:52
takashiso I'm not sure we can work about spark just now.13:52
takashiFrom me, one small update13:53
eranromtakashi: don't worry. I am planning to do this anyway :-)13:53
eranromtakashi: go ahead13:53
takashieranrom: I'm looking foward that work!13:54
takashiI started litter about directory refactoring, like patch 32094513:54
patchbottakashi: https://review.openstack.org/#/c/320945/ - storlets - Create common under storlet_gateway13:54
takashis/litter/little/13:54
takashiI started with the common functions, which doesn't have so big impact about on-going changes13:55
eranromtakashi: sorry must have missed it wil revuew13:55
eranromreview13:55
takashieranrom: np13:55
eranromsure looking good. I will review now13:55
eranromthans13:55
eranromthanks13:55
takashiI'm going to work about handler in middleware and gateway modules, if I can find any good timings, not to prevent on-going works13:56
takashithat's all from my side13:56
eranromtakashi: alright.13:56
eranromThanks for joining13:56
eranromtalk to you later13:56
takashieranrom: Thank you13:56
openstackgerritEran Rom proposed openstack/storlets: Create common under storlet_gateway  https://review.openstack.org/32094513:59
*** eranrom has quit IRC14:09
*** eranrom has joined #openstack-storlets14:34
*** eranrom has quit IRC14:49
*** eranrom has joined #openstack-storlets15:01
*** takashi has quit IRC16:26
openstackgerritTakashi Kajinami proposed openstack/storlets: Create common under storlet_gateway  https://review.openstack.org/32094516:33
openstackgerritTakashi Kajinami proposed openstack/storlets: WIP: Revert zero-copy about GET execution on object-server  https://review.openstack.org/32724416:54
openstackgerritTakashi Kajinami proposed openstack/storlets: WIP: Revive zero-copy about GET execution on object-server  https://review.openstack.org/32724416:56
*** eranrom has quit IRC17:29
*** eranrom has joined #openstack-storlets17:38
*** eranrom has quit IRC18:07
*** eranrom has joined #openstack-storlets18:10
*** eranrom has quit IRC20:29
*** openstackgerrit has quit IRC20:48
*** openstackgerrit has joined #openstack-storlets20:49
openstackgerritMerged openstack/storlets: Create common under storlet_gateway  https://review.openstack.org/32094520:49

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!