08:00:23 <eranrom> #startmeeting storlets 08:00:24 <openstack> Meeting started Tue Jan 17 08:00:23 2017 UTC and is due to finish in 60 minutes. The chair is eranrom. Information about MeetBot at http://wiki.debian.org/MeetBot. 08:00:25 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 08:00:28 <openstack> The meeting name has been set to 'storlets' 08:00:36 <eranrom> Hi 08:00:54 <takashi> o/ 08:01:02 <kota_> o/ 08:01:07 <eranrom> kota_: takashi Hi 08:01:40 <eranrom> I have not got much on the agenda. Here it is https://wiki.openstack.org/wiki/Meetings/Storlets#Agenda 08:02:06 <eranrom> akihito: Hi just sent a link to the agenda https://wiki.openstack.org/wiki/Meetings/Storlets#Agenda: 08:02:35 <kota_> hi akihito, eranrom, takashi 08:02:40 <akihito> Hi! Thank you. I look it. 08:02:51 <eranrom> Hi kota_ 08:02:54 <takashi> #link https://wiki.openstack.org/wiki/Meetings/Storlets#Agenda 08:02:58 <eranrom> ok, so lets start. 08:03:04 <kota_> sure 08:03:10 <eranrom> #topic Multi-input desired behavior 08:04:03 <eranrom> The subject came up while corresponding with akihito on the multi-input functional test 08:04:25 <akihito> The subject came up while corresponding with akihito on the multi-input functional test.. 08:04:26 <kota_> cool, that progressed 08:04:34 <akihito> oh miss. 08:05:27 <kota_> looking at the agenda, it works well but probably it's tbd 08:05:42 <kota_> what if we should do 08:06:10 <akihito> I think that the fix is 'https://github.com/openstack/storlets/blob/master/storlets/swift_middleware/handlers/base.py#L310-L321'. 08:06:25 <kota_> i think ignoring the extra header is safe for users but someone wants to make it as sort of 400 BadRequest, maybe? 08:07:12 <eranrom> I think there are 3 options here 08:07:15 <eranrom> 1. leave this as is 08:07:16 <akihito> I think so too. 08:07:42 <eranrom> 2. enforce running multi-input on the proxy (as suggested bu Akihito's link) 08:08:15 <eranrom> 3. return 400 bad request if there are extra resources by no run-on-proxy header 08:08:46 <kota_> either is fine to me. 08:08:48 <kota_> for now. 08:08:57 <takashi> IMO, solution 2 is the best for me because 08:09:49 <takashi> for 1, considering API design, I think we should not ignore any parameters given by client silently 08:10:10 <takashi> it can confuse people 08:11:06 <takashi> for 3, if we only support that feature for proxy execution, we don't need to ask people to always give run-on-proxy header, as we do for slo/range execution 08:11:33 <eranrom> takashi: +1 08:12:45 <eranrom> If we end up supporting this also from the object server, we can remove this enforcement 08:12:57 <takashi> kota_, akihito: does it make sense to you? 08:13:06 <takashi> eranrom: right! 08:13:11 <akihito> hmm. I think that there is no merit of running on the object-server side.. 08:13:48 <akihito> Therefore, I think 2 is good. 08:13:49 <kota_> sounds ok. If I want to do it in object-server. will propose something with new architecture so 08:13:57 <takashi> akihito: I don't think so, because we want to use small extra source, like a reference file, 08:14:02 <kota_> no opinion exist to block the option 2 08:14:21 <takashi> we can reduce the amount for network transition in object-server execution, in some cases 08:14:42 <takashi> s/we want to/when we want to/ 08:14:48 <takashi> kota_: thx 08:14:56 <eranrom> When I was in IBM we had a PoC with a media firm that wanted this. They had one huge object and many small metadata objects thay wnted all to be streamed onto the storlet 08:15:16 <eranrom> so they were happy with multi-input on object nodes... 08:15:28 <eranrom> anyway, seems like we agree on option 2 08:16:32 <kota_> ;-) 08:16:41 <eranrom> next. 08:16:47 <akihito> I see. 08:17:02 <eranrom> #topic reviews prioritization 08:17:10 <eranrom> any opinions? 08:17:17 <kota_> not 08:17:28 <kota_> eranrom: probably you are looking stale one 08:17:43 <kota_> i updated the agend before 5 minuts from metting 08:17:50 <eranrom> oh, sec 08:18:07 <eranrom> sorry 08:18:17 <kota_> np 08:18:21 <eranrom> #topic Name decision, SBusDaemon? SBusServer? or StorletServer? 08:18:31 <kota_> yes, that one 08:18:50 <kota_> so it's from takashi's patch to abstract the daemon class 08:18:53 <kota_> #link https://review.openstack.org/#/c/406 08:18:55 <kota_> no 08:19:00 <kota_> #unlink https://review.openstack.org/#/c/406 08:19:09 <eranrom> :-) 08:19:22 <kota_> #link https://review.openstack.org/#/c/406620 08:19:51 <kota_> to be honest, idk if we could use unlink for the command :P 08:20:15 <kota_> back to the topic 08:20:25 <takashi> kota_: :-) 08:21:00 <kota_> i think the patch is for addressing the abstraction of the daemon we has been calling as... 08:21:08 <kota_> takashi: SBusDaemon??? 08:21:17 <takashi> kota_: yes 08:21:24 <kota_> ah, just Daemon, IIRC 08:21:25 <takashi> let me explain some background information 08:21:44 <kota_> takashi: sure, please 08:22:06 <takashi> In that patch, as you may know, I tried to create base class for storlet daemon and daemon factory 08:23:26 <takashi> both processes are a kind of daemon which depends on sbus protocol and execute callback functions correspoding to the command requested by client 08:24:53 <takashi> so we can create a baseclass which implements a basic interface for them 08:26:04 <takashi> It works on sbus protocol, not limited for storlets, so that is why I include 'SBus' in that class name 08:26:47 <takashi> and 'Daemon' came from StorletDaemon as they are a kind of daemon processes, which keep running in container side. 08:28:54 <takashi> Currently, after reading some comments from kota_, I think 'Server' is better than Daemon, which shows that it execute a kind of callback based on the request 08:29:16 <kota_> takashi: thanks for explaining 08:29:27 <takashi> So I'm thinking to name the base class as SBusServer 08:29:31 <kota_> takashi: i also think it's better to call it Server 08:29:44 <takashi> Maybe main discussion point is 1. SBus or Storlet 2. Daemon or Server 08:29:50 <kota_> but ... perhaps, StorletServer could be better? 08:30:17 <kota_> that is because it sounds like SBusServer provide sbus, maybe? 08:30:54 <takashi> SBusServer works for request in sbus protocol, like HttpServer works for request in http protocol 08:31:29 <kota_> and IMO, i has been thinking of the abstruction, BaseStorletSrever could include all things we need to run as Server process, e.g. listening, dispathing 08:31:37 <takashi> and I'm thinking to have SBusClient which sends request in sbus protocol https://review.openstack.org/#/c/405937/, like we use HttpClient for http request 08:32:17 <kota_> and then, all the extension like FactoryManager and StorletManager could implment just commands which are supported in the server? 08:32:49 <kota_> takashi: ah, yeah, we call HTTPServer which provide http interface to connect. 08:33:08 <kota_> takashi: make sense. 08:33:43 <kota_> sorry, i said a few kind of things 08:34:00 <kota_> 1. the name, it could be SBusServer for base class? 08:34:10 <takashi> I'm currently thinking to name the base class as BaseSBusServer like BaseHttpServer 08:34:15 <kota_> 2. which feature should be in the SBusServer 08:34:44 <takashi> ^^^ for 1 08:34:48 <kota_> takashi: sounds good for 1 08:35:13 <takashi> and for 2, I think it is better to have all funcutions in base to start up server functions 08:35:18 <kota_> for 2, IMO, all things to provide SBusServer 08:35:26 <takashi> kota_: yes 08:35:49 <takashi> I mean, main_loop, dispatch_command, and all command handler functions, based on currently implementation 08:35:59 <kota_> i think, all things means it can run independently but no command cannot be runable with extension. 08:36:38 <takashi> kota_: or we can implement some basic handler like ping in base class, as we expect same implementations for all servers 08:37:09 <kota_> and if we could think of making it most likely HTTPServer, we should use populer name for each method, like "listen"? 08:37:26 <takashi> kota_: maybe I need to check interface design in HTTPServer 08:37:36 <kota_> takashi: me too 08:38:10 <kota_> eranrom, akihito: summirize current discussion 08:38:13 <kota_> , 08:38:44 <kota_> eranrom, akihito: the patch is going to move... 08:38:59 <kota_> 1. rename the base class as BaseSBusServer 08:39:36 <kota_> 2. more refactor to be likely common HTTPServer (but it listens by SBus protocol) 08:39:44 <kota_> takashi: correct? 08:39:55 <takashi> kota_: yes 08:40:12 <takashi> for 1, I think I can update my patch in not so long time. 08:40:44 <takashi> for 2, I still need some more time because I need to solve interface difference between StorletDaemon and DaemonFactory 08:41:07 <kota_> ok 08:41:14 <eranrom> kota_: takashi: This was a great discussion. I watched and learned. Thanks! 08:41:32 <kota_> they will be something like, StorletServer and StorletServerFactory 08:42:21 <kota_> eranrom: k, sorry we consume much time, please go ahead to the next 08:42:46 <eranrom> kota_: np. It was a very good usage of the time! 08:42:56 <eranrom> if there is more please continue! 08:43:35 <eranrom> you were suggesting names for the servers inheriting form BaseSBusServer 08:45:00 <takashi> In my current idea, I'm just thinking to use the name corresponding to the process name (I mean StorletDaemon and StorletDaemonFactory or DaemonFactory) for each implementation class 08:45:31 <takashi> If we change that name, we should change the name of the script file (files under bin), correspondingly 08:46:02 <kota_> takashi: good point 08:46:02 <takashi> I think we can discuss about that on gerrit. If we need some more discussions, I'll bring that topic in irc meeting again. 08:46:15 <kota_> kk 08:46:57 <eranrom> next? 08:47:02 <kota_> sure 08:47:08 <takashi> yes 08:47:18 <akihito> yes 08:47:23 <eranrom> #topic review prioritization 08:48:00 <eranrom> any opinions? 08:50:01 <takashi> Currently I'm working about agent refactoring, and akihito is working about functional test coverages 08:50:21 <akihito> yeh! My functiona tests without 'WIP' is reviewable. 08:50:39 <takashi> in that point, it would be great if I can ask your reviews about them 08:50:44 <eranrom> akihito: :-) great! will review some more 08:50:57 <akihito> Thankyou! 08:51:21 <kota_> akihito: which one is the first patch for your chain? 08:52:53 <takashi> AFAIK, they are basically independent 08:53:06 <akihito> https://review.openstack.org/#/c/400057/ 08:53:34 <takashi> talking about my patches, because I used some patches for testing config file addition for agent process https://review.openstack.org/#/c/419044/, most of them depends on another one. 08:53:45 <akihito> I divide this commit. 08:53:58 <kota_> takashi: yeah, i mean just which one is the most priority.... 08:54:08 <takashi> kota_: Oh. got it. 08:54:11 <kota_> akihito: it looks like in gate failure. 08:54:34 <kota_> takashi: actually, idk if they are independent or not. 08:54:37 <kota_> :P 08:54:59 <takashi> kota_: Can I ask you to create a list of your patches for review? 08:55:00 <eranrom> takashi: any special patch to start with? Other then the ones I have reviewed 08:55:04 <takashi> sorry, not for kota_ 08:55:08 <takashi> ^^^ akihito 08:55:39 <takashi> eranrom: about my patch, base class implementation for all agent codes are the base one 08:55:43 <takashi> but that dependency is unnecessory, so will think if I can solve that long dependency in some days 08:56:04 <akihito> ok! I will create patches list 08:56:14 <takashi> and I'll also create patch list... 08:56:18 <takashi> about mine 08:56:43 <eranrom> please post them on our channel once you got them. 08:56:44 <kota_> thx 08:56:54 <kota_> eranrom: +1 08:57:01 <takashi> eranrom: +1, and ok 08:57:23 <akihito> ok. 08:57:29 <eranrom> Thanks! We are running out of time, so I will just mention the PDT etherpad. pls have a look and add as you see fit 08:57:39 <kota_> fPTG 08:57:45 <eranrom> https://etherpad.openstack.org/p/storlets-pike-design-summit 08:57:53 <eranrom> kota_: right! 08:57:56 <takashi> eranrom: will check it. thanks! 08:58:10 <kota_> thanks eranrom for organizing 08:58:26 <eranrom> Thanks you all for joining. and for the great discussion. 08:58:44 <eranrom> If there is anything else, we can continue on #openstack-storlets 08:59:06 <eranrom> #endmeeting