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